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.

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

GOTO; Berlin 2014 – רשמים נוספים

הנה תקציר של עוד כמה sessions מעניינים מהכנס:

שימוש ב Lean UX בחברת Carbon Five

Carbon Five זו חברת תוכנה (נחשבת?) שעובדת על פרויקטים ולא מוצרי מדף. הם אימצו וערבבו את מתודולוגיית ה Lean UX עם Agile Development, שהתרחבו לווריאציה משלהם.

החברה מספקת שירותים רחבים מניהול מותג, פיתוח תוכנה, UX / visual design, ועד ל Operations של הפתרון.

עקרון תרבותי חשוב אצלם היה לשבור את ה \”מסגרות התפקיד\”. עדיין יש PO, יש מעצב, ויש מתכנת. אבל מעצב, אם הוא מרגיש נוח עם CSS (בערך כ 50% אצלם הם כאלה) – יכול לדחוף שינויים ב CSS ישירות ל Git.
PO יכול לפתח, ומפתח יכול להציע שיפורי UX. כל אחד מוזמן לתרום בכל מקום בו הוא יכול – תוך שכללי הארגון מעודדים עובדים \”לצאת\” ממסגרת הגדרות התפקיד. כמובן שבעלי התפקיד נושאים באחריות, ונותנים את הטון הסופי.
איך זה עובד בפועל? האם זה יותר PR ממציאות? – אין לי מושג.
הם עובדים בספרינטים של שבוע, וכחלק מה Lean UX, עושים בדיקות שימושיות למוצר – כל שבוע. \”הרבה בדיקות, על קהל מצומצם\”.

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

מה עושים שעדיין אין מספיק \”בשר\” במוצר בכדי לבצע בדיקות שימושיות? כלומר: בחודשים הראשונים של הפיתוח? מציירים על קיר מחיק או על כרטיסיות את ה UX המתוכנן ונותנים למשתמשים \”ללחוץ בכאילו\” על הכפתורים.

עושים על כל מסך הרבה איטרציות של שימושיות (measure), הפקת לקחים (learn), ויישומם (build).
ה UX בד\”כ נמצאים שבועיים לפני המפתחים, ברמת התוצרים.
הם לא מאמינים ב\”מעצב הגאון\”. מספרים (ממקור אחר) שאפל יישמה כל מסך או פיצ\’ר 9 פעמים, ובחרה מבין התוצרים את זה שהוכח כמוצלח ביותר – להיות זה שישוחרר בגרסה.
מפתחי UI עושים Pairing (כמו \”Pair Programming\”) עם מעצב בזמן שמסדרים את ה UI. המעצבים מבינים טוב יותר את המגבלות של התוכנה – ויכולים לספק פתרונות עיצוביים במקום (מבלי שהמפתח יחכה להם). נשמע טוב!
קונפליקטים בצוותים הם חיוניים ל Innovation – אל תנסו \”להעלים\” אותם.
מצהירים שהתרבות הייחודית שיצרו, היא היתרון התחרותי העיקרי שלהם – מול מתחרים בתחום.

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

הנה מבחן קטן: זהו את מתודולוגיות הפיתוח ע\”פ הצללית:

(לחצו להגדלה)

תשובות [א]

Lean Enterprise

כן – זה קורה: Jez Humble הולך לפרסם סופסופ את הספר The Lean Enterprise ב-15 בינואר 2015. עובדה: הוא כבר עסוק בקידום המכירות.

אל תבלבלו עם הספר השחור (בעל אותו שם. יש שיאמרו: חיקוי).

אמרנו ש Jez הוא בחור משעשע? הנה כך הוא פותח את ההצגה: כיצד מנהלים בכירים בארגונים בוחרים איזה מוצר לבנות?

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

מה הבעיה עם תחושת בטן – אתם שואלים?

רון כוכבי (מסתבר שהוא מדען-נתונים מוערך בקנה מידה עולמי) הוביל את ה A/B Testing עבור אמזון במשך שנים, עד שמיקרוסופט \”רכשו\” אותו, בכדי לעשות אותו הדבר, עם 70 מדענים, בבינג.

