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

הקדמה: זה היה אמור להיות פוסט אחד, אבל הוא כ”כ ארוך אז החלטתי לחלק אותו לחלקים קטנים.

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

  1. העתיד מלא הפתעות: בואו ניזכר רגע בהגדרת התפקיד של אנשים שמתעסקים בפיתוח תוכנה, “Software R&D Engineer”.
    R&D = Research and development, או בשפתינו מחקר ופיתוח.
    לדעתי, מעצם הגדרת התפקיד בולטת בעיה משמעותית, אנחנו מתעסקים במחקר!
    תנסו לשאול מישהו שמפתח תרופה מתחרה לאקמול כמה זמן ייקח לו, מה הוא יגיד? כנראה “לא יודע”.
    אז למה כששואלים אותנו “כמה זמן ייקח לפתח תמיכה באורקל ?” אנחנו עונים “שבועיים, עד חודש..” או משהו בסגנון. איזה כלים יש לנו לומר דבר כזה ? מתי פעם אחרונה פיתחנו בפרויקט שלנו תמיכה באורקל ? כנראה אף פעם, אחרת לא היה צריך.
    מעבר לכך, גם אם פיתחנו משהו דומה, הרי הפרויקט השתנה מאז, כמות אי הודאות וההפתעות היא גדולה, פתאום מסתבר שזה יוצר בעיית ביצועים, או שבכלל צריך לשנות ארכיטקטורה. אני יודע שלכם זה לא קרה, אבל יש מתכנתים שבפיתוח מסוים הכפילו (או יותר) את הזמן שהוערך מראש…
  2. פחד מטעות – דמיינו לכם סיטואציה: יוסי, מפתח מנוסה ומוערך נשאל ע”י המנהל שלו: “כמה זמן ייקח לך לפתח את X ?”, עונה יוסי שייקח לו יומיים (כך הוא באמת חושב), ואז, קצת מסתבך X, לא נעים. אחרי יומיים מגיע המנהל ומצפה לקבל את X, אך הפלא ופלא, X לא מוכן… לא נעים ליוסי. מה עושה יוסי פעם הבאה ששואלים אותו כמה זמן זה ייקח לפתח משהו ? יוסי יגיד 4 ימים (ליתר בטחון), צודק יוסי! מה הוא צריך צרות?
    אני חושב שאין צורך להסביר מעבר לכך.
  3. Procrastination – סינדרום הסטודנט – מי שהיה סטודנט מכיר טוב את הסיטואציה: לדני יש מבחן ביום שישי, היום יום ראשון, הוא מעריך שייקח לו יומיים ללמוד למבחן, אז מה עושה דני בד”כ? הולך לים… אחרי יומיים (ביום שלישי) הוא מתיישב ללמוד, לעיתים על 12 בלילה כי, אופס, צריך עוד קצת זמן – זה סינדרום הסטודנט, תופעה אנושית ידועה ומקובלת בפסיכולוגיה.
    עכשיו, בואו נדבר על יוסי מהסעיף הקודם: יוסי, כאמור, מעריך כפול ממה שהוא חושב, אהה, אז אם ליוסי יש 4 ימים לפיתוח שאמור לקחת יומיים לדעתו, מה יעשה יוסי? אמנם לא ילך לים, יעשה דברים אחרים מקבילים במקום העבודה כגון, קפה, ארוחות צהריים של שעתיים, יתכנת לעצמו תוכנה קטנה שצובעת את המסך בירוק ועוד…. מה לא יעשה יוסי ? את זה אתם כבר יודעים.

יש עוד סיבות רבות – המשך בפוסט הבא….
בינתיים, ולמי שמעניין אותו סינדרום הסטודנט : http://en.wikipedia.org/wiki/Student_syndrome

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

  1. Johny K says:

    לדעתי לקרוא למתכנתים אנשי מחקר ופיתוח היא מגוחכת מיסודה!

    להלן ההגדרה ל- R&D
    “Creative work undertaken on a systematic basis in order to increase the stock of knowledge, including knowledge of man, culture and society, and the use of this stock of knowledge to devise new applications”

    אני משאר שאתה מתכנת ולכן אני מרשה לעצמי לשאול אותך: כיצד אתה קידמת את הידע האנושי? איזה פריט מידע אותו חשפת במחקריך השפיע על החברה האנושית?

    אין צורך שתענה…

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

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

    מהיום אמור “שיפוצניק מחקרי-פיתוחי”

    לקרוא למתכנת, “איש מחקר ופיתוח”, שקול למזכירה שמכנה עצמה “עוזרת אדמיניסטרטיבית” – חסר משמעות אבל נשמע טוב…

    מהיום אמור “זה שעושה את העבודה השחורה בחברות היי-טק”

    אני מתנצל עם פגעתי במישהו.
    Johny K

  2. Johny K says:

    אני רוצה לחדד את הנקודה שלי ממקודם.

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

    אבל מה לעשות SHIT HAPPENS, ולכן יש זליגות בזמנים ובתכולה…

  3. agileman says:

    ג’וני,
    קודם כל, אני לא מסכים עם תפיסת עולמך לגבי מפתחים, אך אני לא הולך לפתוח בוויכוח כי הוא ארוך ומיותר.
    אין לי אלא להסכים שמתכנת יכול אכן להעריך את המשימות שלו, אם הוא כבר עשה משהו דומה, וזאת ברמה מסוימת של אי וודאות, אך אם תקרא את סעיפים 2 + 3 תראה שגם אותם מתכנתים, אם הם בני אדם, לעיתים מעריכים את המשימות שלהם לא נכון, ולא בגלל ש – “Shit happens” 😉 – פשוט כי הם אנושיים.
    סיבות נוספות לבעיות בפרויקטים בפוסט הבא.

  4. נועם says:

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

  5. agileman says:

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

  6. Johny K says:

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

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

    כמו שאמר נועם, חובת ההוכחה עליך.

  7. agileman says:

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

  8. eran says:

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

  9. eran says:

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