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

אני לא מבין למה אנחנו לא עומדים בזמנים?

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

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

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

אם התשובה לשלושת השאלות היא כן, איחולי – שברתם את הסטטיסטיקה!
http://net.educause.edu/ir/library/pdf/NCP08083B.pdf
הלינק הוא סקר CHAOS המקובל מאוד בעולם המציין שיעור ההצלחה לפרוייקטי תוכנה הוא שרק 9% מפרוייקטי התוכנה בחברות גדולות ו-16.2% ו-28% בחברות בינוניות וקטנות (בהתאמה) מצליחים.

5 Responses to “למה אנחנו לא עומדים בזמנים ?”

  1. Johny K says:

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

    השאלה היא למה?
    – לפי כיוון הטיעונים שלך, אתה גורס, ש”שיטת המפל” פשוט לא טובה.

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

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

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

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

    אתה יכול להסתכל לי בעינים ולאמר, שכל פרויקט כושל שלקחת בו חלק, לא נכשל כי עניין את כולם יותר איפה אוכלים צהריים או מתי אפשר לחתוך הביתה? -אני חושב שלא…

  2. agileman says:

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

  3. נועם says:

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

  4. מסוקרן says:

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

  5. agileman says:

    למסוקרן היקר שלום,
    קודם כל תודה רבה על התרומה לדיון.
    שיטת המפל היא המתודולגיה המקובלת ביותר כיום בעולם לפיתוח תוכנה, לפרטים והסברים – http://en.wikipedia.org/wiki/Waterfall_model.
    לעומת זאת agile – ועוד לא ממש דיברתי על זה, היא איננה מתודולגיה אלא צורת חשיבה.
    אני לא רוצה להיכנס כעת לעומק, אבל אם זה מעניין אותך אתה מוזמן להמשיך לקרוא כי התפיסה האג’ילית, ובהמשך גם סקראם (אחד המימושים של צורת החשיבה הזאת), ועוד נושאים יעלו בבלוג.