OKRs – באזז ניהולי בעולם הסטארט-אפים

מצד אחד, MBO נשמע דבר מאוד טבעי והגיוני.

מצד שני, יש הרבה ארגונים שלא הגיעו לרמה הזאת.

נכון. למתכנת קצת יותר קשה באמת להגדיר MBO איכותי. לראש צוות – זה כבר הרבה יותר הגיוני.

האם  “MBO” זו ממש מתודולוגיה שניתן להקדיש לה יותר מ-5 דקות בשיחת הנהלה? – בהחלט כן. כשעבדתי בסאפ עשו “הטמעה” ל MBO – וזה תהליך שגזל שעות רבות.

התפתחות נוספת בתחום (ב 1981) הייתה ההגדרה של יעדים חכמים (S.M.A.R.T), כלומר: קווים מנחים להגדרת יעדים מוצלחים יותר:

• Specific – מכוונים לשיפור מוגדר היטב וממוקד.
• Measurable – ניתנים למדידה, עדיף בצורה מספרית (אם כי ייתכן גם הערכה של מנהל או מומחה).
• Assignable – שניתן להגדיר במדויק מי אחראי לביצוע
• Realistic – מציאותיים, ולא יעד בלתי-אפשרי. יעד שסביר שעובד מוכשר ישיג אותו.
• Time-related – מוגבל בזמן.

אני מניח שרבים מקוראי הבלוג נתקלו כבר ב Guidelines הללו….

עוד וריאציה דיי מוכרת היא ה KPIs (קיצור של Key Performance Indicator) – שאלו יעדים מספריים בהכרח. לעתים משתמשים במונח לקבוע מדדים ביצוע של משימה (למשל: “שיפור ביצועים ב 20% אחוז בתצורה xyz”), ולעתים בכדי להתייחס ליעדים שנתיים של עובד (למשל: “גיוס 5 עובדים לצוות חדש”).

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

ההתפתחות האחרונה (וה”חמה”) בתחום היא OKR, קיצור של Objectives & Key Results. כמו שנראה מייד, זו התפתחות הגיונית וחיובית. באופן קצת מפתיע אולי, מנהלים נהנים להשתמש בטכניקות “חדשות וחמות” לא פחות ממפתחים התרים אחר הטכנולוגיה “החדשה והחמה” ביותר. מנהלים בהייטק – בכלל ☺

האם MBO וגישות דומות (במידה שהן מיושמות בצורה נבונה) גורמות למהפכה ניהולית? זינוק בביצועי החברות? ייתרון תחרותי חסר תקדים?

אני מניח ש MBO בזמנה, באמת הייתה מהפכה ששינתה הרבה.

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

האם שיפור של 1% בביצועי החברה הוא יעד ששווה השקעה של כמה שעות מכל עובדי החברה? – אני מניח שכן.

אם כן, אם OKR יכול להשיג שיפור אפילו קטן בהתנהלות הארגון – כנראה שיש טעם להשקיע בו.

ל MBO (על גרסאותיה השונות) יש כמובן גם חסרונות, או לפחות סיכונים:

• ברגע שלכל העובדים יש יעדים – כל אחד עוסק ביעדים שלו. נושאים שאינם מכוסים ע”י יעדים עלולים להיזנח, כאשר במצב אחר – היו מטפלים בהם.
• Over-fitting ליעדים הוא כמובן סיכון מוכר. בהקצנה: אני אגייס עובדים תאילנדים שלא דוברים עברית – רק בכדי לעמוד ביעד של גיוס צוות בן 5 עובדים בזמן.
• ככל שסביבת העבודה דינאמית יותר, כך קשה יותר להגדיר יעדים ארוכי טווח איכותיים. לפני שהשגתי את היעד – הצרכים כבר השתנו, ויעדים הקודמים כבר חסרי משמעות.
  • Mitigation מקובל הוא לבצע review ועדכון של היעדים כל פרק זמן, למשל: כל רבעון.
• אנשים נוטים להיזכר ביעדים לקראת סוף התקופה, וכך להזניח אותם לאורך השנה. אם כל אנשי המכירות שלי מזניחים את היעד ונזכרים בו רק בחודש האחרון – אז נפגעתי כחברה, ו Benchmarks בין העובדים לא יפתור את הבעיה.

OKRs הופיעו, ככל הנראה, בפעם הראשונה ב 1995, בספרו של אנדי גרוב (המנכ”ל האגדי של אינטל) “High Output Management”.

לשיטתו, על ארגון לשאול את עצמו כל פרק זמן:

1. להיכן אני רוצה להגיע? (להלן Objectives)
2. איך אדע שאני אכן מגיע לשם? (להלן Key Results)

ואיך אפשר בלי “מחקר מדעי” (סליחה על הספקנות [א]) ש”הוכיח” ש”המעבר ל OKR שיפר ב 8.5% את המכירות של Sears”.
יש מחקרים אחדים, ועבור ארגונים רבים – זו סיבה יותר ממספיקה לאמץ מתודולוגיה. (פשוט ברור שגוגל מצליחה בזכות ה OKR. מנוע החיפוש, ושליטה בשוק הפרסום – הם משניים).

