-->

יום שישי, 26 באוגוסט 2016

Lean Startup - איך לגדל מוצרים מצליחים?

בספר The Lean Startup, אריק ריס מספר על חברה שהקים בשם IMVU. הרעיון שלה (פלוס מינוס) היה לייצר צ'ט שיש בו Avatar - מן דמות תלת-מימדית מונפשת שמתלווה לשיחה המתהווה ומעצימה את הצד הרגשי של השיחה. ניתן לפתח את הדמות (להלביש אותה, לעשות איתה כל מיני מחוות) כל שהמוצר הוא בעצם חצי צ'ט - וחצי משחק Second Life / The Sims.

שוק ה Instant Messaging (בקיצור IM) היה גדול מאוד ומבוסס באותה התקופה. מכיוון שמדובר במודל של Marketplace (בו הערך של המוצר הוא "כמספר המשתמשים בריבוע") - לא היה טעם להתחיל מאפס: מה טוב Chat Client שאין לי עם מי לדבר בו? האסטרטגיה המבריקה של החברה הייתה למשוך משתמשים בעזרת ה Avatar / הצד המשחקי של הצ'ט - וכך לגרום להם להעביר אט אט חברים לרשת ה IM החדשה.
החברה תייצר Client שיוכל להתחבר לרשתות IM קיימות - כי שם הרי כל החברים שלכם.
שיחה שתתבצע בעזרת שני משתמשים עם ה Client של IMVU - יתווסף עליה מימד ה Avatars.

החברים שאריק התייעץ איתם - התלהבו מן הרעיון. אריק מצא שותפים, כולם אנשי תוכנה מהמעלה הראשונה - והם התחילו לעבוד:
  • מערכת ה Plug-ins לתמיכה ברשתות ה IM השונות התגלתה כמורכבת יותר מהצפוי. 
  • היעד לגרסה הראשונה היה אגרסיבי: כחצי שנה. הצוות התחיל לעבוד +12 שעות ביום על מנת לעמוד ביעד השאפתני.
  • זה לא הספיק, ולכן הצוות החל "לחתוך" פינות רבות במימוש הטכנולוגי ("הרי אנחנו סטארט-אפ").
  • לקראת ההשקה ההרגשה הייתה שאיכות המוצר היא לא-טובה. מה עושים? משחררים בכל זאת, או מקצים עוד זמן לתיקוני באגים? הרי, למכור מוצר מלא באגים - זו דרך מצוינת ליצור שם רע למוצר ולחברה.
  • כנגד ההיגיון הבריא (אריק מספר היום שזה המזל הגדול שלהם), הם החליטו לשחרר את מה שיש להם. גרסה ראשונה יצאה לדרך.
ביום ההשקה הם פתחו את האתר בו מורידים את התוכנה, התחילו לפרסם ברשתות החברתיות ולקשר לדף ההורדה - אבל כלום. אפס הורדות.

(טוב, אופס! הייתה בעיה בכפתור ההורדה.) - מה שתוקן מייד ואז החלו ההורדות: 3, 7, 11, 23, 38, 43, 49, 65, 77, ... וכך המספר עלה. עשרות הורדות, אח"כ כמה מאות - שום דבר שדומה לציפיות על עשרות-אלפי משתמשים.

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

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

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

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

"למה לא?!"
- "אני עדיין לא יודעת אם הרשת שלכם היא קוליקית. להזמין חברה לרשת לא קוליקית - זה פשוט מביך ברמות!!1"

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

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

הם פספסו בהנחות היסוד המהותיות:
  • ההנחה שיהיו משתמשים משכבות גיל שונות. (מה שמשפיע מאוד על המודל העסקי והיכולת לשלם).
  • ההנחה שהתקנה של Plugins היא דבר שמשתמשים יסתדרו איתו לבד. "מה זה פלאג-אין?!" - שאלו רוב המשתמשים.
  • ההנחה שמשתמשים ירצו להזמין חברים שלהם לרשת של IMVU - ובצורה ויראלית.

הסיפור של IMVU יכל להיות עוד סיפור מני רבים של סטארט-אפ שכשל. מה שמיוחד בסיפור הוא מה שהציל את המוצר:
  • מכיוון שהיה מספר מסוים של משתמשים ששיחק עם המוצר (ועדיין לא זנח אותו)...
  • ומכיוון שהמשתמשים לא העזו להזמין חברים לצ'ט...
  • היזמים הוסיפו כפתור בשם "ChatNow" - המאפשר למשתמש אחד לשוחח עם משתמש אקראי אחר. זה היה ניסיון אקראי לייצר קצת תעבורה במערכת.
  • אבל, באופן פלאי כמעט - הרשת החלה להצליח.
  • הדמות שהמשתמש עיצב, ה Avatar, עזרה להפיג את המתח הראשוני עם בן-שיח זר לחלוטין.
  • מסתבר שהמשתמשים לא רצו להתחבר לשירותי IM אחרים או לדבר עם החברים הקיימים שלהם - הרשת שצמחה הייתה רשת לשיחות עם זרים.

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






