שישה מיתוסים שצריך לשבור לפני שבוחרים את שיטת ניהול פרויקטי תוכנה הנכונה לך

31 באוגוסט 2011

אחרי שדיברנו על כיצד לעשות ארכיטקטורת תוכנה בצורה טובה יותר, הגיע הזמן לפתוח את הקלפים ולראות איך אנחנו מביאים תוצר עובד שמתאים לארגון שאנחנו עובדים בו.
אמנם דיברנו כבר בעבר על כלי הפיתוח הנכונים, איך מגייסים את אנשי הפיתוח הנכונים ואיך מכשירים מהנדסי תוכנה, אבל הפעם נדבר על תרבות ארגונית, צרכים עסקיים ואיך זה מתחבר לקוד שאנחנו כותבים.

 

מיתוס מספר 1: כל פרויקטי התוכנה נכשלים
לא כל הפרויקטים נכשלים. אבל הנתונים של של Leading Answers שמוצגים למטה ומתבססים על נתוני Standish Group (*) מצביעים ש – 95% מהפרויקטים שנמשכים מעל שנתיים נכשלים! אלו כמובן החדשות הרעות. החדשות הטובות הן שאם נבין למה יש 5% שמצליחים, נוכל לבצע את הדברים הנכונים גם אצלנו. לשם כך נצטרך לשבור כמה מיתוסים.

 

(*) Standish Group היא חברת ייעוץ מובילה בתחום ניהול הפרויקטים הממוקמת בבוסטון. החברה אוספת נתונים על פרויקטי תוכנה מאז שנת 1994, ומפרסמת אחת לשנה סטטיסטיקות עדכניות. נתוני 2011 פורסמו בגיליון PM Network August 2011 של אגודת ה – PMI. הנתונים בגרף למטה הם משנת 2005 (לא כל כך ישן למאמר אקדמי), אבל הם בהחלט תקפים כפי שתוכלו ללמוד מהמאמר ב – PM Network וההשוואה של הנתונים הכוללים לשנים הקודמות (37% מהפרויקטים עומדים בזמן ובתקציב, 42% "מאותגרים הצלחתית" ואילו ב – 21% מהמקרים הכירו בכישלון המוחלט של הפרויקט).

 

From Leading Answers Blog: 2007 Study by Standish Group

 

מיתוס מספר 2: פרויקטים נכשלים כי אין להם מספיק משאבים
הוספת שולי בטחון לפרויקט והגדלת רמות הניהול (שמתרגמות בסופו של דבר לדיוני סטטוס בני שעתיים שבהם חצי מהאנשים המשתתפים לא רלוונטיים), תגרומנה באופן פרדוקסאלי להגדלת הפרויקט ולפי הגרף לעלייה בסיכוי לכשלון. אם נעיף מבט נוסף בגרף נראה שפרויקטים קצרים מגיעים ל – 60% הצלחה, ולכן הפתרון לעיתים יהיה להקטין את הפרויקט: הקטנת תכולה, הקטנת זמנים, פישוט ארכיטקטורת התוכנה וקיצור יעדים.

 

מיתוס מספר 3: יש רק שיטת ניהול פרויקטים אחת והיא עובדת לכל פרויקטי התוכנה
בקורסי ניהול פרויקטים מתרכזים בעיקר בשימוש בגאנט וניהול פרויקטים בשיטה הקלאסית Waterfall. בשנים האחרונות החלו להופיע מספר שיטות חדשות שמביאות מענה לצרכים עסקיים שונים של חברות. הראשונה בהן היא מתודולוגיית ה – Agile המתמקדת בעבודה עסקית בסבבים קצרים יותר, תוך שימוש בהיזון חוזר מהסביבה (אנחנו נעסוק בה בפוסטים הבאים, אבל בינתיים מומלץ שתעיפו מבט בבלוג המצויין של אלעד סופר שעורך גם את מפגשי ה – Agile practitioners IL). מתוך מתודולוגיה זו צמחה שיטת ה – SCRUM שדוגלת בשחרור גרסאות עובדות מדי 2-5 שבועות. שיטה חדשה עוד יותר שהופיעה רק בשנתיים האחרונות היא ה – Continuous Deployment. שיטה זו מוטמעת כבר במספר חברות בישראל ודוגלת בשחרור גרסאות לייצור מסביב לשעון (או בעברית פשוטה יותר עשרות גרסאות חדשות בייצור מדי יום). השיטה הזאת מתאימה בעיקר לגופי תוכנה שמספקים שירות ללקוחות פנימיים או חיצוניים וגם בה נדון בשבועות הקרובים.

 

