למה אנחנו לא עומדים בזמנים? – חלק 2

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

  1. יותר מידי תכולה – מה? מי נתן לי את הזכות לטעון טענה כזאת?
    לא טוב לך? לך תעבוד בחברה אחרת שם יש פחות תכולה לפרויקטים!
    ובכן, תוצאות המחקר ה”מחמיא” ביותר מראות כי 40% מכל התכונות (Features) שמפותחות אינו כלל בשימוש ו-25% מהתכונות נמצאות בשימוש לעיתים רחוקות. כלומר – יש יותר מידי תכולה!
    נכון, אתם צודקים,בד”כ הלקוח מחליט על התכולה (גם לקוח פנימי הוא לקוח), אבל איזה היגיון יש ללקוח אם הוא בוחר לשלם בממוצע 40% תוספת על תכונות שהוא לא ישתמש בהן?
    ואני אומר – היגיון בריא!
    בשיטת המפל, עוד לפני תחילת הפיתוח, מספק הלקוח לחברת התוכנה את הגדרת התוכנה ומאפייניה, עכשיו דמיינו לכם שאתם מזמינים תוכנה, ואומרים לכם “תחשוב טוב מה אתה רוצה בתוכנה עכשיו, כי אם תרצה שינוי, זה יעלה לך, והרבה!”, מה תעשו? תכנסו ישיבה ותגדירו את הדרישות, ואז פתאום תעלה שאלה, “נראה לכם שנזדקק לתמיכה באורקל ?” אז תגידו, “לא בטוח, אבל אם נזדקק זה יעלה המון, אז תכתוב שכן.”, וכך עקב העובדה שהלקוח לא רוצה לשלם יותר, ועקב העובדה שהוא מודע לכך שכנראה הדרישות שלו ישתנו בעתיד, הוא משלם הרבה כסף על דברים שהוא לא צריך. מעניין. ב- Agile רוצים שינויים – אוהבים שינויים ! והלקוח לא צריך להגדיר הכל מראש
  2. תעביר את זה הלאה – בשיטת המפל, ברגע שמתחילים לפתח, כבר יש תוכנית מפורטת שמתארת את סדר הפיתוח, כמה זמן כל דבר ייקח ואת התלויות בין המשימות (תרשימי גאנט ופרט – GanttPert). התבוננו נא בשרטוט הבא:
    clip_image002
    למי שלא הבין את השרטוט: משימה ג’ יכולה להתחיל רק כשמשימה א’ ומשימה ב’ נגמרות, למזלנו משימות א’ וב’ יכולות להתבצע במקביל ובל לחסוך זמן.
    כעת, נניח שמשימה א’ ו-ב’ תוכננו להסתיים ביחד, וקרה מקרה ומשימה א’ איחרה בגלל אחת מאלף סיבות, מה עשינו, גרמנו לאיחור של ג’ (וכל מי שתלוי בה). עכשיו תגידו: ברור – יש דרך אחרת, הרי ג’ תלויה ב-א’ ו-ב’. צודקים אבל עכשיו דמיינו לכם תרשים גאנט אמיתי, שיש בו תלויות מספיק בשביל לגרום לאשפוזכם, והא לכם עוד פרויקט שלא עומד בזמן. ב-Scrum (מימוש של Agile) יש צמצום של התלויות על ידי תכנון שונה.
  3. יחידות המידה לא נכונות – אחת הבעיות בתכנון זמנים המסורתי של פרויקטים היא, תאמינו או לא, יחידות המידה.
    יש לנו מדד מקובל שקוראים לו זמן (או שעה), ומבחינה אנושית ופסיכולוגית אנחנו די מוגבלים ביכולת שלנו לחוש באמת את יחידת המידה הזאת, בשביל זה יש לנו שעונים. בעזרת יחידת המידה הזאת אנו מודדים מספר דברים שונים :
    מאמץ (Effort) – משימה X תיקח Y שעות עבודה.
    זמן קלנדארי – אמנם Y שעות עבודה, אבל זה ייקח חודשיים עקב אילוצים אחרים.
    דוחות – כמה שעות עבדנו על מה.
    העניין הוא שבכל שימוש מסתתר מידע שאינו חשוף לקורא, לדוגמה – 100 שעות, אולי מסתתר מי יעשה את המשימה או כי 100 שעות של מפתח מנוסה הן לא 100 שעות של סטודנט, או שיש מישהו בחופש בחודש יולי ולכן המשימה לא תוכל להתקדם, או שבדוחות לא מוכנס למשל ש-M עזר ל-Z שעה בפרויקט אחר ביום שני.
    בנוסף, ובאופן מסורתי, ההנהלה תמיד מנסה לאזן את המשוואה של שלושה גורמים, שאמנם תלויים זה בזה אך בד”כ לא שווים:
    זמן קלנדארי = מאמץ ( של גרסא נניח) = זמן בדוחות.
    אסיים בשאלה האלמותית : האם אנשים = שעות ? או, האם תשע נשים בחודש ראשון יכולות לייצר תינוק ?
    לשיטות התכנון האג’יליות יש אלטרנטיבה לתכנון בשעות.

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