מתודולוגיית ה Lean Startup


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

מתודולוגית ה Lean Startup היא אחד החידושים המרעננים והחשובים (לדעתי) בעולם התוכנה בשנים האחרונות.


לכאורה, נראה שמדובר בעוד מתודולוגיית Agile.
מדוע אנו זקוקים ל*עוד* מתודולוגיית Agile?? האם לא מיצינו כבר את הכיוון הזה?


עיון בעקרונות ה Agile (ליתר דיוק: Lean [א]) הוא: ״Eliminate waste" - להתמקד בביטול פעולות לא-נחוצות כאמצעי לשיפור הפריון של הארגון.

מהו waste?
  • תכנון לקוי - בואו נשפר אותו.
  • ישיבות ארוכות - בואו נגביל אותן בזמן (timeboxing - רעיון דומיננטי של סקראם).
  • שכבות ניהול מיותרות - בואו נבטל אותן ונעצים את הצוות.
  • באגים שצצים בפרודקשיין - בואו נעשה מאמץ לאתר אותם מוקדם יותר.
  • וכו׳

כל אלה נושאים חשובים וטובים. הם שיפורים חיוביים, אבל הם לא מתמודדים עם "ה waste הגדול מכולם" או ה BWoA (קרי: Biggest Waste of All).

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


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

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

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

במקום זה, יותר יעיל למדוד למה באמת אנשים מגיבים (מעשים > דיבורים) - בעזרת סדרה של ניסויים.





במעט סרקזם, ניתן לומר שאם תשאלו אנשים מה חסר להם בסקראם - הם יובילו אתכם ל LeSS או SAFe [ב], אם תבחנו מה שורש הבעיה של ארגוני-תוכנה - תגיעו ל Lean Startup.



אז מה הוא בעצם ה BWoA?


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

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

קרוב לוודאי שנתקלתם בכמה שכאלו בקריירה שלכם...


"Fail early, Fail fast"

החשבון הוא פשוט:
  • אם השקענו שנה, בפיתוח של מוצר לא מצליח - אזי בזבזנו שנים-עשר חודשי פיתוח!
  • נניח שבעזרת ניהול פרויקט נכון יותר, ניהול ישיבות יעיל, ושלל תהליכים אותו פרויקט - סיימנו את הפרויקט הנ"ל בתשעה חודשים (נניח באופטימיות). אם זה לא פרויקט מצליח - עדיין בזבזנו תשעה חודשי פיתוח!
  • אם השקענו 100,000 שקל אצל מגדת עתידות שאמרה לנו בוודאות שהפרויקט ייכשל - אזי בזבזנו רק 100,000 ש"ח. חודשי פיתוח של צוות פיתוח הם יקרים הרבה יותר! הזמן שהתבזבז - עשוי להיות יקר יותר מכסף.
מכיוון שאין לנו בתעשיית התוכנה מגדת-עתידות אמינה, אנו נשקיע זמן פיתוח בפיתוח של Minimal Viable Product (בקיצור: MVP). המוצר הזה יאמר לנו בהשקעה קטנה ואמינות גבוהה (אם עשינו אותו נכון) - האם המוצר השלם הולך להצליח (ואז שווה להמשיך ולהשקיע בו) או האם עלינו לשנות כיוון משמעותי (מה שנקרא גם "Pivot" - "שינוי ציר התנועה").

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

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





Lean Starup היא מתודולוגיית פיתוח ״רזה״, המבוססת על רעיונות של חשיבה מדעית, המתמקדת בעיקר בשאלה: כיצד נצמצם למינימום את ההשקעה במוצרים/פיצ׳רים לא מוצלחים?

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

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

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

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