“Evaluating well-designed and executed experiments that were designed to improve a key metric, only about 1/3 were successful at improving the key metric!” — Online Experimentation at Microsoft, Kohavi et al

כוכבי היה אחד מאלו ש\”חיו\” על הנתונים של בדיקות A/B Testing יום-יומיות. אם יש דרך לאדם ללמוד מה הלקוחות רוצים / כיצד פיצ\’ר חדש ישפיע – אזי היא לחוות מאות ניסויים כאלו לאורך זמן.

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

כלומר: יש לנו תחושות בטן, רובן הגיוניות:

שכדור הארץ הוא שטוח – \”רואים\”
שהשמש סובבת סביב כדור-הארץ – \”רואים כל יום!\”
ושזבובים נוצרים מתוך בשר שנשכח ללא קירור (- נסו ותראו).

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

זוכרים מה Lean Startup מהו \”ה waste הגדול מכל\”? – לא ישיבות, לא קוד כפול, וגם לא טיפול בבאגים.

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

הנה דוגמה:

מה משנה איזה צבע יהיה הכפתור?!

ובכן, CareLogger גילו, בעזרת A/B testing, ששינוי הצבע של כפתור יחיד באתר שלהם הגביר את מספר המשתמשים בשירות ב 34% אחוז (מקור). כמה פיתוח מוצר בד\”כ עושה בכדי לצמוח ב 34%?

נכון: זו דוגמה קיצונית.

לכן, ובהתאם לזאת, ג\’ז מציע להשליך את ה Story Template המקובל ב Agile, כלומר:

As a , I want so that .

לטובת ה Story Template הבא:

We believe that , will achieve .
We will know we are successful when we see .

שימו לב: אם יש פיצ\’ר שאתם לא יודעים כיצד למדוד ששיפר מדד עסקי כלשהו – עדיף שלא תפתחו אותו בכלל.
עם סיכוי של 70% לטעות – פשוט עדיף לא לעשות כלום. בעצם: עדיף להתאמץ עוד קצת ולמצוא דרך למדוד אותו בכל זאת.

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

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

Enterprises היו פעם סטאראט-אפ שחי ב Horizon 3, הם הצליחו, התבגרו, ואז עברו ל Horizon 2, ו Horizon 1. אם לא היו עושים את ההתבגרות הזו – הם לא היו שורדים. אבל… הם בדרך מאבדים את היכולת לעשות בחזרה את מה שעושים ב Horizon 3.

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

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

נושא מעניין נוסף היה תוצאות מחקר \”State Of DevOps 2014\”.

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

את \”ביצועי ה IT\” הם מדדו כשילוב של:

Throughput

זמן לפיתוח פיצ\’ר: הגדרה עד שחרור (קטן ככל האפשר).
תדירות שחרור גרסאות (deploy של גרסה חדשה כל 10 שניות כמו אמזון – זה פשוט מעולה)

Stability

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

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

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

כיצד משיגים את המדדים הללו?

התגלה במחקר קשר ברור (correlation) בין ההצהרות הבאות – לביצועי IT:

\”את התקלות במערכת מגלות מערכות ה monitoring, לא משתמשים\”
\”כל המפתחים מבצעים merge ל trunk/master branch – כל יום\” (כלומר: by-the-book CI)
\”כאשר מפתחים ו DevOps משתפים פעולה – התוצאה היא בדכ win/win\”.
\”המפתחים נוהגים לשבור פיצ\’רים גדולים לחתיכות קטנות שנכנסות למערכת בזו אחר זו\”

ההתנהגויות הבאות הם המנבאים הטובים ביותר לביצועי IT:

יש peer review לכל קוד שנכנס למערכת המרכזית (בניגוד לחוסר בתהליך, או לסירוגין לתהליך \”כבד\” יותר מ peer review)
כל הקונפיגורציות של המערכת (\”כל מה שאפשר\”) מנוהל ב Source Control.
monitoring פרואקטיבי למערכות (למשל: הרצה של flows יזומים ובדיקה שלהם, ולא רק בדיקת מדדים טכניים של השרת).
שיתוף פעולה טוב בין Development ו Operations.

