מנהיגות בהייטק #22—מקינזי והערכת ביצועים

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

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

• בציר אחד יש את רמת המערכת, הצוות, והמפתח.ת.
• בציר השני יש את הערכת התוצרים, הערכת היעילות, והערכת מיצוי היכולות.

כשאתם כותבים מסמך, אני תמיד ממליץ להתחיל בראש ובראשונה בהגדרת היעד של כתיבת המסמך (איזה בעיה אתם מנסים לפתור?), ואז להמשיך בהגדרת קהל היעד של המסמך. באופן דומה, כשאתם קוראים מסמך, חשוב להבין מי קהל היעד של המסמך ואז מה היעד של המחברים. היעד של הדו״ח של מקינזי הוא להגדיל את המכירות של שירותי הייעוץ של החברה בהטמעת מערכות הערכת ביצועים. קהל היעד הוא ההנהלה הבכירה (C-suite) והלא טכנית בחברות בינוניות+. במילים אחרות, הדו״ח הזה לא כתוב בשבילנו.

אז למה בכלל להתעסק אתו? כי יש כאן המון מה ללמוד.

הדו״ח נוגע באתגר אמיתי עם השפעה רבה על מחלקות הפיתוח בחברות השונות. כפי ששיתפתי בעבר, לכל חברה בעולם יש חמישה חלקים בדיוק (ניתן לקרוא עוד באתר של ג׳וש קאופמן):

1. יצירת ערך
2. שיווק
3. מכירות
4. העברת ערך
5. פיננסים

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

אז הנה כמה טיפים.

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

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

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

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

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

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

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

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

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

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

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

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

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

וזהו להפעם 😊.