חזון, הוא כלי רב-עוצמה להעביר מסר עמוק והכוונה ארוכה טווח לחברי הארגון.
החזון של חברת דיסני “לגרום לאנשים שמחה” מנחה את העובדים בכל רגע בהחלטות קטנות וגדולות: האם אני גורם לאנשים שמחה (= טוב), או האם אני משבית שמחה (= לא טוב).
באופן דומה, החזון של חברת Dell “לספק טכנולוגיה רלוונטית, עם superb value, ובאיכות מעולה” – גם היא עוזרת לעובדים להתמקד במה חשוב לארגון, לא משנה באיזה תפקיד הם.

חזון הוא סוג של פיצוי (mitigation) לחולשה של יעדים ברורים, קרי MBO, KPIs – שממקדים אותנו במשימה האישית שלנו, שלעתים יהוו סתירה למקום אליו הארגון רוצה להגיע.

היישום

• לשפר דרמטית את הרמה המקצועית בצוות.
• לספק את המוצר A בתאריך d, ובכך לתת ערך ממשי ללקוחות.
• להפסיק להשתמש במערכת x (שהבעיות שלה מוסכמות) – בהנחה שזו עבודה הנדסית מאתגרת.

• איכותי, ומעורר-השראה עד כמה שניתן.
  • יעד כמו: “הפחתת מספר הבאגים ב 10%” הוא לא איכותי ומעורר השראה. “שיפור משמעותי באיכות” – הוא כן.
• מוגבל בזמן. תאריך שהוגדר, או הרבעון.
• ניתן לביצוע ע”י הצוות ללא תלויות משמעותיות אחרות.
  • אם ה delivery תלוי בעבודה משמעותית של צוות אחר – זה לא יעד טוב: כשלון של הצוות השני יגרור כשלון שלי.
  • להסתמך על עובד שלא גויס, או תקציב שלא התקבל עדיין – גם הם הפוכים את היעד לתלוי בגורמים חיצוניים ולא רק מי שקיבל אותו.
• מאתגר!

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

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

למשל: אם היעד שלנו הוא “לספק Continuous Deployment, שיאפשר לארגון לבצע A/B Testing בצורה סדירה”, אזי תוצאות המפתח עשויות להיות:

• Deploy נעשה בממוצע 20 פעמים בשבוע.
• ה Availability של המערכת לא נפגע.
• לפחות 5 Deploys בשבוע הם גדולים מ 20 שורות קוד.

על תוצאות המפתח להיות מאתגרות למדי, אך אפשריות.
כלל אצבע הוא להציב תוצאות מפתח, שבממוצע הציון הצפוי שלהם הוא 5/10. כלומר: ציון 5 הוא ביצוע טוב.

החשיבה מאחורי גישה זו היא:

• לדרבן את האנשים להשיג יותר. הרעיון ש”אם נציב יעד x – נקבל x. אם נציב יעד 1.5x – נקבל 1.2x, וזה יותר!”
• לספק מרחב לזיהוי כישרונות יחודיים. מי שמשיג 9 או 10 – הוא כנראה כשרון יוצא דופן.

נוהל יום ראשון (תרגום מ: “Monday Commitments”)

מומלץ שהמעקב אחר ביצוע תוצאות-המפתח יהיה שבועי. אולי בישיבת צוות, אולי בפגישה 1:1 עם המנהל, ואולי אני-לעצמי (לאנשים שמתנהלים מעצמם). זה אולי נשמע טרחני, אבל אם לא יהיה מעקב צמוד – הפוקוס עלול להתפוגג.

בכל נקודת מעקב כזו מומלץ:

• לבצע הערכה היכן נהיה בעוד חודש.
• לנסות ולהעריך את הביטחון שלנו ביכולת להשיג את תוצאות-המפתח.
• לבדוק “מדדי בריאות” – מה מוראל הצוות? האם יש שחיקה? האם שרפנו קשרים עם קבוצות אחרות?
  • כאשר מתמקדים בביצועים – מדדים חשובים אחרים עלולים להיפגע. לכן ההמלצה היא לייצר לעצמנו 2-3 מדדי בריאות (בחשיבה מה עלול להשתבש), ולבדוק אותם כל פעם בסקירה השבועית.

קבלת שבת (תרגום מ: “Friday Celebrations”)

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

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

מה עם מי שלא מצליח לו? האם אפשר להציג גם אי-הצלחות ולפרק כך קצת מתח? האם זה לא חופף ל Sprint Demo בסקראם?

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

On-Boarding 

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

על כן, ההמלצה היא להתחיל ביעד אחד ברבעון הראשון, ולהעלות משם.
ניסיון לעבור בפעם אחת ל 100% ניהול ב OKRs – עלול להיות חוויה שלילית ושוחקת. במיוחד שמדובר באלמנט שמוסיף לחץ נוסף למערכת.

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

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

סיכום