איך למדוד את מחלקת הפיתוח בצורה אפקטיבית?

בקצרה:

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

בהרחבה:

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

למה בכלל מודדים? (ה- WHY)

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

1. מעקב אחר התקדמות המשימות: בהכי טריוויאלי – איפה אנחנו עומדים במשימה הגדולה, האם אנחנו מתקדמים לפי הקצב שתכננו, האם אנחנו אמורים לעמוד בתאריך היעד שקבענו לעצמנו?
2. שיפור התקשורת והתיאום : מדדים מאפשרים לכל בעלי העניין בחברה לדעת גם על מה עובדים וגם איפה הדברים עומדים מבחינת ההתקדמות ובכך לאפשר שקיפות והיכרות רוחביים לכולם.
3. אבחון בעיות/ לעודד לימוד ארגוני: מתוך התחקור של המדדים אפשר לראות היכן קיימים צווארי בקבוק, היכן דברים נתקעים זמן רב או חוזרים בלופ לנקודת ההתחלה וכו’.
4. הערכת רווחיות פרויקטי פיתוח: לדעת כמה שעות כח אדם הושקעו בכל פרויקט יאפשרו לנו למדוד את הרווחיות של המוצרים יחסית לעלות הכוללת של הפיתוח שלהם.
5. העלאת המוטיבציה של חוקרים ומהנדסים: חוקרים ומהנדסים בדר”כ לא אוהבים שמודדים אותם ואולי בעצם אף אחד לא אוהב שמודדים אותו. אבל זו דרך טובה להציג את התמונה הרחבה יותר של הביצועים של המחלקה והיכולות שלה ולתת מקור גאווה לעובדים.

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

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

מדדים אפקטיביים למדידת ביצועי מחלקת הפיתוח: (ה- WHAT)

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

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

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

1. אפקטיביות, מרעיון לתוצאה – Lead Time: עבדתי פעם עם מישהו שהיה אומר שזה נקרא ToV: Time to Value יעני, כמה זמן לוקח להפוך רעיון לתוכנה אצל הלקוח? אפשר לנתח לעומק על מה הולך הזמן הזה – כמה מהזמן הזה הולך על המתנה לפגישות, המתנה לבדיקות, שינויים בתכולה וכו’. בדרך כלל מחלקים את הזמן הזה לשניים:
   1. מרעיון לפריסה – From Idea to deploy: מהרעיון ועד השלב שבו מעלים את הקוד לשטח.
   2. מפריסה ועד ללקוח – From Deploy to production: משלב העלאה למערכות השטח ועד ללקוח.
2. יכולת תכנון – היבטי קצב והספק:
   1. קצב הצוות – Team Velocity: מדד שאומר כמה “יחידות פיתוח” מספיקים לעשות בשבוע או בספרינט. יש צוותים שמודדים אותם ב – Story Points או בשעות. מדד שנועד לאפשר לצוות לתכנן את עצמו בצורה מדויקת יותר. חשוב ממש שלא להשתמש במדד הזה כדי להשוות בין צוותים או כדי להוות יעד.
   2. מיקוד בתכנון מול ביצוע: בגדול אני חושבת שאפשר פשוט להתמקד בכמה זמן תכננת למשימה מול כמה זמן היא לקחה בפועל. אם מתחקרים ברמה שבועית זה מספק את השיפור ביכולת התכנון בצורה מהירה.
3. היבטי איכות:
   1. באגים “שברחו”- Escaped Bugs: כמה באגים נפתחים ב- Production בזמן נתון, או בזמן מסוים לאחר העלייה לאוויר. אפשר לנתח לפי חומרת הבאגים, או היכולת שלנו למנוע אותם.
   2. קצב סגירת באגים – Open/ Close rages: כמה באגים נפתחים ונסגרים ב- Production בזמן נתון.אחוז הזמן המושקע בבאגים: אחוז הזמן של המהנדסים שמושקע בפתרון באגים ב-Production, לעומת שאר הזמן המושקע בפיתוח חומרים חדשים.

איך מודדים? (ה- HOW)

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

1. כדאי להתבסס על מדדים שאפשר למדוד, בעיקר בהתחלה: ובכל מקרה לא הייתי רוצה בשלבים הראשונים שיהיה יותר משלוש שעות בשבוע של מנהל פרויקטים על הוצאת נתונים מהמערכות.
2. מקור הנתונים: יש פעמים שזה קורה מעצמו בתהליכי העבודה של הצוותים ויש פעמים שצריך להטמיע דרכי עבודה חדשות. צריך להחליט מהם 2-3 המדדים החשובים שדורשים שינוי ולהתעקש על להטמיע אותם. הסיבה לכך היא שמקור החזק ביותר לנתונים הוא מערכות ניהול הפרויקטים שלנו., Grafana ,JIRA, Salesforce, Slack..
3. לא כל הנתונים מדויקים וזה בסדר: כאשר מתחילים למדוד ולהציג מדדים אז אנשים רוצים להצליח ולהתיישר וזה נותן בוסט עצום לרצון של האנשים להציג את הנתונים במערכות בצורה יותר ויותר מדויקת.

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

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

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