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.

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

על תפקיד ה Product Owner והשפעתו על הארכיטקטורה

בסקראם, ה Product Owner (בקיצור PO) נדרש למלא 2 תפקידים שונים בתכלית:

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

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

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

ממש פיצול אישיות!

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

שייך לסדרה: אג’ייל – מתודולוגיות פיתוח רזות

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

בעוד ה PO חובש את מגבעת המרחבים, התמונה הראשונה המתגלה לעיניו על המוצר היא משהו כזה:

אקסל כ”מוצר עוצמתי ורב יכולות עבור המשתמש המקצועי”. מקור: http://nizagreen.blogspot.co.il/2012/01/partes-de-excel.html

או אולי משהו כזה… (עבור ה PO בעל הנטיות השיווקיות):

“אקסל מוכן להשקה”. מקור: מייקרוסופט

“Begin with the end in mind” היא אחת העצות שנותנים למנהלי מוצר בכדי שיהיו יעילים.

תחת הכובע של בוב הבנאי, התמונה הראשונה שעל ה PO לראות צריכה להיות משהו כזה:

היכולות הבסיסיות ביותר באקסל, מפורטות ומדויקות. מקור: וויקיפדיה.

האם זה אפשרי? האם אדם אחד יכול לעשות כזה “סוויץ'” בנקודות המבט? בואו נניח שכן.

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

מה יקרה אם יהיה לנו ״איש חזון ושיווק״ טוב, שלא יחבוש את ״קסדת בוב-הבנאי״?

בואו ניקח לדוגמה סיפור בו אנו רוצים להוסיף למוצר שלנו יכולת חדשה: בדיקת איות.
ה PBIs[ב] של היכולת, כפי שהוגדרו על ידי ה׳ PO, נראים כך:

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

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

שאלה: בהנחה שיש לצוות יכולת לבצע את כל 9 ה PBIs בוודאות, האם יש משמעות לסדר של ה PBI שהוא מגיש?

תשובה: בהחלט כן! לסדר בו יגיש ה PO את ה PBIs לצוות יש השפעה ניכרת על התוצאה הסופית מבחינת ארכיטקטורה ואיכות הקוד.

אנו נוגעים כעת במרכז העצבים של מתודולוגיות ה Lean / Agile.

על קביעת העדיפויות

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

מצד שני, אם ה PBI הראשון ב backlog יהיה: “כמשתמש, אני רצה שבדיקת האיות תהיה מהירה, תוך כדי הקלדה” (= שיפורי ביצועים) – איך יוכל צוות הפיתוח לגשת למשימה? יהיה עליו לעשות שיפורי-ביצועים, אבל למה? למשהו שעוד לא קיים? למשהו שעוד לא ברור כיצד הוא יעבוד ומה הוא יעשה?!

זכרו את הקונטקסט: בסקראם, כולם נמצאים בריצה מספרינט לספרינט. ברוב הפעמים, לא יהיו הגדרות מדויקות של PBIs, ולא יהיו UI Mockups מוכנים אלא אם זה PBI שצפוי להתממש בספרינט הקרוב. כולם עובדים “Just-In-Time”.

הנה תוצאה אפשרית וסבירה למצב הנ”ל:

המפתחים יפתחו מנגנון Cache. כי cache = ביצועים.
כיוון שהם לא יודעים מה תהיה התנהגות הריצה של מנוע בדיקת האיות, ואלו תבניות התנהגות הוא יכתיב ל Cache – הם יוכלו לכתוב רק Cache “גנרי”. כזה שעושה הכל “בסדר”, אך לא מצטיין באף תסריט ספציפי.
סביר אפילו, שעבור הרגשת הביטחון שה Cache בסדר (“!Done means Done”) יפתחו אותו קצת אקסטרה – רק כדי “להרגיש בטוחים”, וללא קשר לידע קונקרטי.
אם נקביל תהליך זה להתאמת מבנה-נתונים לבעיה, אזי על צוות הפיתוח לבחור מבנה נתונים לבעיה שלא הוגדרה. כיצד בוחרים מבנה נתונים כזה? מחפשים כנראה הרבה (O(1 – אולי HashTable שמאונדקס כפול ברשימה-משורשרת. ברור שזה מבנה נתונים שאינו “גרוע” למקרים רבים – אך כנראה שגם לא אופטימלי לכמעט אף מקרה.

מה לא היה בסדר? ה PO שם במקום הראשון את הדבר שמרקטיאלית הוא החשוב ביותר – זה נשמע הדבר נכון לעשות.
ה PO גם לא יכול היה לספק Functional Spec מפורט להכל מראש – זה לא Waterfall.

כלומר: ה PO יכול “לעשות הכל ע“פ הספר” – ועדיין להגיע לתוצאה לא-טובה.

“Amplify Learning / Amplify Feedback”

אם נחזור לעקרונות ה Lean, ניזכר שאחד מעקרונות היסוד הוא “הגבר את הלמידה” – זהו עקרון מרכזי בעולם האג’ייל[ג].

בעת בניית וסידור ה Backlog, על ה PO לחבוש את “קסדת בוב-הבנאי” ולקחת בחשבון גם שיקולים של בניית מוצר: מה הגיוני לבנות לפני מה? היכן ישנן שאלות מהותיות (טכנולוגיות) פתוחות – שאם נתקוף אותן קודם לכן נוכל לייצב טוב יותר את ארכיטקטורת המערכת.
תזכורת: ב”מפל המים”, החופש המלא לקבוע את סדר הפיתוח היה בידי צוות הפיתוח. מנהל המוצר העביר “מסמך דרישות” והוא נפגש עם הצוות לאחר שנה לראות את התוצאות. צוות הפיתוח היה מודע לאספקטים הטכנולוגיים ויכול היה לקבוע סדר הגיוני של פיתוח.
לרוע המזל, שיטת מפל המיים, דווקא בנקודה זו, לא עבדה כ”כ יפה: כמעט תמיד גוף הפיתוח לא סיים לממש את כל הדרישות ולעתים נוצר מצב בו פ’יצר משני פותח במלואו, בעוד פ’יצר מרכזי וחשוב – נשאר בחוץ.

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

להלן 2 כללים שיכולים לעזור ולהנחות כיצד לבנות Backlog שמאפשר גדילה בריאה (טכנולוגית) של מוצר. כמובן שה PO יכול להעזר למשימה זו בפיגורה טכנולוגית.

חתרו למשהו מינימלי ועובד, ורק לאחר שהוא עובד – חזרו ועבו (מלשון עיבוי) את הפ’יצר.

מי שבא מרקע של מדעי המחשב בוודאי זוכר את האלגוריתמים לסריקת גרף: BFS ו DFS. בכדי “לגדל מערכת” באג’ייל אנו נרצה בבירור לעשות DFS (להגיע ל”משהו עובד” מהר ככל האפשר) ולא BFS (לעבוד שכבה שכבה ולסיים עם כולן בו-זמנית).

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

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

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

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

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

הנה, כך אנו רוצים שבדיקת האיות תראה. אופס – וצריך גם “ignore”. האם אתם רוצים לגלות זאת לפני, או אחרי שכתבתם את כל הקוד?

הגדירו Maximum Learning PBIs – ויישמו אותם ראשונים
ה PBIs מהם נלמד הכי הרבה הם לרוב כאלו שכוללים UI.

מדוע? “תמונה אחת שווה אלף מילים”. כבני אדם, אנו יכולים להפיק מהגדרות ה UI הבנה טובה יותר של הדרישה מאשר מהתיאור המילולי שלה. אפילו ה PO בעצמו יתגבש טוב יותר – אם הוא יעבוד עם איש ה UX בשלב מוקדם להגדיר את ה User Interaction. בעיות רבות עלולות לצוף באופן זה בשלב מוקדם.
במערכות ללא UI, כגון שרתים – יהיו אלו הנתונים. “נתונים לפני” ו “נתונים אחרי” או “מה נכנס” מול “מה יצא”. התבוננות בנתונים ראליים, בעלי משמעות – שווה יותר מעשרות מצגות ופגישות הדנות ב”כוונות” וב”המוצר – לאן?”. פשוט אספו נתונים ראליים שאתם רוצים שהמערכת שלכם תעבד והציגו אותם.ב”מפל המים” לימדו אותנו שאי אפשר לכתוב UI לפני שהשירותים שמאחוריו כבר כתובים ועובדים. בואו נתקן אמירה זו: לא ניתן לסיים לכתוב את ה UI לפני שסיימנו לכתוב את השירותים שמאחוריו, אבל אפשר להתחיל.
UI שבו רוב הכפתורים הם disabled – הוא התחלה סבירה על מנת להגביר את הלמידה. כיתבו קוד שמציג התנהגויות מרכזיות שהוגדרו מראש, אפילו בצורה hardcoded, ועליתם מדרגה ברמת הלמידה שניתן להשיג בשלב מוקדם זה.

UI יוצר דיון וגורם לאנשים להביע דעה / להבין / להעלות בעיות.
ה UI ישתנה בכל מקרה – עדיף להתחיל את סבב השינויים עוד לפני שסיימנו לכתוב את כל המערכת שתומכת בו.
UI הוא “הקשר עם הלקוח/משתמש”. קשר שממנו כל ההתנהגויות האחרות נובעות. שינינו את החוזה מול המשתמש? סביר להניח שכל המערכת תושפע מכך.

הערה: כל אלה נכונים, באין UI, גם לנתונים איכותיים.

כמובן שיהיו אנשים שיתנגדו לגישה זו: “למה לעשות UI בכאילו? למה לכתוב סימולציה hard-coded רק כדי למחוק אותה בספרינט הבא?”.

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

תרגיל מחשבתי: גישה כנגד גישה
בתרגיל המחשבתי שמוצג בתמונות הבאות, ניתן לראות התפתחות אפשרית של מוצר בשני מקרים:

אנו עובדים תחת הנחות מסורתיות של “מפל המים” / BFS: קודם נסיים את התשתיות – ואז נגיע בסוף ל UI.
חתירה, מרבית, ל End 2 End flow – שגם מתחילה מהUI.

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

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

לחצו על התמונות להגדלה.

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

אל מול:

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

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

—-

[ב] Product Backlog Item – יחידת עבודה לספרינט עבור הצוות או חלקים ממנו.

[ג] תוכלו לקרוא על עקרון זה ואחרים בפוסט “קיצור תולדות הסקראם – חלק 2” בסדרה זו.

סדרה: Agile (מתודולוגיות פיתוח רזות)

ישנם חילוקי דעות לגבי מתודולוגית הפיתוח החדשה יחסית “סקראם” (SCRUM): “שווה” או “לא-שווה”?כנראה שאין ויכוח על כך שמתודולוגית הסקראם שינתה את תעשיית התוכנה ללא היכר – שינוי בלתי-הפיך:

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

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

נתקלתי ברעיונות האג’ייל לראשונה בשנת 2002, עוד בתקופת האוניברסיטה, בעת שמנחה הפרויקט שלנו דרש מאיתנו לעבוד ב Extreme Programming – קיצוני למדי לאותה התקופה, אולי בכלל. רעיונות אלו טלטלו אותי והשפיעו עלי עמוקות.

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

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

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

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

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

קיצור תולדות הסקראם – חלק ב’
בעוד חלק א’ הוא יותר סיפורי – חלק ב’ מתמקד בעקרונות עצמם, כפי שהושמו ע”י טויוטה וה TPS.
עקרונות אלו נקראם Lean או Lean Manufacturing – סקראם הוא רק תרגום שלהם, לעולם התוכנה.

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

סקראם – על חודם של שני אנשים
בואו נדבר ת’כלס: סקראם כולל הרבה רעיונות / כללים, אבל מה באמת הכי חשוב?
אם אנו רוצים להתמקד ברעיון אחד או שניים – מה הם צריכים להיות?

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

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

על יזמות ואמונה

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

ישנו בלבול עמוק בין 2 סוגים של מודלים עסקיים:

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

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

מודל קיצוני (מודל השורטיסט) – מודל זה מבוסס על הימור בסיכון גבוה, וסיכוי נמוך להצלחה מטאורית. השורטיסט יאכיל את הוריו בקוקיז מאמסטרדם, יקבל את הסכמתם למשכן את ביתם – וילך להשקיע [א] את הכסף.
בגרסה המוצלחת הוא ישקיע ב\”אפל\” או פייסבוק ב 2007 (אין לי שום מושג מה היא השקעה נבונה ב 2012). בגרסה הפחות מוצלחת הוא ישקיע בשוק הטקסטיל כי \”המחירים ברצפה ומכאן הם יכולים רק לעלות!\”.

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

סאנסה: מאמינה. מקור: wallpapers.com

הטיית השרידות

באנגלית: Survivorship Bias. דוגמה טובה להטיית השרידות היא ביצועים של קרנות נאמנות. אם תשבו עם יועץ השקעות, קרוב לודאי שהוא יציג בפניכם מספר של קרנות בעלות ביצועים יפים ועוד כמה \”חדשות\”. התחושה היא טובה – \”הנה זו הרווחיה 5% וזו 7% – בממוצע של ארבע שנים. קרן נאמנות היא רווח בטוח!\” – אתם עלולים להסיק.
מה שלא מספרים לכם היא שכל קרן שביצועיה לא היו טובים (נאמר 3% ומטה) – נסגרת ונפתחת בשם חדש, כך שההיסטוריה הכושלת שלה \”נמחקת\”. אתם רואים מדגם לא מייצג של \”הקרנות השורדות\” ויכולים להסיק, בצורה שגויה, שאתם יכולים להניח על ממוצע ביצועים של 6% בשנה, מכל קרן כלשהי. כשמציגים בפניכם נתונים, נסו לשאול את היועץ כיצד יש כ\”כ הרבה קרנות \”חדשות\”, ללא נתונים היסטוריים משמעותיים…
אין שום סיבה להניח שקרנות שהצליחו במשך 4 שנים – ימשיכו להצליח בהמשך. סביר יותר שהן מהמרות עם סיכון בינוני+, וביום שהם יתחילו להפסיד – הן ימחקו ויופיעו בשם חדש.

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

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

סינדרום \”סאנסה\”

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

אם מר צוקרברג מספר לכם ש\”בפייסבוק לא ניסינו לעשות עסק – רק עשינו מה שכיף לנו\” – אוי לכם אם תסיקו ש\”רק לעשות כיף\” הוא המתכון להצלחה. גוגל מאפשר לעובדיה לעבוד 20% על נושא לבחירתם. היא אמנם חברה חדשנית מאוד – אך את הכסף שלה היא עושה מעובדים שעבדו ב 120% על מטרה מוגדרת היטב.

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

רוב התקשורת, והראיונות, שאנו סופגים מחברות עסקיות מצליחות הם יח\”צ. יש להן אינטרס ברור.

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

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

הספר Good to Great בחר בכמה מהחברות המצליחות ביותר בתקופה וניסה לזהות מה המכנה המשותף להן. דורות של מנהלים למדו שעליהם לנהל חברה כמו \”קיפוד\” ולא כמו \”שועל\” – ושורה של חוקים אחרים. עצות של מצליחנים. למרבה הצער, בשנים לאחר פרסום הספר, רוב החברות שבמדגם ירדו בהצלחתן וחלקן פשטו רגל. הייתה פה הטיית השרידות, לכל הפחות.

מקור: https://hbr.org/2009/04/are-great-companies-just-lucky

דברי סיכום

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

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

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

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

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

אם אתם רוצים לדעת איך עושים את זה – כדאי שתכירו את ה \”Lean Start-up\”, אחד הדברים המעניינים שמתרחשים פה בשנים האחרונות.

אני אנסה בפוסטים הקרובים לעסוק ב Lean Startup. אני מסתובב מסביבו כבר זמן רב [ב] – והגיע הרגע לגשת אליו ישירות.

כל טוב.

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

—-

[א] בעברית תקנית, \”להמר\” היא המילה הנכונה לתיאור מצב זה.

[ב] פוסטים קודמים מסביב לנושא:

[ג] ע\”פ הספר היא קצת פחות תמימה.