מיתוס מספר 4: אני מנהל פיתוח בסטארט אפ, השיטה הזאת לא מתאימה לי, היא מתאימה רק לחברות גדולות!
אז זהו, שלא כל החברות זהות, גם אם מספר העובדים בהן דומה ואפילו אם הן עוסקות באותו ענף. ההחלטה על שיטת ניהול פרויקטי התוכנה צריכה להלקח על בסיס מאפייני הארגון, צוואר הבקבוק הארגוני שלו והתרבות הארגונית. אם הכוונה שלך במילה סטארט אפ היא "חברה ללא הררכיה מסודרת עם רמת הגדרת מוצר נמוכה, חוסר ודאות לצרכי המשתמשים ותרבות ארגונית שמבוססת על ניצול הזדמנויות" אז ככל הנראה החסם שלכם בארגון הוא השוק וההיזון החוזר ממנו. אמנם תיאור זה מאפיין ארגונים של 3 אנשים שייסדו את החברה לפני חודש עם מושג מועט לגבי השוק, אבל הוא גם מאפיין חברות גדולות בהרבה (דוגמה טובה לכך תמצאו בפוסט על השלבים הראשונים בפיתוח מוצר ב – Google).
מצד שני, ישנן גם חברות קטנות מאוד שעונות טוב מאוד להגדרה "יש לנו הגדרת צורך ברורה מאוד לגבי השוק, אנחנו יודעים בדיוק מה אנחנו צריכים לספק גם בשבוע הבא וגם בעוד שנה, אבל אם היו לנו עוד 5 מהנדסי תוכנה היינו מגיעים לשם מהר יותר". זאת אף על פי שהגדרה זו נפוצה יותר בקרב חברות גדולות יחסית עם בסיס רחב בשוק,התקנות קיימות וצבר הזמנות. בחברות שעונות להגדרה הזאת החסם הוא בכח הפיתוח ויעילות הניצול שלו. המענה לכך יהיה תיעדוף נכון של משימות, הכפפה של הארגון לצרכי גוף הפיתוח ושחרור מהיר של חבילות לשוק.
סגמנט נוסף של חברות הוא סגמנט חברות שיודעות מה השוק רוצה והן רוצות לזעזע אותו. במקרים כאלו המשימה המרכזית תהיה בניית תוכנית מסודרת שתתמקד ביצירת אפקט מקסימלי בזמן מינימאלי בעת ההשקה.

 

מיתוס מספר 5: שיטת ניהול פרויקטי התוכנה הנכונה ביותר היא זאת שכולם מדברים עליה בערב יום שישי
קודם כל אם אתם מדברים על זה בערב יום שישי, אז הגיע הזמן שתגוונו את החברים שלכם. מיד לאחר מכן, כדאי שתבינו מה החסם העסקי של החברה שלכם, וכיצד גוף פיתוח התוכנה שלכם יכול לשרת טוב יותר את החסם הזה. לעיתים תדרשו להבין האם הארגון במשבר וכיצד אתם צריכים להתאים את עצמכם לכך.
לדוגמה, חברה שתלויה בגחמות של לקוח יחיד: במצב זה מתן מענה מיידי בתוך חלון זמנים קצר לצרכי הלקוח משמעותו זכייה בחוזה משמעותי נוסף, לשם כך תדרשו להתאים את שיטת ניהול הפרויקטים לדרישה הזאת. איך עושים את זה? אמנו את צוות הפיתוח שלכם למימוש פרויקטים בזמן קצר, תרגלו זאת והשקיעו בהרחבת הידע של הצוות. גם אם האימונים הללו נראים חסרי תוחלת או שנראה לכם שיכולתם להוציא יותר תוצר פיתוחי בפרק הזמן הזה, אל תתפתו לשנות את התעדוף.
לעומת זאת, אם הלקוחות שלכם רגילים לבצע הזמנות פעם בשנה, התאימו את תהליך הפיתוח כך שתגיעו עם גרסה יציבה, נקייה ושוברת קופות בזמן ובמקום הנכון כי אתם לא רוצים לפספס כמו סוני את ה – Christmas Launch.

 

