#34 לי זה עולה יותר

כמה אנשי תוכנה דרושים בשביל להחליף נורה? מה זה חוק הופששטר? מהו כלל ה 20-80 האמיתי? ואיך כל זה קשור לפרקינסון?

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

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

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

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

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

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

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

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

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

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

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

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

כי מה לעשות, זהו כלל ה 80-20 האמיתי: 80% הראשונים של העבודה לוקחים 80% מהזמן, 20% הנותרים לוקחים עוד 80%.

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

---

מתחת לקו: כמובטח, הנה עוד רשימה קצרה של בדיחות נורה על מתכנתים.

אז כמה מתכנתים צריך כדי להחליף נורה שרופה?

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

וכמה בודקי תוכנה צריך כדי להחליף נורה? אפס! "אנחנו רק מוצאים את הבעיות, מישהו אחר אמור לתקן אותן"

[הקרדיט לאתר (הישן) "בדיחות מקצועיות"]