לבסוף, היה גם עניין של ה Toyota Kata – שלא הצלחתי ממש לעקוב אחריו. תאלצו לקרוא את הספר, אם אתם רוצים לדעת במה מדובר 🙂

ה Keynote של היום השני: פילוסוף גרמני נוזף

(הערה: שתי ההרצאות הנ\”ל היו ביום השני)

אולי גרמנים יזהו את השם Gunter Dueck – אני בהחלט לא זיהיתי. הציגו אותו כפילוסוף, מתמטיקאי, ואחד מ 100 הסופרים הנחשבים בגרמניה. הממ… והוא היה גם בכיר ב IBM גרמניה עד לפני כ 3 שנים (נראה שעסק בפיתוח של DB2 ומערכות DW/BI).

ההרצאה שלו הייתה כתב תוכחה חריף מול התרבות הגרמנית \”שהולכים להזיז לה את הגבינה\”. למשל: תסריט בו תעשיית הרכב קורסת לטובת מכוניות של גוגל / טסלה = קריסת הכלכלה הגרמנית. הוא טען ששליש מהמשרות בגרמניה נובעות באופן ישיר ועקיף מתעשיית הרכב. אאוץ.

אז מה הוא אמר?
היא סיפר על חוויות מ IBM גרמניה. על כך שכל פעם שהיו מפספסים עסקה גדולה – היה מפגש של ההנהלה בשם Lessons Learned.

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

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

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

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

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

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

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

משם גונטר החל לבצע מחקרים על העובדים ב IBM גרמניה:

הוא שכנע מהנדסים לעבור מבחן, שהוא בעצם מבחן אוטיזם. אדם ממוצע מקבל 15/50, אספרגר מאובחן מציון של 27/50 במבחן, והמהנדס החציוני ב IBM שנבדק קיבל 25/50 במבחן. כלומר: ב IBM גרמניה יש הרבה מהנדסים שסובלים (או לחלופין: נהנים) מאספרגר. לא לצחוק: אולי המצב בארץ לא מאוד שונה.
את המנהלים הבכירים העביר מבחן סטנדרטי לאיתור חוזקות (התכונות הבולטות אצלם). אין לי את השקף, אבל זה היה בערך כך (מתוך 4 קטגוריות של חוזקות):

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

גורטר סיפר שבראש כל תעודה בביה\”ס בגרמניה, מציינים 4 ציונים מרכזיים על התלמיד:

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

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

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

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

היכולות הטכניות הגבוהות של הגרמנים נשחקות (עוברות תהליך של Commoditization), וללא שינוי – גרמניה לא תמשיך להיות מה שהיא היום.

לא שכ\”כ משנה לי גורל הכלכלה הגרמנית, אך זו הייתה הרצאה מרתקת ועוצמתית, ואני מקווה שהצלחתי להעביר חלק מהחוויה.

הנה עוד כמה מסרים מעניינים שעלו במהלך הכנס, ממרצים שונים:

IoT (כלומר: Internet of Things) כבר כאן – הוא פשוט נמצא כרגע במוצרי High-End בלבד. המחירים יירדו – ואז הוא יחלחל לכלל תחומי החיים.
IoT הוא לא Stack טכנולוגי חדש, זהו האינטרנט – אבל עדיין יש פרוטוקולים חדשים כגון MQTT או CoAP.
שימוש במונח Water-Scrum-Fall, לתאר מצב בו בפיתוח יש איטרציות קצרות בעוד ה Product וה Operations עובדים ע\”פ איטרציות ארוכות – מצב שהוא בהחלט בגדר \”פספוס נפוץ\”. המונח הוטבע ע\”י סוכנות Forrester.
אבטחה: יש כיום יותר פריצות למערכות On-Premises מאשר למערכות ענן.
זוהי קורליציה ולא סיבתיות, כלומר: ייתכן וזה בגלל שב On-Premises יש יותר מידע שמעניין פורצים ועדיין לא עבר לענן.
Vert.x הוא Framework מגניב. בסשן שלו פשוט היה צפוף!
Netflix שחררה 4 פרויקטים כ Open Source. מסתבר שהם שחררו דיי הרבה בשנה האחרונה. להזכיר: Netflix היא אחד ה Unicorns הבולטים בעולם הענן.
Adrian Cockcroft הוא בחור רציני ומרשים. לא הכרתי אותו קודם לכן. התחלתי לעקוב (@adrianco)
ההבדל בין מהנדס חכם למהנדס נבון: מהנדס חכם יודע כבר את הפתרון, מהנדס נבון מוצא אותו תוך כמה דקות בגוגל…
Rules ב JUnit – יכולים להיות שימושיים למדי!