4 Responses to “למה אנחנו לא עומדים בזמנים? – חלק 2”

  1. נועם says:

    אוקי, העצם שזרקת קטנה מדי כדי לפתח כאן דיון…ולמרות זאת:
    יותר מדי תכולה? נשמע הזוי משהו…הרי אנחנו כל הזמן מקצצים בתכולה כדי “לכנס” תוכניות עבודה…התחושה היא שאנחנו תמיד עושים את המינימום הנדרש (וגם בדרך הקצרה ביותר – שלרוב השגויה ביותר, אבל זה נושא אחר).
    לעיתים, נדרשת ממוצר תכולה בסיסית די גדולה כדי שתתאים לרוב הלקוחות ואז אתה משדרג ומוסיף ללקוח ספציפי פיצ’רים בשבילו (בוא נקרא לזה “התאמת מוצר”).
    מאוד בעייתי לברור את התכולה הבסיסית, שהרי אתה רוצה לקלוע לכמה שיותר לקוחות, למשוך אותם ואז לבצע “התאמת מוצר”.
    זו אולי הסיבה שלקוח לא משתמש בהרבה מהפיצ’רים הקיימים במוצר – אבל הם חייבים להיות בו (לפחות בשביל הברושור של השיווק :-) ).
    כמה אנשים משתמשים ב “סאונד רקורדר” של חלונות? ועדיין לכולם יש – ירצו או לא ירצו… מקווה שהפואנטה ברורה.
    האם אתה מכיר מקרים שמתארים תהליכי “התאמת מוצר” עם דרישות מופרזות של הלקוח? תביא משהו מבוסס…לא סומך על המילה שלך 😉

  2. agileman says:

    קודם כל, תודה על התגובה, אני ממש נהנה!
    אקדים ואומר שאינני מתיימר לפתור את כל בעיות העולם בפוסט אחד (ייקח לפחות שלושה :) ) והתייסתי לאספקט ספציפי מאוד בבעית התכולה, אך כשנצלול יותר עמוק לאג’יל אני מקוה שתהיה לך הבנה טובה יותר של ניהול תכולה בתפיסת ה-agile.
    וכעת לעניין, הסקר שהבאתי הוא באמת המחמיא ביותר ורוב הסקרים אף גורסים כי אחוזים יותר משמעותיים מהפיצ’רים אינם בשימוש.
    נכון שאנחנו “חותכים” תכולה בד”כ, השאלה היא: האם הורדנו את החלק הנכון? האם באמת עשינו את המינימום, או שמא פיתחנו פיצ’רים לא רלוונטיים, והמינימום למעשה לא פותח?
    עיקר הבעיה לדעתי, ושם גם שמתי את הדגש היא הגדרות מופרזות, וכן, אני מכיר הגדרות כאלה אך אני לא יכול להיכנס לפרטים עקב סודיות של החברות שעבדתי בהן.
    אני גם חולק עליך כשאתה אומר ש:”זו אולי הסיבה שלקוח לא משתמש בהרבה מהפיצ’רים הקיימים במוצר – אבל הם חייבים להיות בו (לפחות בשביל הברושור של השיווק”, על סמך מה אתה טוען את זה ? האם יש לך ניסיון הפוך ?
    אני מאמין שהלקוח יעדיף התאמה ספציפית לפי דרישות שלו על פני ברושור זה או אחר.
    אוסיף ואומר שלמשוך לקוחות זה עבודה של מחלקת מכירות ולא תוכנה, אז הם יכולים לכתוב על הברושור מה שהם רוצים, כשלקוח יבקש את זה, אנחנו גם נפתח.

  3. נועם says:

    רק כדי לסגור פינה…להרבה מוצרים תכולה בסיסית שגדלה לא מבוטל.
    אם אתן דוגמא מן העולם הקרוב אלי, כדי שיהיה לך BRIDGE ביד, אחרי ש”הרמת” את החומרה, האופטיקה, תשתיות התוכנה, הניהול והדיבג וכולי (ונגיד שהכל לעילא)…אתה עדיין צריך סט לא מבוטל של פיצ’רים אפליקטיבים על מנת שתהיה לך ה”זכות” לקרוא לעצמך BRIDGE. אפליקציות שהן הא”ב של BRIDGE – והסט הזה די רחב.
    מעל הסט הבסיסי ישנן תוספות אינספור של פיצ’רים והרחבות של הפונקציונלית הבסיסית בהתאם ללקוח.
    הלקוח, גם אם הוא לא ממש צריך כל פיצ’ר מהסט הבסיסי, ידרוש אותו בדיוק כמו שאתה מצפה למזגן וחלונות חשמליים באוטו החדש…ועדיין תרצה אותם ב-נ-ו-ס-ף למערכת ההגברה והדי.וי.די ששידרגת (קרי, התאמת המוצר לך כלקוח ספציפי). עכשיו תענה בכנות, אם היו אומרים לך, “עזוב אותך עכשיו ממזגן, עכשיו חורף – נתקין לך בקיץ, כי לא נוכל גם לשים מזגן וגם די.וי.די ולספק לך את האוטו בזמן”, היית הולך לקנות במקום אחר לא?
    בקיצור – אם לא בדוגמא אז פרגן בלינק לסקר עליו אתה מתבסס…יכול להיות שהוא מטעה ולא לוקח בחשבון את החשיבה הבאה:
    אם תיקח הרבה לקוחות (שמשתמשים באותו מוצר) ותעשה איחוד של הפיצ’רים שבהם הם משתמשים, ככל הנראה תגיע ל 90% שימוש…אם תתמקד רק בלקוח אחד אתה במקרה הטוב תגיע ל 60% ה”מחמיאים” אבל אז אתה לא מתאים ללקוחות האחרים שמנצלים את ה 30% האחרים (90-60) שלא היו לך לו התמקדת בלקוח היחיד.
    אם הסקר אומר שאחרי “איחוד הלקוחות” אנחנו ב 60% אז מבחינתי עברת משוכה אחת בדרכך הקשה לשכנע אותי 😉 . אם הוא בוחן רק מקרה מוצר-לקוח לגופו – הרי שהוא מפספס.

  4. agileman says:

    הסקר בוחן כ-40,000 פרוייקטים של תוכנה מכל הסוגים, כלומר גם מוצרי מדף וגם מוצרים Custom. להבנתי הנתון מתייחס לכל פרוייקט תוכנה לגופו ולא לכל לקוח, ומנסיוני הנתון הוא הגיוני.
    הייתי שמח לתת לך לינק אבל המחקר מוגן בזכויות ועולה כסף, אתה מוזמן לקנות אותו בלינק הבא:
    http://www.standishgroup.com/quarterly_reports/index.php
    או להתרשם מהתיחסות אליו בלינק הבא (שים לב לגרף) : http://www.featuredrivendevelopment.com/node/614