דוגמה אהובה היא הסיפור של חברת SnapTax, שביצעה במשך חודשיים וחצי בסוף השנה (תקופת חישוב המס בארה"ב) כ 500 ניסויים שונים על אופן השימוש המוצר שלה - זה אומר כ 11 ניסויים שונים שמתחילים כל יום!
אם היה ספק: רעיון ה Continuous Deployment (בניגוד ל Delivery) - נולד כחלק ממתודולוגית ה Lean Startup: ביצוע ניסויים הוא צורך קיומי של החברה, ולא ניתן לבצע ביצועים ברצף ללא ביצוע שינויים תכופים בסביבת הפרודקשיין. מי שאמור לדאוג לקיום של ה Continuous Deployment הם א
לא המפתחים - אלא ה CEO.

בשלבים הראשונים של המוצר, התהליך הוא תהליך של Pivot (שינוי כיוון מהותי) - אם הניסוי כשל, או Preserve (מעבר לסיכון/ניסוי הבא שאותו נרצה לבדוק) - במקרה של הצלחה.
קודם כל עלינו לדעת שאנו מפתחים משהו שכמות מספיק גדולה של משתמשים באמת תרצה להשתמש בו.

משהו שאין בתרשים: אם ב Agile אנו מתקדמים בכיוון כמעט אחיד ועושים שינויים בעיקר בסדרי העדיפויות / שינויים קטנים במוצר לאורך הזמן, ב Lean Startup המסלול, לפחות בהתחלה, הוא הרבה יותר כאוטי: שינוי הלקוחות שאנו פונים אליהם, ביטול או שינוי מהותי ליכולות עיקריות של המוצר, או אפילו כתיבה מחדש - של חלקים או כל המערכת. זמן פיתוח משמעותי מושקע בניסויים ואיסוף התוצאות שלהם - ולא רק בפיצ'רים. המדד להצלחה הוא לא כמה "Story Points" השגנו בזמן נתון - אלא כמה למידה משמעותית.

״סטארט-אפ מצליח הוא סטראט-אפ שהצליח לבצע מספיק איטרציות בהגדרת המוצר - לפני שנגמר לו הכסף״ -- אריק ריס. (ההדגשה היא שלי)



כיצד נראה תהליך של Lean Startup?


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

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

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

לאחר מכן הוא שכלל את האתר, ועשה A/B Test - "תיאור מוצר א'" מול "תיאור מוצר ב'". "תיאור מוצר ב' מול תיאור מוצר ב'2" - וכו'.

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

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

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


Zappos

עוד סיפור מפורסם של Lean Startup הוא הסיפור של זאפוס - היום חנות הנעליים הגדולה בעולם, עם מחזור מוערך של כ 2 מיליארד דולר בשנה (ב 2009 היא נרכשה ע"י אמזון).

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

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

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

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

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

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







מיתוס המנהיג בעל החזון המושלם.


ההסתייגות הראשונה לרעיונות ה Lean Startup מגיעה מסיפורים על איש אחד: סטיב ג'ובס.

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

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

מה החולשות של המיתוס:
  • הוא מתבסס על הטיות אנושיות, למשל: הטיית השרידות (דוגמה חיה אחת, חזקה פסיכולוגית יותר מסטטיסטיקה של אלפי מדגמים).
  • סטיב ג׳ובס דוגל באסטרטגיה של סיכון גבוה / רווח גבוה:
    • כשהוא המציא את Newton - הוא הימר על הכל והביא את אפל לסף פשיטת רגל.
    • כשהוא המציא את ה iPhone - הוא הימר על הכל, והביא את אפל להצלחה אדירה.
    • על רוב ההימורים הגדולים אנו לא שומעים - כי זה לא מעניין לספר על עוד יזם שכשל.
      אנו שומעים רק על סיפורי ההצלחה (המעטים) - וכך מקבלים תמונה מעוותת של המציאות, שלא משקפת את הסיכון הגדול.
  • גם לו היה מנהיג בעל חזון מושלם - איך תוודאו שהאדם שאתם מתמסרים אליו הוא כזה? שהוא לא סתם עוד אדם כריזמטי עם בטחון עצמי?
למרות שמה שאנשים מסוימים ינסו לטעון, Lean Startup הוא דיי הגישה ההפוכה לגישה בה אפל השיקה כמה מוצרים מאוד מצליחים. לאפל יש מגבלות: היא מייצרת מוצרי חומרה - שבהם קשה מאוד לבצע MVPs (אולי עכשיו, בעזרת הדפסה תלת-מימדית - זה יהיה יותר אפשרי). אפל כאסטרטגיה משקיעה רק במוצרים עם קהל פוטנציאלי מאוד רחב. בשל ההנחה הזו, מפתחי המוצר באפל האמינו שעובדי החברה הם קהל מספיק טוב לקבל ממנו פידבק להשקת המוצר.

יש גם כמה קווי דמיון שניתן למצוא בין הגישה של אפל ל Lean Startup:
  • כשאפל הציגה מוצרים לראשונה, היו להם כמה תכונות פורצות דרך - אבל גם הרבה תכונות מביכות. חשבו על השעון: מה עושים איתו? זהו פסודו-MVP: אפל שחררה מוקדם יותר - על חשבון ליטוש "המוצר המושלם".
    • שחרור ה iPod הראשון רק למשתמשי מק (בעלי חיבור firewire, לא היה לiPod חיבור USB) - עזר לאפל ללמוד הרבה, מקהל מוגבל יחסית - שהם מכירים היטב.
    • ה Clickwheel המפורסם של ה iPad הופיע קודם בדגם ה iPod Mini, ורק לאחר שהוכח כמוצלח - הועבר לדגם הרגיל ממנו היו רוב ההכנסות של אפל.
  • יחסית למוצר חומרה, אפל עובדת ב cycles קצרים: שחרור כל שנה. בכל cycle - יש כמה שיפורים משמעותיים. זה עניין של פוקוס - לעשות כמה דברים אבל טוב, ולא המון פיצ'רים לא-חשובים.

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




ביקורת 


תגובה צפויה להעלאת רעיונות ה Lean Startup היא: "זה נשמע נהדר - אבל זה לא מתאים לנו".

התירוצים הנפוצים הם:
  • כי המתחרים יעתיקו את הרעיון אם נחשוף אותו בניסויים מוקדמים.   
    • תשובה: הם כמעט תמיד מתעלמים ממה שאין לו עדין נתח שוק, ולהעתיק בלי הבנה מעמיקה - זה לרוב לא שווה הרבה. אם ניתן להעתיק את הרעיון בקלות - אז זה יקרה גם אחרי שיצאתם לשוק.
  • כי אנחנו חברה גדולה שחושבת בגדול - ואין לנו זמן ל"ביצוע ניסויים".
    • תשובה: כן, אבל לשרוף שנת פיתוח של 50 מתכנתים יש לנו זמן?
  • כי אין לנו כוח אדם מתאים: יש לנו מתכנתים - לא אנשי מחקר שוק. 
    • תשובה: רבים מהמתכנתים יכולים ללמוד לעשות את זה. זה מעניין, מאתגר, ומאוד מספק.
  • כי שחרור של גרסה מינימלית יפגע בשם הטוב שלנו - אסור ל Brand שלנו להוציא מוצר פחות מ"מענג".
    • תשובה: זה לרוב תירוץ. אפשר להוציא כ"בטא" או "אלפא", אפשר להוציא את הניסוי תחת מיתוג אחר של "חברת-בת לא ידועה".
  • לא יאשרו לנו בחיים לעבוד ככה. יש תהליכים בחברה.
    • תשובה: זו באמת בעיה. בעיה של החברה.
  • זה בכלל לא מתאים לחברות גדולות. זה ה Lean Startup.
    • תשובה: הכל בראש. אם HP וממשלת ארה"ב מסוגלות - אז גם חברה קטנה יותר, של כמה עשרות אלפי עובדים בלבד - מסוגלת.
    • האמת, שהשם Lean Startup הוא לא הכי מוצלח. "Lean Product Incubation" - הוא שם פחות קליט אך יותר מדויק: העניין הוא מוצר חדש בעולם לא מובן - לא גודל הצוות שמפתח אותו. 
    • כן אני אסכים שהסבירות להצלחת מתודולוגיה שכזו בארגון קטן וצעיר - היא גבוהה לאין שיעור מיישום בארגון גדול ומורכב. כן המתודולוגיה הזו מתאימה יותר לסאטרט-אפים.

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

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

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

בכל מקרה, כדאי לזכור שזה לא "הכל או לא-כלום". אפשר להיות מושפעים מרעיונות ה Lean Startup ולהרוויח מהם - גם ללא אימוץ מושלם / קפדני, אולי קיצוני.




סיכום


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

זה מדויק - אבל לא נכון.

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

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

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


שיהיה בהצלחה!



---


[א] - אנשים רבים משתמשים במונחים "Agile" ו "Lean" כמושגים נרדפים - אך יש שוני חשוב בהשפעות והנחות היסוד של כל גישה. 

Lean היא השפעה ישירה של ה Toyota Production System או מה שקרוי Lean Manufactoring - וניסיון לתרגם אותם לעולם התוכנה. Kanban ו Lean Software Development - הם מתודולוגיות לדוגמה, והדובר הלא רשמי שלהם (עד לאחרונה) היו בני הזוג Poppendieck.

 Agile הן סדרת מתודולוגיות שהושפעו באופן עקיף מאותם רעיונות של טויוטה, אך ניסו להגדיר מחדש תהליכים לעולם התוכנה - ללא תרגום ישיר. היישומים המוכרים היום הם SCRUM, XP, ולאחרונה גם SAFe ו LeSS. 


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


יום חמישי, 28 ביולי 2016

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

בשנות ה-50 של המאה העשרים, הציג פיטר דרוקר (אבי הניהול המודרני) - רעיון מהפכני לתקופתו: Management By Objectives.

Management by Objectives (בקיצור: MBO. נקרא לעתים גם MBR) הוא אוסף הרעיונות הבאים:
  • במקום שהמנהל יכוון ("ינהל") את העובד באופן שוטף, משבוע לשבוע - ייקבעו המנהל והעובד כמה יעדים ארוכי טווח לעובד (למשל: יעדים שנתיים), אשר על העובד יהיה לנהל את עצמו ולדאוג לכך שהוא מגיע אליהם.
  • העובד או העובדים יהיו שותפים לקביעת היעדים. אלו יעדים שהם מסכימים לקחת על עצמם (ולא הנחתה של המנהל).
  • היעדים הללו הם יהיו הבסיס להערכת העובדים בסוף התקופה (נאמר: שנה) - יעד מדיד ואובייקטיבי.
  • מכיוון שהמדדים הם מספריים (למשל: שיפור של 15% במחזור המכירות) - ניתן להעריך עובד ע"פ Benchmark מול עובדים מקבילים.
    • הבהרה: העובדים שותפים לקביעת היעדים, עוד אחד יקבע 13% והשני 15%. בכל זאת אם עובד אחד השיג 12% והשני 10% - אזי ברור שלמרות שלא עמד ביעדים שקבע לעצמו - העובד הראשון עדיין עשה עבודה טובה.

מצד אחד, 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. מנוע החיפוש, ושליטה בשוק הפרסום - הם משניים).


OKRs, בבסיס הם שילוב בין הרעיון של MBO לרעיון של חזון ארגוני (המוכר במידה רבה מהספר "לנצח נבנו") + כמה שיפורים.

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

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



היישום


ע"פ OKRs, ההלצה היא לקבוע 3 עד 5 יעדים (ולא יותר!), לתקופה של רבעון (ולא שנה).

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

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

סגירת באגים בצורה אגרסיבית עשויה להראות לגיטימית למי שהיעד שלו הוא "הפחתת הבאגים הפתוחים ב 30%" (ייתכן ב MBO), אך דיי ברור שהיא לא לגיטימית אם היעד הוא "שיפור האיכות".
מדידת הביצועים של העובד, תעשה בהיבט השגת היעדים - ולא רק המדדים.


לכל Objective מומלץ לקבוע 2-3 Key Results.

Key Results (להלן "תוצאות מפתח") הם המדדים, או Milestones - שבעזרתם אנו יכולים לדעת אם אנחנו בכיוון הנכון להשגת היעד.
הם עוזרים לנו להבין שאנחנו בכיוון הנכון ועומדים בלוחות הזמנים (וגם לספק תחושת התקדמות = פידבק), אך הם לא היעד. הם בגדר "תנאי הכרחי, אך לא מספיק".

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

למשל: אם היעד שלנו הוא "לספק Continuous Deployment, שיאפשר לארגון לבצע A/B Testing בצורה סדירה", אזי תוצאות המפתח עשויות להיות:
  • Deploy נעשה בממוצע 20 פעמים בשבוע.
  • ה Availability של המערכת לא נפגע.
  • לפחות 5 Deploys בשבוע הם גדולים מ 20 שורות קוד.
ריבוי תוצאות-המפתח "נועל אותי" בפני סוגים שונים של Overfitting:
  1. אני לא יכול לבצע Deploy ביום - ולטעון שיש לי CD.
  2. אני לא יכול לבצע המון Deploys - אבל לחרב את יציבות המערכת.
  3. אני לא יכול לבצע המון Deploys לא משמעותיים (שינויי הערות, או תיקונים של שורה), ולספר לעצמי שזה CD.

כמו כן, תוצאת-מפתח של "ביצוע לפחות A/B Test אחד בשבוע" היא מאוד רצויה לארגון - אבל לא הוגנת, אם היא לא תלויה רק בי.


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

החשיבה מאחורי גישה זו היא:
  • לדרבן את האנשים להשיג יותר. הרעיון ש"אם נציב יעד x - נקבל x. אם נציב יעד 1.5x - נקבל 1.2x, וזה יותר!" 
  • לספק מרחב לזיהוי כישרונות יחודיים. מי שמשיג 9 או 10 - הוא כנראה כשרון יוצא דופן.
בגוגל, אגב, החליטו שהנורמה תהיה 7/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...


---

[א] במקרה בדקתי, והתוודעתי לכך שהחברה של "ספק סביר" חזרו לשדר. יוהוו!