זה מתחיל מלמטה

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

אני חושב שהכי אפקטיבי לדבר על ההשקעה הכספית בגיוס: לעיתים, כך נוכחנו לדעת, חיי המדף של מפתח בן דור ה-Y גם ככה קצרים ואתה יכול למצוא את עצמך מפסיד פעמיים בשנה שווי משכורות ניכר על שילוב עובדים. אם גייסת שני עובדים לאותה משרה, על אותה עמדה, בעצם השקעת פעמיים. ואם כל הכשרה של עובד עולה 4 חודשי משכורת (לכל מפתח לוקחים 3 חודשים כדי שייכנס לקצב, ועל זה מוסיפים עוד חודש בסך הכל שמשקיעים בהכשרה שלו. הווה אומר ב-3 החודשים הראשונים 180 שעות. 60 שעות לחודש שהם בערך שני ימים בשבוע, 40% מהזמן) בעבור תפוקה מינימלית, הרי שעבור 2 עובדים שגויסו שווים יותר מחצי שנה של משכורות. אם משכורת חודש היא 10000$, הרי שכמעט 75000$ הושקעו כשהפרודוקטיביות המצרפית של שני המפתחים שווה אולי לתפוקה של מפתח סניור ותיק אחד בחודשיים.

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

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

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

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

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

האפקט ההרסני של חוק פרקינסון על סקראם

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

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

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

בממוצע, חברה שמנהלת אג'ייל טוב אמורה להפסיד שעת עבודת מהנדס בשבוע על שיחות סרק. אם חברה מפסידה שעת עבודת מהנדס ביום, לא בשבוע, המצב גרוע. שעת עבודה היא סטנד-אפ שהתמשך בקבוצה של 6 אנשים, 10 דקות יותר ממה שהיה אמור להמשך. שזה בערך שלושה משפטים מיותרים שנאמרו ושלוש תשובות למשפטים האלה. 20 ימי עבודה בחודש, וזה אומר ש-20 שעות מהנדס הלכו לפח על שטויות.  אם בחישוב גס משכורת של מהנדס לחודש היא 10000$, כך 20 שעות מהנדס בחודש יוצאות בקירוב 1000$ שנעלמים רק בגלל משפט מיותר שנאמר והיה יכול לא להיאמר. ואני לא מדבר בכלל על זמן שהולך לפח בגלל קוד לא קריא והזמן שלוקח לפענח אותו, או בגלל הנחיות ואפיונים לא ברורים שמצריכים ביאורים והבהרות (שזה בקלות יכול לגלוש לעוד, לפעמים, שעתיים ביום לכל חבר צוות, כלומר בכל יום עבודה זורקים לפח משכורת של יום של מהנדס). אני מדבר רק על זמן שנזרק על נושאים טריוויאליים ולא חשובים, שעלו בשיחה רק כי היה לך חשוב להראות שאתה קיים ואתה עושה משהו.

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

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

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

כמו תוכי

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

טסט קייס: צוות שבו אף אחד לא יודע גיט יותר מהפקודות הבסיסיות של commit, pull, push. ואז יש קומיט שגוי, וצריך לעשות revert, ואף אחד לא יודע מתי צריך לעשות rebase כי יש כלל ברזל שלעולם לא עושים ריבייס. או חמור מזה: יש הוראה מלמעלה שעל פיה אף אחד לא עושה merge, חייבים לעשות pull request כדי שרק אדם אחד ימרג'ג' את הקוד. והאדם הזה לא יודע את המשמעות של rebase. ואז יש קונפליקט, והוא תקוע, ומסתכל בסטאק אוברפלואו ומסתמך על המלצות שקיבלו לייקים ופועל לפיהן בלי לדעת באמת מה הוא עושה ואיך יימנע ממקרים כאלה בעתיד.

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

תסמונת הפרה החולבת

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

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

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