כמה דברים לפני שאנחנו בוחרים במפל המים (Waterfall)

30 בספטמבר 2011


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


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


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


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


 כשצריך לעמוד במטרות


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




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


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


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


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


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

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




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


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


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


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


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


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

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


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


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


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


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


משה קפלן Follow MosheKaplan on Twitter


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


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


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


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


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

להגיב על יוסי טל לבטל

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

9 תגובות

  1. יוסי טל1 בנובמבר 2011 ב 13:18

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

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

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

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

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

    כמובן שכל סבב ספירלי יכול להיות תכנית שתמומש בשיטה אג'ילית כלשהיא, בקצור הגמישות מירבית

    הגב
  2. Moshe Kaplan1 בנובמבר 2011 ב 14:00

    שלום יוסי,

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

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

    הגב
  3. ליאור1 בנובמבר 2011 ב 14:01

    יוסי,

    בהרבה מובנים אגייל זה ספירלה עם מחזורים מאד קצרים.
    ואם זה עובד לחלקים של 3-4 חדשים. אז למה לא לקצר לחלקים של 3-4 שבועות?

    הגב
  4. Moshe Kaplan1 בנובמבר 2011 ב 16:38

    ליאור,

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

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

    הגב
  5. אילן1 בנובמבר 2011 ב 18:42

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

    הגב
  6. Moshe Kaplan2 בנובמבר 2011 ב 8:45

    תודה אילן על הנקודות החשובות,

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

    אבל מה עושים בהשקה כשיש לך הזדמנות אחת?

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

    הגב
  7. אדריאן הורודניצ'אנו6 בנובמבר 2011 ב 17:03

    שאלת שיטת ניהול הפרוייקט היא מעניינת ותומכי הagile הנלהבים לא רוצים לשמוע על מפל המים , אף כי בפרוייקט גדול שבו קיימים מספר רב של צוותים שונים, גם אם כל אחד מהם עובד agile , בסופו של דבר בנקודות ההשקה בין הצוותים ולקראת בדיקות כוללות (עומס, ביצועיים, הסבות) למעשה מנההלים מפל/י מים של חלקי agile .
    הדבר החשוב בכל מקרה בנהול פרוייקט בינוני ומעלה הוא לדאוג למספר נקודות חשובות :
    1) נהול סיכונים כולל בהתחלה וביצוע review אחת לחודש .
    2) מעקב ,עדכון ואיתור צווארי בקבוק באותו גאנט באופן שוטף כמו שנאמר על צווארי בקבוק…. אין צווארי בקבוק ללא גאנט).
    3) שיתוף ועירוב הלקוח בתהליכי הנהול על מנת לוודא שהדרישות תקפות או חל בהם שינוי , בעיקר בראייה העיסקית.
    4) טיפ טיפת מזל אף פעם לא מזיק.

    הגב
  8. Moshe Kaplan7 בנובמבר 2011 ב 14:45

    שלום אדריאן,

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

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

    הגב
  9. מיכאל שורץ20 בנובמבר 2011 ב 21:36

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

    לדעתי זה מכסה את ההבדלים בין המתודולוגיות השונות (כלומר, בנושא האיטרציות, כל מתודולוגיה היא מקרה פרטי של הפרמטרים הנ"ל).
    להרחבה: http://eyelevel.co.il/2011/05/23/

    אשמח לשמוע את דעתכם.

    מיכאל

    הגב