אחרית דבר

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

כשחזרתי מברלין למשרד, הבאתי (כמקובל) משהו מתוק שקשור למדינה שבה הייתי.
שלחתי מייל לכולם: \”Back from Berlin – Milki on my desk\”, וקיבלתי הרבה תגובות עם חיוכים / \”לייק\” / וכו\’ – אבל המילקי לא נאכל. רק אחרי איזה ארבעה מפגשים משעשעים במסדרון קלטתי שאנשים אשכרה חושבים שאני מתבדח. כלומר – לא הבינו שבאמת הבאתי מילקי. מייל הבהרה ששלחתי אח\”כ – גרם לערימת המילקי להיעלם.

הייתי בברלין, והבאתי מילקי. הכל עובדות.

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

—–

[א] והתשובות הן:

א. Design Thinking

ב. Lean Startup

ג. Lean UX

ד. Agile

נכון, Lean UX ו Design Thinking הן ממוקדות UX ולא פיתוח. Agile זה בערך סקראם.

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

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

מה הקטע של… סקראם? (ת’כלס)

בוודאי שמעתם לא מעט דיבורים על סקראם (Scrum).

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

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

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

רקע
סקראם היא מתודולוגית פיתוח תוכנה המיישמת עקרונות של ייצור רזה (Lean) בעולם התוכנה (מה שנקרא אג’ייל Agile).
אם השמות מבלבלים, אתם יכולים להניח כרגע ש Agile = Lean = Scrum.

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

מתודולוגית סקראם עוסקת ב:

מחזור פיתוח המוצר: איך מפתחים תוכנה? מהם השלבים בתהליך? אלו תפקידים (כלומר, אנשים) מעורבים וכיצד הם עובדים אחד עם השני?
[נושא משנה] ניהול פרויקטים: כיצד לעקוב אחר ביצוע הפרויקט? כיצד לבצע שינויים בתוכניות? כיצד להתמודד עם סיכונים? וכו’
[נושא משנה] ניהול קבוצת פיתוח: כיצד על המנהלים לעבוד עם המתכנתים? כיצד מפיקים לקחים ומשפרים? אילו ערכים להעדיף ולקדם? וכו’

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

סקראם! (בספורט)

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

סקראם או שיטות אג’יליות אחרות (XP, Kanban)
כל השאר, שנקרא לו בפשט(נ)ות “מפל המים” (Waterfall).

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

במודל מפל המים מניחים שהתוכנה דומה לבניית מבנה מגורים:

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

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

מתודולוגיות גמישות (כלומר Agile / Lean / Scrum) מניחות שבניית תוכנה היא דומה יותר לעיצוב חנות כלבו:

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

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

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

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

מקור: http://cafecrem.wordpress.com

מה המשמעות של סקראם בפועל?

במבט של מי שרגיל ל”מפל המים”, ניתן לומר שההבדלים העיקריים בדרך העבודה הסקראמית הם:

בסקראם אכן עובדים במחזורים (נקראים ״ספרינטים״) קצרים: שבועיים עד חמישה, כאשר בכל מחזור יש עוד טיפה פונקציונליות עובדת: “הוספת מדף מתנות במחלקת מתוקים” או “שיפור התצוגה של נעלי טיפוס הרים”, בהקבלה למטפורת ההכלבו.
במפל המים המשימות כנראה היו “מדפים (כל הכלבו)”, “תאורה (כל הכלבו)” או “תצוגות מבצע (כל הכלבו)”. אם הערכות הזמנים היו שגויות, היה יכול להגמר הזמן המתוכנן לביצוע הפרוייקט מבלי שיש מוצרים על המדפים.
בניגוד למפל המים בו יש מסמכים מפורטים כמו MRD, PRD ו Functional Spec, בסקראם מחליפים את המסמכים ברשימות מתומצתות (״backlog״) והרבה פגישות / עבודה פנים מול פנים של האנשים המעורבים. התקשורת היא ישירה, תדירה ודינמית – ולא באמצעות ניירת.
סקראם מגדיר מספר גדול של ישיבות שיש לקיים, כגון “Daily Stand-up”, “Sprint Planning”, יש גם “Sprint Sprint Demo”, “Retrospective” ועוד.
בסקראם יש דגש על השגת יעילות (effectiveness): “כמה פ׳יצרים מועילים נוספו למערכת בפרק-זמן נתון?”.
הדרך היעילה ביותר להשיג זאת היא להפעיל שיטות לזיהוי פ׳יצרים שלא באמת זקוקים להם – ולבטלם. בסה״כ המפתחים יכתבו פחות שורות קוד, אך הם יכתבו יותר שורות קוד שלקוחות באמת משתמשים בהן.
סקראם מסירה סמכויות ואחריויות מהמנהלים ומטילה אותם על אנשי הצוות. אין ראש צוות שמרכז את העבודה, המעקב אחריה וההתחייבות ללקוחות. הצוות מנהל את אלה בעזרת תהליך מובנה שאמור לאפשר לצוות לעשות זאת ללא ״דמות מרכזית שלוקחת את הדברים לידיים״
הצוותים בסקראם הם “צוותי פ’יצר” בניגוד ל”צוותי רכיב” של מפל-המים.
במפל המים היו צוותים כגון “צוות בסיס נתונים”, “צוות UI” וצוות “לוגיקה” – צוותים הממופים לרכיבי המערכת. אם צוות ה”UI” קורס מעומס – הצוותים האחרים לא מסוגלים לעזור לו – יש להם את ההתמחויות והאחריות שלהם.
בסקראם כל צוות אמור להיות מסוגל לבצע “כל משימה”. בצוות יש כישורים כגון בסיס נתונים, UI ולוגיקה, QA, תיעוד – כל מה שצריך על מנת לסיים משימה “מקצה לקצה”.
הנוהג הוא להימנע מלקרוא לצוות על שם רכיב במערכת (“צוות DB”), אלא להשתמש בשנות ניטרליים כמו צוותים “1,2,3” או צוותים “אדום, כחול, וירוק”.
בסוף כל ספרינט, יש פגישה יזומה של “הפקת לקחים” על מנת לאפשר שיפורים בתהליך, שללא תשומת הלב הנוספת, לא היו מתקיימים.

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

דרך חשיבה / עבודה בולטת בסקראם היא Prioritization and Time Boxing. כל פעילות (ישיבה, workshop, משימה) יש לתחום בזמן ולהתחיל מהנושא החשוב ביותר לנושא החשוב פחות. כשהזמן ייגמר, יהיו לנו כמה נושאים חשובים – שסיימנו, וכמה נושאים פחות חשובים – שכנראה נוותר עליהם. זאת במקום הרבה נושאים לא גמורים או השקעת זמן בלתי-נשלטת.
בניגוד לשיטת מפל המים, בה משתדלים מאוד לכתוב קוד “פעם אחת, ולא לגעת בו יותר”, כשכותבים קוד בסקראם כותבים בדיוק את מה שצריך ולא טיפה יותר. סביר למדי שנחזור לקוד הזה ונבצע בו שינויים / תוספות עוד כמה פעמים. בדיקות-יחידה ו CI הם הכלים שמאפשרים לגישה כזו להיות אפשרית.

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

הנה סרטון מצחיק (אבל נכון) המסביר מהו תפקידו של ה Scrum Master

