הפוסט הזה נכתב במקור כפוסט לפייסבוק, לקבוצה של מנהלות פרוייקטים ועל כן מנוסח בלשון נקבה.
מוזמנים/ות לקרוא וליישם מכל המינים והתפקידים 🙂
הערכות זמנים (ESTIMATION) או הערכת נקודות (STORY POINTS) נחשבות לחלק מהותי מאד בניהול של פרויקט פיתוח. למרבה הצער, פעמים רבות זוהי דרישה ניהולית שנכפית על הצוות מלמעלה.
כמו כן, יש נטיה לראות בהערכות אלו סימן לארגון אג'ילי, כאילו הן חזות הכל – לכאורה, אם יש הערכות זמן לכל משימה ומשימה, ונשות הפיתוח מעדכנות זאת באופן שוטף >> זה הופך את הצוות להיות אג'ילי.
ובכן, לא בדיוק.
מטרת הפוסט – לנפץ את הפרדיגמה הזו, להציע דרך חליפית ולעודד אתכן לבחון ולנסות בעצמכן כדי להגיע לדרך שמתאימה לכן ולארגון.
הערכת זמנים גוזלת זמן ושודדת פוקוס
כאשר נדרוש מהמפתחות להעריך משימות, הן יעסקו בזה במקום בלחשוב על המשימה עצמה. אפילו שנדמה שזה משהו שלוקח 2 שניות – זה לא. יש לזה מחיר יקר בפוקוס ובתשומת הלב של המהנדסת, במקום לחשוב על הדרישות והבהרות של המשימה, היא עסוקה בלנחש מספר, שישביע את רצון ההנהלה או מנהלת הפרויקט.
בנוסף, אחרי שהתברר שהמשימה לקחה יותר זמן – המהנדסות עסוקות בלתקן את ההערכות האלה ושוב משקיעות זמן יקר שיכול היה כבר להיות מושקע במשימה עצמה.
ומה עם הזמן שלכן מנהלות פיתוח יקרות שצריכות לעקוב אחרי ההערכות הללו, לעשות השוואות, להסביר מדוע ההערכות היו שגויות? ושל ראש הצוות, מנהלת המחלקה וכל השאר… בזבוז נוראי של זמן. כולן עסוקות, אבל הפיתוח לא מתקדם.
הסיבות העיקריות לכך שהערכת הזמנים רחוקה מהמציאות:
- מורכבות המשימה מתגלה ככל שמתקדמים בה. מכירות את זה ש- 80% מהמשימה בוצע בשבועיים וה- 20% הנותרים מתארכים כבר חודש? זה השיקוף של מורכבות המשימה.
לפעמים זה קשור למשימה שלא מוגדרת היטב, definition of done לא מדויק, עמום, לא מדיד ולא בשליטת הצוות. ולפעמים זו פשוט המציאות – אנו עובדות בסביבה של חוסר ודאות, וזו המשמעות, שלא הכל ידוע בנקודת ההתחלה, ומכאן הקושי להעריך את המשימה. - לצוות אין בעלות ואחריות על משאבים שמחוץ לצוות, הנדרשים לביצוע המשימה. לפעמים זה QA, לפעמים זמינות מעבדות או חומרה מסויימת, או אפילו פידבק של Product owner במהלך הפיתוח. לא משנה מה הסיבה לתלות הזו – הצוות הוא לא הבעלים של המשאב, הצוות עוצר ומחכה למשאב ולכן הלו"ז מתארך מעבר ליכולת הצוות להעריך.
- הפרעות – לא צריך להסביר, כל מנהלת פרויקט מכירה את הבקשות הקטנות, הדחופות, המעצבנות, שקשה לסרב להן והורסות כל תכנון מושלם. האם הצוות אחראי להפרעות האלה ויכול למנוע אותן / לצפות אותן / להעריך אותן? ברור שלא.
- שינויי תכולה Content switching – ובעברית פשוטה "זיגזג". כל יומיים משתנה הכיוון או התכולה או אבן דרך להגיע אליה. ככל שהשינויים האלה תכופים יותר, כך יורדת היכולת של הצוות להעריך זמנים.
כתוצאה מהפנית אצבע מאשימה לצוות על הערכות זמנים לא נכונות – הצוות למוד ניסיון, וכולן לוקחות מקדמי ביטחון, מוסיפות buffer ומציגות תאריכי יעד רחוקים. כך נוצר מצב שהלוח מראה כמה באגים קטנים, והערכות להנהלה מדברות על גרסה עוד מספר שבועות 😏.
זהו מעגל קסמים נבזי שמהתל בנו ובנסיון שלנו לצפות את העתיד.
העיסוק בהערכות הזמנים יוצר אשליה של ניהול ולרוב מסתיר את הבעיה האמיתית והיא, שאין תיעדוף ברור של המשימות.
להשקיע בתיעדוף במקום בהערכת זמנים
תיעדוף נכון של משימות פרושו רשימה מדורגת של משימות – ראשונה, שניה, שלישית וכך הלאה, כאשר אין שתי משימות באותו דירוג – זה מאד חשוב. כך נוצרת לנו רשימה סדורה. באנגלית זה נקרא Rank להבדיל מ- Priority.
רשימה כזו יוצרת בהירות ופוקוס: המפתחת מגיעה בבוקר ויודעת בדיוק במה להתמקד. יש לה רק משימה אחת בכל רגע נתון. כשהמשימה הראשונה תסתיים, היא תמשוך מהבקלוג את המשימה הבאה ושוב יש לה רק משימה אחת להתמקד בה. זה מצב מצוין שמונע בלבול והסחות דעת ומאיץ את הפיתוח.
בואו נציץ רגע בעולם תוכן שונה – בית חולים או חדר מיון. 
תארו לעצמכן מה היה קורה אם הרופאות היו עוסקות בהערכת זמנים בחדר מיון… שלא נדע.
אנו יכולות ללמוד הרבה מהאופן שבו מתנהלת העבודה בחדרי מיון – יש שם תהליך רציף של מיון וסידור התעדוף, כל הזמן. בשמו הלועזי Triage – זהו תהליך חכם שמשקלל את העדיפות למתן טיפול לפי חומרת הפציעה וסיכויי ההחלמה (ממליצה מאד לחפש ולקרוא עוד על Triage).
👈 טיפ – איך לייצר הצלחות מהירות quick wins כמנהלת פרויקט?
תדאגי שכל יום, יש לכל אחת ואחד בצוות תיעדוף ברור של משימות – זה עובד כמו קסם.
מי כן עושה הערכות זמנים ולאיזה צורך
אם כבר רוצות לדון במשך זמן של משימה, מי שתדע להעריך משימה, היא מנהלת המוצר / CTO / ראש צוות, או מי שנמצאת בתפקיד של הכנסת המשימות לצוות ומתן הנחיות טכניות.
השאלה על משך הזמן יכולה להתניע שיחה על תכולות עם ה- Product owner, יכולה לסייע "להוריד לקרקע" מנהלות שיש להן נטיה להגדרת דרישות כללית ועמומה, עוזרת לגדר ולתחום את התכולה ומשפרת את תאום הציפיות עבור צוות הפיתוח.
כדאי לתחום משימה בגבול עליון, כדי להבהיר לצוות שלא לגלוש למחוזות שלא התבקשו. מומלץ להכניס זאת לשפה השגורה כחלק מדרישות הפיתוח.
הנה כמה דוגמאות:
- "הפיתוח הזה אמור לקחת 3-4 ימים עד למצב של XYZ שיאפשר בדיקה/פידבק. אם לדעתך זה לא מספיק, בואי נדבר על התכולות".
- "הבאג הזה קריטי, אבל הוא קורה אך ורק אצל הלקוח הזה. לכן בבקשה תקדישי גג שעה לחקור אותו, ולא יותר. תעדכני על הממצאים ולפי זה נחליט האם להשקיע בתיקון ובאיזה תיעדוף".
- "התלונה הזו מצריכה שינוי של נתון ב- DB, סדר גודל של 5 דקות בלבד. במקביל, נפתחה קריאה נפרדת, לפיתוח עתידי שימנע את היוצרות הבעיה מלכתחילה. הפיתוח הזה לא דחוף לעכשיו, הוא יתועדף בבקלוג בין שאר המשימות".
איך נמדוד את ביצועי הצוות בלי הערכות זמנים?
אין קשר בין הערכות זמנים ובין מדידה
כמו כן, לא נמדוד זמני ביצוע של כל משימה ומשימה בנפרד, אלא נחשב את המהירות הממוצעת של הצוות בפרק זמן קבוע – Velocity.
חשוב שפרק הזמן בין המדידות יהיה קבוע, לא משנה מהו פרק הזמן, זה יכול להיות שבוע / שבועיים / ספרינט.
ההבדל העיקרי מגישת ה- Story points המקובלת ב- Scrum, שבמקום למדוד את אורך הדרך באמצעות סיכום Story Points, אנו נספור את מספר המשימות שהושלמו באותו פרק זמן.
כלומר נשתמש ב- Count במקום Sum.
הגודל שיתקבל, זה יהיה מדד המהירות הממוצעת של הצוות.
למשל:
הצוות סיים 4 משימות בשבוע => ננסח זאת Team Weekly Velocity = 4
הצוות סיים 10 משימות בספרינט => ננסח זאת Team Sprint Velocity = 10
וכך הלאה.
חשוב לשמור את המדידות האלה, ולבחון אותן לאורך זמן. הכי פשוט בעזרת אקסל.
איך נדע כמה זמן משימה תיקח?
האמת כואבת – לא נדע.
כך או כך, בין אם נתעסק בהערכות זמנים או לא – לא נדע.
כפי שמוסבר בפוסט, ואתן יודעות זאת מנסיונכן – הערכות זמנים שהצוות עושה לא שוות הרבה.
איך נתכנן קדימה?
זו שאלה מצויינת שאפשר להעמיק בה (אולי על זה יהיה הבלוג פוסט הבא).
עקרון מנחה בתכנון הוא להתבסס על ביצועי העבר – כלומר על המהירות המוכחת של הצוות.
בדומה לתחזית הגעה ליעד של וויז על סמך אורך הדרך יחד עם מאפייני הנהגת. וויז לא שואל את הנהגת כמה זמן יקח לה להגיע ליעד. באנלוגיה, לא נשאל את הצוות כמה זמן יקח לסיים משימה, אלא נבחן מה היתה המהירות הממוצעת בעבר.
כללי אצבע לסיכום:
א. לא לבקש הערכות זמן מהצוות: הצוות עוסק במוצר. אך ורק במוצר. ולא בתכנון קדימה.
ב. תכנון יעשה לרוב על ידי גורם ניהולי עם ראיה רחבה והבנה טכנית. זו יכולה להיות ה- PO, מנהלת צוות, CTO, או אתן מנהלות הפרויקט. לרוב מי שעוסקת במדידה ובקרה, מעורבת גם בתכנון.
ג. נחשב וגם נציג באופן שוטף את נתוני הביצוע בפועל (ולא את ההערכות) – נשתמש במספר משימות שהושלמו כמדד "דרך" ומספר משימות שהושלמו חלקי הזמן כמדד מהירות.
מותר לנסות בבית:
יתכן שלחלק מכן הגישה הזו נראית אינטואטיבית ולאחרות זה ישמע כמו רעיון מהפכני וקצת יותר קשה לעיכול.
הפעם הראשונה בה השתמשתי בספירה של משימות שהושלמו, במקום בהערכות זמנים או story points היתה במחלקת פיתוח של כ- 30 איש.ה. התמקדנו במדידה והצגה של ה- Velocity בפועל, וקצב הפיתוח הלך והשתפר כל הזמן.
היום, לאחר שנים של ניסיון, הדבר הראשון שאני עושה כשנכנסת לתפקיד – הוא להפסיק עם הערכות, ולהעיף את השדה הזה בכלל מהלוח, אם זה JIRA או כל מערכת אחרת. במקום זאת, אני מחשבת ומציגה באופן שוטף את מהירות הצוות.
אני מקווה שבעקבות הפוסט, תרצו גם אתן לעשות ניסוי מבוקר (Experiment) לפחות באחד הצוותים או הפרוייקטים שלכן.
ניתן לעשות זאת בהדרגה – אל תפסיקו עדיין עם ההערכות הנהוגות אצלכן, תתחילו מהיום למדוד ולהציג את ה- Velocity האמיתי. אתן תראו איך בהדרגה ירד הפוקוס מהערכות הלא אמינות – ותהליכי קבלת ההחלטות יסתמכו יותר ויותר על המהירות בפועל, עד שתרגישו בטוחות להפסיק להשקיע בהערכות זמנים.
מוזמנות ומוזמנים להעלות כאן תגובות ופידבק על נושא הערכות הזמנים.
אשמח לשמוע על חוויות שלכם/ן בשימוש במדד המהירות בפועל במקום בהערכות זמנים.
ניתן לשלוח לי הודעה דרך המסנג'ר בלינקדאין.
בהצלחה!
שרון