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

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

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

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

האתגרים בשיטת מפל מים
כפי שראינו העמידה בגאנט מציבה בפנינו אתגרים משמעותיים בעת מימוש פרויקט בשיטת מפל המים:

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

אז מתי כן משתמשים במפל המים?

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

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

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

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

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

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

משה קפלן 

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

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

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

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