מה זה OKR? הסבר פשוט + כמה משרות פתוחות בישראל

OKR היא שיטה להגדרת יעדים שמורכבת משני חלקים: Objective - מטרה איכותית שמסבירה לאן רוצים להגיע, ו-Key Results - שתיים עד ארבע תוצאות מדידות שמעידות שהגענו. בלוח HiTakeJob פתוחות כרגע 81 משרות בקטגוריית ניהול מוצר, 26 שמזכירות Agile ו-26 שמזכירות Jira.

המבנה - ואיפה טועים בו

המטרה עונה על "לאן"; התוצאות עונות על "איך נדע". הטעות הנפוצה היא להפוך את התוצאות לרשימת משימות.

ניסוח חלש	ניסוח טוב
"להשיק את מסך ההרשמה החדש"	"שיעור השלמת ההרשמה יעלה מ-X ל-Y"
"לכתוב שלושה מאמרים"	"תנועה אורגנית לעמודי המוצר תגדל ב-Z%"
"לשפר את הביצועים"	"זמן טעינה באחוזון 95 יירד מתחת ל-N"

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

איך זה אמור לעבוד

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

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

למה זה נכשל ברוב הארגונים

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

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

איך זה נראה כשזה עובד

דוגמה לצוות מוצר ברבעון:

• מטרה: משתמשים חדשים יגיעו לערך הראשון מהר יותר.
• תוצאה 1: שיעור המשתמשים שמשלימים את התהליך הראשוני יעלה מ-X ל-Y.
• תוצאה 2: הזמן החציוני עד לפעולה המשמעותית הראשונה יירד מ-A ל-B.
• תוצאה 3: שימור בשבוע השני יעלה בנקודות אחוז מוגדרות.

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

איך מנסחים תוצאה מדידה

נוסחה פשוטה שעובדת: מדד, מאיפה, לאן, עד מתי. "שיעור השלמת ההרשמה יעלה מ-40% ל-55% עד סוף הרבעון" מכיל את כל הארבעה; "לשפר את ההרשמה" אינו מכיל אף אחד.

שלוש בדיקות לפני שמאשרים ניסוח:

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

מה ההבדל מ-KPI

	OKR	KPI
מה מתאר	מה רוצים לשנות בתקופה	מה מודדים באופן שוטף
אופק	רבעון או שנה	מתמשך
אופי	שאפתני, לא תמיד מושג	יציב, מצופה לעמוד בו
דוגמה	העלאת שימור מ-X ל-Y	זמינות המערכת

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

מאיפה השיטה הגיעה ולמה היא התפשטה

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

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

מה זה אומר לעובד

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

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

שאלות נפוצות

כמה יעדים לקבוע?

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

מה אחוז השגה נחשב טוב?

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

האם זה מתאים לצוותי תשתית?

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

מי קובע - ההנהלה או הצוותים?

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

מה עושים כשיעד הופך ללא רלוונטי באמצע?

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

כל כמה זמן בודקים אותם?

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

האם כל צוות צריך יעדים משלו?

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

האם זה מתאים לחברה קטנה?

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