מיתוס מספר 6: קוד תוכנה הוא כמו ג'לי, צריך לתת לו להתמצק לפני שמשחררים אותו החוצה
קוד שלא שוחרר ללקוחות הוא מלאי של חברות שהמוצר שלהם הוא חבילות תוכנה או שירותים מבוססי תוכנה.
אם תשאלו מנהלי תפעול ומנהלי כספים של חברות תעשייתיות, הם יספרו לכם שמלאי הוא דבר רע כי הוא צובר אבק ומאבד ערך והדבר היחיד שגרוע ממנו הוא מלאי בתהליך (חומרי גלם שעברו עיבוד ראשוני ואי אפשר למכור אותם לא כחומר גלם ולא כמוצר מוגמר). הבשורה הרעה היא שכאשר אנחנו מפתחים מוצר, כל עוד אנחנו לא משחררים גרסה ללקוחות, כל הקוד שלכם הוא מלאי בתהליך (שילמתם כסף טוב למפתחים, מעצבים וכו' אבל שום לקוח לא יכול להשתמש בתוצרים). במקרה הרע שבו אתם משחררים גרסה פעם בשנתיים, למעשה כל הוצאות המו"פ שלכם במשך שנתיים הן מלאי בתהליך. הבשורה הרעה עוד יותר, היא שבתעשיית התוכנה הפחת של מלאי הוא מהיר מאוד, ולכן במחזורים ארוכים, אנחנו משחררים מוצרים מיושנים שעלות הפיתוח שלהם יקרה ומפסידים כסף רב שיכול היה לעבור לשורה התחתונה של הדוחות הכספיים. בעיה נוספת של זמני פיתוח ארוכים היא שככל שהמוצר מסובך יותר זמן ההתמצקות של הג'לי ארוך יותר, ואת התוצאה תוכלו כמובן למצוא במיתוס מספר אחד. אם מעניין אתכם איך משחררים גרסאות במהירות ללא התמצקות של ג'לי חכו לפוסט על Continuous Deployment.


השורה התחתונה
בחירת שיטת ניהול פרויקטי התוכנה המתאימה לכם צריכה להתבצע לפי הצורך העסקי שלכם, המבנה הארגוני והתרבות הארגונית, וחשוב מכל: החסם העסקי שעומד בפניכם. אם כולם בוחרים ליישם SCRUM, זאת לא בהכרח השיטה הנכונה בשבילכם ויתכן שהיא תגרום לכם יותר נזק מתועלת. בפוסטים הבאים נלמד על השיטות השונות ומתי נכון להפעיל כל אחת מהן.

 

יש לכם מיתוסים נוספים שצריך לשבור? רוצים לתת טיפ לבחירת לשיטות ניהול פיתוח תוכנה טובות יותר? אתם מוזמנים להוסיף את התרומה שלכם בהערות בתחתית הפוסט.

 

נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!

 

ממשיכים לפתח
משה קפלן

 

משה קפלן הוא יזם, יועץ ומרצה בתחום ניהול פיתוח תוכנה

 

טיפים והערות הקוראים

הטיפ של אבי נפרסטק:

אהבתי את הדגש על למצוא מה נכון לארגון, לאתר את חסמי ההצלחה של הארגון ולטפל בהם.
סקראם הוא דוקא שיטה שמציפה את המחסומים הארגוניים "לפנים" ומכריחה אותנו לטפל בהם,
מהבחינה הזו ולפי הפוסט שלך היא דוקא כן טובה לכולם.

אגב לגבי כשלון פרוייקטים – אג'ייל שובר את הכללים.
בפרוייקטי WATERFALL הצלחה וכשלון נמדדים באם המוצר שהוזמן מראש הגיע בזמן, האם היו עיכובים במסירה, האם היו באגים והאם היו הפרות חוזה.
באג'ייל משנים את ההגדרה של הצלחה – הצלחה היא ליצור שביעות רצון של הלקוח/משתמש ולייצר עבורו ערך עסקי גם כשהדרישות משתנות, ולהתמיד בזה לאורך זמן.
אין תאריך יעד ואין תכולה מוסכמת מראש, כך שאין משמעות לשבירה שלהם כל עוד מספקים ערך אמיתי ללקוח.

 

הטיפ של סער דגן:

לא כל הפרוייקטים שעומדים בזמן ובתקציב הם פרוייקטים "מוצלחים" הרי יש את מקרי ה-"המערכת עובדת אבל לא ישתמשו בה בצורה יעילה/לא באמת מתאימה לצרכים" סקראם ואג'ייל לא באו סתם כי חשבו שצריך להחליף את מפל המים וזהו, היתרון של מתדולוגיות אלו הן כמובן השינויים המהירים שניתן לבצע עקב ההיזון החוזר.
ולכן הרבה חברות עוברות למתדולוגיות אלו כי חברות יעדיפו להשקיע עוד טיפה תקציב וזמן עבור מערכת שתיתן מענה אמיתי לצרכים בארגון.

 

התייחסות:

אתה צודק לחלוטין, כל ארגון (כמו כל אדם) עושה את החלטות הרכש הנכונות (והלא נכונות) שלו.
אני בטוח שאם כל אחד מאיתנו יפתח את ארון הבגדים שלו, הוא יגלה כמה דברים שאין לו מושג מה גרם לו לרכוש אותם…

ככל שבארגון שלכם יש יותר "חפצים מיותרים בארון", שיטות Agile יתאימו לו יותר. אם לעומת זאת נדיר למצוא "חפצים כאלו" או לחילופין פרויקטים והשקעות משמעותיות שנחות להן כאבן שאין לה הופכין, יתכן ששיטות כגון מפל המים יתרמו יותר לארגון שלכם.

 

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

12 תגובות

  1. Moshe Kaplan1 בספטמבר 2011 ב 22:47

    רק הוצאתי את הפוסט, וכבר קיבלנו חיזוק בדמות מחקר אוניברסיטת אוקספורד: לפרויקטי IT סיכוי של פי 20 להיכשל לעומת כל פרויקט עסקי אחר:
    http://www.pc.co.il/?p=68232

    ממשיכים לפתח,
    משה קפלן

    הגב
  2. Moshe Kaplan5 בספטמבר 2011 ב 14:09

    אם אתם מתעניינים בתוכנה ורוצים לראות את ה – Thread בקשר לפוסט הזה, אתם מוזמנים להצטרף לקבוצה פיתוח התוכנה בפייסבוק: http://www.facebook.com/groups/swdevelopers/

    ממשיכים לפתח,
    משה קפלן

    הגב
  3. פיני כהן19 בספטמבר 2011 ב 18:51

    משה- דברים כדורבנות
    ישר כוח!

    הגב
  4. Moshe Kaplan19 בספטמבר 2011 ב 22:08

    תודה פיני,

    ממשיכים לפתח,

    משה קפלן

    הגב
  5. ויקטור רוקח6 באוקטובר 2011 ב 20:10

    בכליי נכון מאוד. אך עדיין יש מאפינים לארגון שכדאי לקחת בחשבון. לדוגמה עובדים בצוותי ה-agile שגם צריכים עדיין לתמוך ביישומים קודמים , או בארגונים גדולים, כאלו שנותניפ שירות לצוות הפיתוח, אך הם נותני שירות בצורה מטריציונית. היתרון הגדול הוא בהפשטה של הכל: וזה כולל את המשתמשים, חברי הצוות וכיוצ"ב.

    הגב
  6. Moshe Kaplan6 באוקטובר 2011 ב 20:55

    שלום ויקטור,

    אתה בהחלט צודק, יש נושאים רבים שצריך להתייחס אליהם כשמיישמים Agile. בכלל זה באפרים בין הגורם הקריטי בארגון (במקרה הזה כנראה התמיכה ביישומים הקודמים עונה לזה), לבין המשאב שמנסים לנהל. אני אתייחס לזה בהרחבה באחד מהפוסטים הבאים.

    ממשיכים לפתח,
    משה קפלן

    הגב
  7. יובל ירט7 באוקטובר 2011 ב 8:12

    שלום משה,

    כתבה מעניינת. אכן חשוב להתייחס למאפייני הסביבה העסקית, הסיכונים והאי-ודאות בבחירת שיטת פיתוח.

    מה שכן חשוב לי לציין הוא שגם אם לא מתאים לשחרר ללקוחות באופן תדיר מדי, עדיין יש יתרון משמעותי לביצוע תהליך הפיתוח באופן המוריד סיכונים ע"י משוב מהיר יותר להחלטות, לקוד, לאינטגרציה. אני מכיר לא מעט ארגונים קטנים כגדולים שמשחררים גרסה פעם בשנה ללקוחות מאוד גדולים ושמרנים, אך מצאו ששיטות פיתוח אג'יליות בסגנון SCRUM ו-KANBAN (שלא הזכרת כאן) עוזרות להם להוריד סיכונים ולמסור גרסאות בזמן ובאיכות, תוך predictability יחסית גבוה למה עיקר התכולות בגרסה.

    דווקא שיטות כגון המפל לא מצטיינות בעמידה בזמנים ובאיכות… ברגע שיש איזהשהם גורמי אי-ודאות (legacy code, technical debt, אי ודאות מה הלקוח רוצה, נושא טכנולוגי חדשני).

    הגב
  8. Moshe Kaplan7 באוקטובר 2011 ב 11:11

    שלום יובל,

    תודה על הדגשים הנכונים! שיטות ה – Agile אכן תורמות משמעותית גם למוצרים עם גרסאות שיוצאות אחת לשנה (אפילו עצם הקטנת האינטגרציה וצמצום הסיכון בה הוא רווח משמעותי מאוד).
    לגבי מפל המים – כפי שניתן לראות בפוסט החדש שהוצאתי: http://blogs.microsoft.co.il/blogs/vprnd/archive/2011/09/30/waterfall.aspx אכן, החסרון הגדול ביותר שלה הוא התמודדות עם גורמי חוסר ודאות (כאמור כל שיטה והיתרונות שלה 🙂

    ממשיכים לפתח,
    משה קפלן

    הגב
  9. אדריאן7 באוקטובר 2011 ב 22:02

    AGILE הוא טוב כאשר ניתן לספק חלקים קטנים יחסית ולקבל משוב מהיר. יש עלויות לפיתוח כזה (אין ארוחות חינם ) בכל הקשור לתהליכי ההדרכה והיישום שנעשים ביחידות קטנות מדי. בארגון גדול עלויות אלה עשויות להיות גדולות ( מאות אנשים והרבה מדריכים חוזרים לקבל הדרכה על פיסת אפליקציה נוספת באופן תדיר).
    החלופה של "צבירת" הפיתוח עד שיש מספיק "מסה" להפיץ כפי שיובל ממליץ חוזרת לבעית המלאי בתהליך ועל מסירת מערכת אחרי הרבה זמן.
    יש להביא בחשבון גם את טיב האפליקציה . לפעמים אין משמעות לחלקים אלא לשלם כולו .
    בקיצור אין וכנראה שלא תהיה שיטה מנצחת . כל פרויקט וכל ארגון דורש את שלו .
    מה שכן AGILE רענן את עולם פיתוח התוכנה וניהול פרויקטי תכנה שקפא תקופה ארוכה.

    הגב
  10. Moshe Kaplan9 באוקטובר 2011 ב 16:59

    שלום אדריאן,

    תודה על ההערות החשובות.

    נושא ההטמעה הוא נושא חשוב מאוד, שטרם התייחסתי עליו בהרחבה בפוסטים, ונראה ששווה להקדיש לו בעתיד פוסט. בנקודה הזאת כדאי לציין שחברות האינטרנט (כמו גוגל ופייסבוק) עושות שימוש מסיבי בהדרכה באמצעות סרטונים והסברים קצרים שדווקא נהנים מהשקות של מספר מועט של רכיבים.
    לעיתים דווקא בהטמעה יש עדיפות לביצוע של שינויים קטנים ודחופים מאשר שינויים מהותיים שדורשים הדרכה מאפס.

    ממשיכים לפתח,
    משה קפלן

    הגב
  11. אופיר18 במאי 2012 ב 16:52

    פוסט מעולה!
    לAGILE המון יתרונות, בייחוד נהנים מהשיטה דרגי העבודה, המפתחים וראשי הצוותים, אך לעיתים מתעורר קושי ביישום השיטה בחברות המנהלות עשרות פרויקטים בו"ז עם משאבים מטריציונים, כמו כן מתעורר קונפליקט בדרגי הניהול הבכירים, בעיקר בחברות בורסאיות בעלות דירקטוריונים, בהיבט הגדלת רווחיות החברה. לדעתי ארגון המעוניין להגדיל את התפוקה שלו בסדרי גודל, יתקשה לעשות זאת רק עם מתודולוגיית AGILE, לכן, שילוב של AGILE עם מתודולוגיות מוכוונות תפוקה כגון TOC יכול ליצור WIN WIN הן לדרגי העבודה, ללקוחות ולדרגי הניהול הבכירים.

    הגב
  12. Moshe Kaplan18 במאי 2012 ב 18:25

    שלום אופיר,

    תודה!
    לצערי (ואני בטוח שיהיו כאלו שיתקנו אותי), Agile ועבודה מטריציונית לא עובדים כל כך טוב. Agile עובד טוב מאוד בארגונים שיש להם צוואר בקבוק מזוהה (ופה אנחנו מתחברים ל – TOC), וכל הארגון עובד מסביב אליו. כאשר הליבה של צוואר הבקבוק (לדוגמה מהנדסי התוכנה) עובדים בצוותים אורגניים (כל צוות מטפל במוצר או בחלקו), ושאר גופי החברה עובדים מסביבם לפי הספרינטים שבחרתם.

    אם צוואר הבקבוק בארגון הוא הלקוח או ה – QA, אני לא בטוח שעבודה ב – SCRUM של צוותי הפיתוח תעשה טוב לארגון.

    אבל כאמור זאת דעתי בלבד,

    ממשיכים לפתח,
    משה קפלן

    הגב