האם סקראם “עובד”?

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

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

אכן רוב היישומים שראיתי לא היו דומים לסיפורי ההצלחה ששמעתי עליהם.

לסקראם יש גם כמה בעיות:

שוק גדול של הסמכות ויועצים – שיש להם אינטרס קודם ל”מתודולוגיית הסקראם” מאשר להצלחת הארגון שלכם.
כמה אלמנטים (כמו “צוות שמנהל את עצמו), פשוט לא עובדים היטב / קשים מאוד ליישום. סקראם איננה קהילה דינמית ובמשך השנים אני רואה מעט הצעות חדשות מהותית להתמודדות עם הבעיות. בעוד סקראם חרתה על דגלה את עקרונות ה”למידה ושיפור תמידי”, קהילת הסקראם היא דיי מקובעת ושינויים ו”גמישות” באימוץ הסקראם הם לרוב לא-באים-בחשבון. אירוני משהו.
סקראם מכילה חוקים רבים, אך משאירה גם שאלות מהותיות פתוחות: כיצד מפתחים אמורים להתמודד עם בעיות שנובעות מ”צוותי פי’צר” או “עבודה ביחידות קטנות”. מתודולוגיות אחרות, בעיקר Extreme Programming ו Lean Startup מכסות רבים מהחורים שלא נפתרו ע”י סקראם – ונפוץ למדי למצוא שילוב שלהן בתוך הסקראם.
“חסידי הסקראם” נוהגים לדקלם ש “Scrum is a Framework” ועל הארגון להשלים בעצמו את החסר. עדיף היה לו היו מספקים פתרונות (אפילו בדמות XP ו LS).
סקראם מתאים לאופי מסויים של אנשים. מקובל מאוד לאמץ סקראם במלואו, הכל או לא-כלום. הגדרות תפקיד כגון “סקראם מאסטר” או “Product Owner” הן מוגדרות היטב ואין כמעט דיון על “וריאציות אפשריות” שלהן. ארגון שגייס אנשים ע”פ פרופיל X – יתקשה לרוב לומר לאנשים יום בהיר אחד “עכשיו עושים סקראם, אתם צריכים להיות Y”. כשהוא אומר להם את זה (ראיתי את זה קורה) – יש טלטלה ארגונית גדולה.

אמרנו כבר שאם ניישם סקראם, לא נכון לצפות שהתוצאה תהיה “כמו בספרים”.

שאלת השאלות היא אם כן:

האם “סקראם ממוצע” עדיף על “מפל-המים ממוצע”?

אני לא חושב שהתשובה היא חד-משמעית – אך אני נוטה לומר שכן. במעט.

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

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

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

בואו נביט בחלון החיפוש של כרום גרסה 22. מוצר בן 4 שנים שנמצא בפיתוח אינטנסיבי:

האם זה לא היישום הפשוט ביותר? זה שמתאים לספרינט ראשון של מימוש הפ’יצר?

לא. אפשר להוריד את האינדקס (“1 מתוך 11”). אפשר גם לוותר על הרקע האדום, שמוצג במידה והחיפוש לא מצא כלום. שניהם לא הכרחיים על מנת לסגור את פונקציונליות החיפוש הבסיסית ביותר.
שני אלו יכולים להכלל בדרישה מאוחרת יותר, שתקרה ספרינט מאוחר יותר, גרסה מאוחרת יותר, או אפילו לעולם-לא.
אם הצוות חושש שגם זה יותר מדי- אפשר לחפור ולצמצם עוד: ויתור על הפינות מעוגלות ב UI, לכתוב קוד נאיבי שלא יעיל מבחינת ביצועים, לוותר על הכפתורים (למעלה / למטה) ולבצע חיפוש עבור ערך ראשון בלבד. כל אלו אולי חשובים ללקוח, אך ניתן לעשות אותם בספרינט הבא. זכרו: מה שאתם רוצים הוא To Nibble [זהירות! וידאו].

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

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

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

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

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

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

—-

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

[ב] תודה לאנונימי על החידוד.

http://en.wikipedia.org/wiki/Lean_Startup