- במקום שהמנהל יכוון (“ינהל”) את העובד באופן שוטף, משבוע לשבוע – ייקבעו המנהל והעובד כמה יעדים ארוכי טווח לעובד (למשל: יעדים שנתיים), אשר על העובד יהיה לנהל את עצמו ולדאוג לכך שהוא מגיע אליהם.
- העובד או העובדים יהיו שותפים לקביעת היעדים. אלו יעדים שהם מסכימים לקחת על עצמם (ולא הנחתה של המנהל).
- היעדים הללו הם יהיו הבסיס להערכת העובדים בסוף התקופה (נאמר: שנה) – יעד מדיד ואובייקטיבי.
- מכיוון שהמדדים הם מספריים (למשל: שיפור של 15% במחזור המכירות) – ניתן להעריך עובד ע”פ Benchmark מול עובדים מקבילים.
- הבהרה: העובדים שותפים לקביעת היעדים, עובד אחד יקבע 13% והשני 15%. בכל זאת אם עובד אחד השיג 12% והשני 10% – אזי ברור שלמרות שלא עמד ביעדים שקבע לעצמו – העובד הראשון עדיין עשה עבודה טובה.
התפתחויות נוספות
- Specific – מכוונים לשיפור מוגדר היטב וממוקד.
- Measurable – ניתנים למדידה, עדיף בצורה מספרית (אם כי ייתכן גם הערכה של מנהל או מומחה).
- Assignable – שניתן להגדיר במדויק מי אחראי לביצוע
- Realistic – מציאותיים, ולא יעד בלתי-אפשרי. יעד שסביר שעובד מוכשר ישיג אותו.
- Time-related – מוגבל בזמן.
- ברגע שלכל העובדים יש יעדים – כל אחד עוסק ביעדים שלו. נושאים שאינם מכוסים ע”י יעדים עלולים להיזנח, כאשר במצב אחר – היו מטפלים בהם.
- Over-fitting ליעדים הוא כמובן סיכון מוכר. בהקצנה: אני אגייס עובדים תאילנדים שלא דוברים עברית – רק בכדי לעמוד ביעד של גיוס צוות בן 5 עובדים בזמן.
- ככל שסביבת העבודה דינאמית יותר, כך קשה יותר להגדיר יעדים ארוכי טווח איכותיים. לפני שהשגתי את היעד – הצרכים כבר השתנו, ויעדים הקודמים כבר חסרי משמעות.
- Mitigation מקובל הוא לבצע review ועדכון של היעדים כל פרק זמן, למשל: כל רבעון.
- אנשים נוטים להיזכר ביעדים לקראת סוף התקופה, וכך להזניח אותם לאורך השנה. אם כל אנשי המכירות שלי מזניחים את היעד ונזכרים בו רק בחודש האחרון – אז נפגעתי כחברה, ו Benchmarks בין העובדים לא יפתור את הבעיה.
עולם חדש מופלא
- להיכן אני רוצה להגיע? (להלן Objectives)
- איך אדע שאני אכן מגיע לשם? (להלן Key Results)
- פרסום בביזנס אינסידר אודות גוגל ב 2014
- פרסום הטכניקה ב Re:Work (האתר של גוגל לשיתוף טכניקות ניהוליות)
- בפרסומים רבים לאחר מכן, גוגל (וחטיבות בה, כגון YouTube) מוזכרות תכופות כ Case Study.
יש מחקרים אחדים, ועבור ארגונים רבים – זו סיבה יותר ממספיקה לאמץ מתודולוגיה. (פשוט ברור שגוגל מצליחה בזכות ה OKR. מנוע החיפוש, ושליטה בשוק הפרסום – הם משניים).
חזון, הוא כלי רב-עוצמה להעביר מסר עמוק והכוונה ארוכה טווח לחברי הארגון.
החזון של חברת דיסני “לגרום לאנשים שמחה” מנחה את העובדים בכל רגע בהחלטות קטנות וגדולות: האם אני גורם לאנשים שמחה (= טוב), או האם אני משבית שמחה (= לא טוב).
באופן דומה, החזון של חברת Dell “לספק טכנולוגיה רלוונטית, עם superb value, ובאיכות מעולה” – גם היא עוזרת לעובדים להתמקד במה חשוב לארגון, לא משנה באיזה תפקיד הם.
חזון הוא סוג של פיצוי (mitigation) לחולשה של יעדים ברורים, קרי MBO, KPIs – שממקדים אותנו במשימה האישית שלנו, שלעתים יהוו סתירה למקום אליו הארגון רוצה להגיע.
היישום
- לשפר דרמטית את הרמה המקצועית בצוות.
- לספק את המוצר A בתאריך d, ובכך לתת ערך ממשי ללקוחות.
- להפסיק להשתמש במערכת x (שהבעיות שלה מוסכמות) – בהנחה שזו עבודה הנדסית מאתגרת.
- איכותי, ומעורר-השראה עד כמה שניתן.
- יעד כמו: “הפחתת מספר הבאגים ב 10%” הוא לא איכותי ומעורר השראה. “שיפור משמעותי באיכות” – הוא כן.
- מוגבל בזמן. תאריך שהוגדר, או הרבעון.
- ניתן לביצוע ע”י הצוות ללא תלויות משמעותיות אחרות.
- אם ה delivery תלוי בעבודה משמעותית של צוות אחר – זה לא יעד טוב: כשלון של הצוות השני יגרור כשלון שלי.
- להסתמך על עובד שלא גויס, או תקציב שלא התקבל עדיין – גם הם הפוכים את היעד לתלוי בגורמים חיצוניים ולא רק מי שקיבל אותו.
- מאתגר!
מדידת הביצועים של העובד, תעשה בהיבט השגת היעדים – ולא רק המדדים.
לכל Objective מומלץ לקבוע 2-3 Key Results.
הם עוזרים לנו להבין שאנחנו בכיוון הנכון ועומדים בלוחות הזמנים (וגם לספק תחושת התקדמות = פידבק), אך הם לא היעד. הם בגדר “תנאי הכרחי, אך לא מספיק”.
ריבוי תוצאות-המפתח, שניים-שלושה ולא אחד – אמורים לצמצם את הסיכוי ל Overfitting. שאנחנו מביאים מדד אחד למקסימום (כי זה היעד), ובדרך פוגעים במדדים אחרים.
למשל: אם היעד שלנו הוא “לספק Continuous Deployment, שיאפשר לארגון לבצע A/B Testing בצורה סדירה”, אזי תוצאות המפתח עשויות להיות:
- Deploy נעשה בממוצע 20 פעמים בשבוע.
- ה Availability של המערכת לא נפגע.
- לפחות 5 Deploys בשבוע הם גדולים מ 20 שורות קוד.
- אני לא יכול לבצע Deploy ביום – ולטעון שיש לי CD.
- אני לא יכול לבצע המון Deploys – אבל לחרב את יציבות המערכת.
- אני לא יכול לבצע המון Deploys לא משמעותיים (שינויי הערות, או תיקונים של שורה), ולספר לעצמי שזה CD.
על תוצאות המפתח להיות מאתגרות למדי, אך אפשריות.
כלל אצבע הוא להציב תוצאות מפתח, שבממוצע הציון הצפוי שלהם הוא 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.
סיכום
סה”כ OKRs נראה מנגנון או שיטה שיש בהם הרבה היגיון.
האם OKRs מתאימים יותר לאנשי מכירות מאשר מתכנתים? אולי. מצד שני יש הרבה חברות תוכנה שמאמצות את השיטה.
האם OKRs מתאימים יותר לראשי צוותים או צוותים מאשר מתכנתים בודדים? אני חושב שכן, אבל אולי אני טועה.
בד”כ ב MBO וב OKR יש יעדים ארגוניים, מחלקתיים, קבוצתיים, צוותים, ואישיים – וכדומה (תלוי במבנה הארגון).
אני לא אחזור שוב, על ההמלצה הגורפת שלי לקחת כל כלי בפרופורציה, ולהתאים אותו לארגון וצרכיו. (אופס. חזרתי על זה שוב!).
שיהיה בהצלחה!
—
טיפים לאימוץ OKRs מחברות מובילות:
https://www.wrike.com/blog/12-okr-tips-google-linkedin-twitter-intel
בת’כלס, רוב העצות הללו טובות, באותה המידה, לאימוץ CI, סקראם, או MBO…
—
[א] במקרה בדקתי, והתוודעתי לכך שהחברה של “ספק סביר” חזרו לשדר. יוהוו!
תודה על מאמר מרתק ומעשי!!
שלום!האם אתה מכיר יועצים ישראליים ליישום OKR בארגוני מערכות מידע? ליישום OKR בכלל?תודה!