קאנבאן (Kanban) – תהליך שמתנהל מעצמו

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

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


\"מדוע אנו זקוקים ל*עוד* מתודולוגיה? עדיין לא השתלטנו על סקראם!\"

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

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

חלק נכבד ממיישמי הקאנבאן הם ארגונים שהחלו באימוץ סקראם אך \"נתקעו באמצע הדרך\".

מקורות
המילה קאנבאן היא מילה יפנית שמשמעה ״כרטיס חזותי״. היא משמשת בטויוטה (החברה שהמציאה את האג׳ייל[ב]) לתאר תהליך ניהול המלאי מופלא שקורה מעצמו. את התהליך של טויוטה כותבים בעזרת k קטנה (kanban) בעוד את תהליך התוכנה שמבוסס עליו כותבים בעזרת K גדולה (Kanban).

תהליך ניהול המלאי שהיה מקובל במערב נראה בערך כך:

  1. החברה מגדירה ומאיישת תפקיד בשם ״מנהלי מלאי״.
  2. כשהמלאי מגיע לרמה הנמוכה (\"מלאי מינימום\") מנהל המלאי מבצע הזמנה על מנת למלא את המלאי לרמה הגבוהה (מה שנקרא בטעות \"מלאי אופטימום\"[ג]). 
  3. \"מלאי האופטימום\" היא תחזית סטטיסטית, של מנהלי המלאי, על הביקוש העתידי לחלק. 
  4. מנהלי המלאי הם בעלי הבנה קטנה בייצור. ה\"חלקים\" ומבחינתם אלו יכולים להיות מנועי בואינג 747 או עגבניות. Same Same. 
  5. חלק גדול מהעבודה של מנהלי המלאי מושקע בזיהוי הפריטים והזמנת החלק הנכון. לכל חלק יהיה שם, מספר קטלוגי פנימי, מספר קטלוגי יצרן, פרטים לזיהוי היצרן, תמונות שיסייעו (למנהלי המלאי – האנשים במפעל כבר יודעים) לזהות את החלקים וכו\'. אופרציה שלמה. הזמנות מלאי לרוב נעשות באצוות (batch) על מנת \"לקבל מחיר טוב יותר ולחסוך כסף במחלקת המלאי\".

    הגישה המערבית לייעול התהליך היה רכישת תוכנה יקרה עם מיליון אפשרויות (ניהול מלאי הוא עסק מסובך) שתסייע למנהלי המלאי לעבוד מהר יותר (\"Send an order by one-click\").
    גישת ה LEAN, שצמחה מיפן, הייתה לשלוח את כל מנהלי המלאי להיות עובדי ייצור – ולבטל כמעט כליל את תפקיד ניהול המלאי.

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

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

    קאנבאן (kanban), שהחל כתהליך של טויוטה, הפך עם השנים לתהליך עולמי:

    • כשאתם מזמינים קפה בסטארבקס – ההזמנה נרשמת על הספל (החד פעמי) ומועברת למטבח. כשיחזור הספל לקופה – ידעו למי לתת אותו. בקשות מיוחדות – פשוט כותבים על הספל.
    • הגן הקיסרי בטוקיו נדרש להגביל את מספר המבקרים בו. הוא מחזיק מספר מתאים של tokens שכל אורח מקבל בכניסה ומוסר ביציאה. התנאי לכניסה לגן היא הימצאותו של token פנוי – אחרת יש להמתין בתור. בקרת עומס שמתרחשת מעצמה.
    קאנבאן. מקור:  http://mylesbraithwaite.com/journal/2011/03/new-starbucks-coffee-cup-design/ 

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

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

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

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

    • גרמו לתהליך להיות נראה (visible) ע\"י פרסום גלוי של מידע-מפתח[ד].
    • הגבילו את מספר הפריטים שבעבודה (Work In Progress = WIP)
    • הגדירו מדדי הצלחה ופרסמו אותם.
    • שפרו, באופן עקבי, את התהליך.

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

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

    אם ראיתם פעם את רשימת המטלות של ארגון סאפורט (כלומר Product Backlog), אתם בוודאי יודעים שיכולים להיות עשרות קייסים בטיפולו של כל צוות. אי-ניהול ה Sprint Backlog יכול ליצור מצב לא יעיל בו אנשי-הצוות במקביל על הכל (חוק התיכנותיקה: \"ל Context Switch תמיד יש מחיר\"). באירגון סאפורט קשה מאוד \"להתחיל קייס ולסיים\" – מכיוון שיש תלויות חיצוניות.
    לשם כך מגדירים בקאנבאן מגבלה בשם Work In Progress. המגבלה מחייבת את הצוות, מצד אחד, לא לעבוד במקביל על יותר ממספר פריטים (כל צוות קובע עם הזמן את ה WIP שלו). מצד שני היא מחייבת את הצוות \"לסיים\" נושאים ויהי-מה, אחרת כל ה slots של ה WIP יתמלאו – והצוות לא יוכל להמשיך לעבוד.

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

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

    למרות שקאנבאן נתפרה לצוות ללא Deliverables – גם צוותי פיתוח יכולים לעשות קאנבאן והיטב. באופן אישי אני מעדיף  לעשות \"קאנבאן עם ספרינטים\". לקחת את קאנבאן כפי שהוא, ללא תפקידים מיוחדים (Scrum Master) או טקסים (Stand-Up Sit-Down meeting ואחרים), אבל עדיין עם תצוגת התקדמות יזומה בצורת ספרינט רביו: \"מה עשינו בשבועיים-שלושה האחרונים\".

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

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

    [ב] תוכלו לקרוא על כך בקיצור תולדות הסקראם.

    [ג] רכישה של חלקים שיושבים במחסן במשך זמן ללא שימוש = מינוס בבנק וריביות. הרבה רכיבים כאלו זה בהחלט לא \"אופטימום\".

    [ד] ברוח ה Waterfall האהוב, הצעד הראשון של ארגונים רבים במימוש Scrum או Kanban הוא השגת תוכנה (יקרה) שתעזור לנהל את התהליך בצורה Efficient (= מהירה לכאורה). ניהול הסטטוס של הצוות בתוך תוכנה, כך שצריך לגשת למחשב וללחוץ כמה קליקים על מנת לראות נתון כלשהו, היא הדרך ליצור חוסר-נראות. האאא הרגלים רעים…

    .lior_comment { background-color: #fff2cc; border: 1px solid #BFBFBF; margin: 4px 0; padding: 4px; }

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

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

    ישנו בלבול עמוק בין 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. אני מסתובב מסביבו כבר זמן רב [ב] – והגיע הרגע לגשת אליו ישירות.

    כל טוב.

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

    —-

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

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

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

    בית קברות לסטארטאפים: The Chasm

    .lior_comment { background-color: #fff2cc; border: 1px solid #BFBFBF; margin: 4px 0; padding: 4px; }

    דיסקליימר: ה Chasm מכה גם במוצרים בחברות גדולות. הכותרת היא לשם הקריאות בלבד.

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

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

    כיצד ניתן להסביר סירוב שכזה?!
    באים אל החוואי ונותנים לו מתנה משמיים – אך הוא מסרב?!

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

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

    מחזור קבלת טכנולוגיות (Technology Adoption Lifecycle)
    סדרת המחקרים הניבה תוצאות עקביות[1] וכך החוקרים הצליחו לבנות מודל שמתאר בצורה טובה את המתרחש.
    המודל חילק את החוואים לחמש קבוצות של אנשים, בהיבט קבלה של טכנולוגיה חדשה:

    סוגי הלקוחות בהיבט האימוץ של טכנולוגיה חדשה. מקור: \"The Diffusion Process\", Special Report No. 18 (Agriculture Extension Service, Iowa State College) pages: 56–77
    באפון קלאסי, האנשים הראשונים לאמץ טכנולוגיה חדשה הם אלו שמעריכים אותה בזכות מה שהיא.

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

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

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

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

    אחוז גדול יותר של החוואים, 10-15% מהם, נקרא מובילי שוק (Early Adopters). אלו הם לרוב החוואים משכילים, דינאמיים ופתוחים לשינויים. הוא יהיה מוכן לנסות ולאמץ את הטכנולוגיה החדשה ולראות האם היא מצליחה. הוא נהנה מהערך החברתי בלהיות חדשן ו״לפני כולם״, אבל המסירות שלו לרעיון היא פחותה משל החוואי החדשן. לרוב הוא יצפה למחיר נמוך או הטבות תמורת נכונותו ״להתגלח״ על המוצר החדש והוא יסכים לקבל מוצר לא כל-כך בשל.

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

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

    הנגררים (Laggards או Non adopters), הם שאר האוכלוסיה. הם פשוט לא רוצים טכנולוגיה חדשה. חלק זה של החוואים כולל אוכלוסיה מבוגרת יותר ומשכילה פחות. הם ישארו עם הטכנולוגיה ישנה עד שיכריחו אותם להחליף, ואם לא יכריחו אותם – הם ישארו עם \"הטכנולוגיה הישנה והטובה\". אנשי המכירות לומדים לזהות סוג זה של אנשים ולדלג עליהם – הם לא שווים את מאמץ-המכירה.
    בעולם הטכנולוגיה, אלו הם האנשים שעדיין מסתובבים עם טלפון ישן של נקייה למרות שאין להם בעיה כלכלית להחליף לטלפון חדש יותר. הטלפון יפסיק לעבוד – ואולי הם יעברו לנוקיה דור-שני.

    החלוקה לסוגי חוואים מתיישבת יפה עם גרף \"פעמון\" גאוסיאני – ולא במקרה.

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

    באינטרנט, מקור אחד ענה לשאלתה של מיכל 9929 בנושא:

    חוואי הוא כזה שישלו חווה עם חיות כמו פרות ועיזות תרנגולות וכלזה…וחקלאי הוא כזה שמגדל דברים של חקלאות כגון תירס וכל זה מקווה שעזרתי ( ;

    מקור אחר, גרס:

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

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


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

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

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

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

    אבל רגע… האם התמונה עקומה? … באיכות לא טובה? נדמה לי ש\"סדק\" אחד בפעמון גדול מה\"סדקים\" האחרים. בעצם, הוא גדול למדי – ממש ענק! ומה יש שם בתוך הסדק הגדול והאפל הזה? שברים ורסיסים של מאות-אלפי מוצרים ורעיונות שלא השכילו לזהות את הפער בין ה Early Adopters לבין ה Early Majority של המוצר שלהם, שלא הצליחו להתעשת ולגשר על הפער הזה. כל הרעיונות הטובים האלו נקברו בסדק הענק.

    הסדק הזה קיבל כבר שם היאה לכבודו: \"התהום\", The Chasm.

    Liberty Bell – סמל אמריקאי ואולי מקור ההשראה של מור לתיאור \"הפעמון הסדוק\". מקור: http://etc.usf.edu

    The Chasm
    כמו שכל סטארט-אפ בימנו מכיר את חשיבות תזרים-המזומנים, שאם יעצר גם הסארט-אפ ייחדל מלפעול, חשוב לא פחות הוא \"תזרים הלקוחות\" – היכולת לפנות לעוד ועוד לקוחות ולצמוח.
    אז איך זה קורה? האם יום אחד לקוחות מפסיקים להגיע? האם המכירות נופלות מ 100 ל 0 ביום שהגענו אל התהום? האם יש שלט גדול \"תהום\" שיסביר מה קרה?

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

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

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

    כשאתם \"מקשיבים ללקוח\", \"יוצרים קשר עם הלקוח\", \"עושים מה שהלקוח רוצה\" או \"עושים מה שהלקוח צריך – לא מה שהוא מבקש\" – כל אלה הם דברים טובים מאוד ונכונים! בכל זאת, כדאי לתת להם הקשר חשוב: באיזה סוג של לקוח מדובר?


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

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

    Crossing The Chasm
    בעוד קצת אינטואיציה ומזל יכולים לעזור לכם לעבור את ה\"סדקים\" האחרים, המעבר את התהום דורש טקטיקה מדויקת, תכנון והבנה. הפעם בין \"מובילי השוק\" ל\"early majority\" הוא פשוט גדול מדי מכדי שהמעבר יתרחש מעצמו.

    ישנה דרך מומלצת לחציית התהום. נוסחה. קל לדבר וקשה לעשות. היא הולכת כך:
    הבעיה הגדולה שלכם היא שלקוחות \"Early Majority\" ירצו references. דוגמאות ללקוחות, עדיף שדומים להם בגודל ובתעשייה בה הם עוסקים (לדוגמה כימיה, רו\"ח, חברות תעופה וכו\'), שימליצו ויספרו על ההצלחה. לקוחות ה Reference נדרשים להיות \"Early Majority\" בעצמם. כיצד ניתן לפרוץ את המעגל ולהגיע ללקוחות ה Reference הראשונים?

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

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

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

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

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

    \"כאשר היה נדמה לנו שלקוח גדול מקשיב לנו ואנו קרובים להשיג עסקה גדולה ראשונה, הסתבר לנו שהמתחרה DEF, הגדול מאיתנו פי כמה, כבר בפנים וההחלטה ללכת איתו היא כמעט סגורה. ידענו מפעמים קודמות שהם מודעים אלינו והם יעשו כמעט הכל כדי לחסום אותנו מלהשיג עסקאות גדולות – ברור גם למה. אלו References שחסרים לנו על מנת לחדור לעסקאות השמנות. פנינו לאיש הקשר שלנו אצל הלקוח וביקשנו שיכתוב ל DEF שמעכבים בעוד שבועיים את העסקה – מכיוון שבודקים גם את הפתרון שלנו. בהתחלה הוא סירב, למה לסכן עסקה טובה? הבטחנו לו שהוא יראה הפתעה – שממנה ילמד משהו חשוב שישנה את דעתו. הוא חיבב אותנו והסכים לנסות. כשאנשי המכירות של DEF שמעו שהעסקה מעוכבת בשבוע אחד בלבד על מנת לבדוק גם את המוצר שלנו – הם הגיבו באגרסיביות רבה והניחו מייד על השולחן הצעה שלא ניתן לסרב לה: הנחה מיידית של 50%. אנחנו כבר היינו מוכנים עם הסבר משלנו לתופעה: אתם רואים? הם כל-כך מפחדים. הם יודעים שהמוצר שלנו פי-אלף יותר טוב וברגע שיש טיפה תחרות – נופלים להם המכנסיים במקום. זכינו בעסקה.\"

    פלישה רצינית: נורמנדי.

    תהייה אחרונה
    האם אנחנו באמת יכולים להיות מתויגים לאחת מ 5 קבוצות של לקוחות בעלי התנהגות צפויה? האם זה כ\"כ פשוט? – שאלה זו ניקרה בי במשך זמן מה. ובכן, אני לא חוקר ולא נראה לי שאוכל לענות על שאלה זו בצורה מדעית ומדויקת, אולם בכל זאת שמתי לב שאני מתאים לקבוצת לקוחות אחרת בתחומים שונים.
    עד לפני כמה חודשים, הסתובבתי עם טלפון נוקיה ישן. עכשיו יש לי אייפון ואני נהנה ממנו מאוד. \"שורף\" ג\'יגה ויותר בחודש. בבית יש לי טלויזית CRT, איכותית אמנם אך ישנה (אופס! לא פוליטיקלי קורקט – אל תגלו לאף אחד!) – ואין לי שום תכנית להחליף לפלסמה או LED. האם אני Laggard מושבע?

    מצד שני ספרים אני קונה שבוע אחרי שהם יוצאים. היו תקופות שהייתי משוטט בחנויות ורק סורק את הספרים החדשים למצוא כאלו שנראים לי. יצא לי כבר לקרוא כמה ספרים (בעיקר מקצועיים) ב beta או MEAP ואפילו לתרום ל Errata או לדיונים בפורום. אני אוהב להמליץ לאנשים אחרים על ספרים ואני מקבל אי-החזרה ארעית כמחיר סביר להנאה זו. האם אני Innovator?

    אני מניח שאנחנו כאנשים, מתאימים לפילוחים שונים בתחומי עניין שונים ובתקופות שונות בחיינו. לא ייקחו מאיתנו את המורכבות שבנו!

    אני אשמח לשמוע תובנות נוספות בנושא.

    ———–

    [1] התוצאות של חלק מהמחקרים לימדו שבזרעים החדשים היו כמה אלמנטים של Disruption (או הפרעה) במימד החברתי שהקשה על האימוץ שלה. למשל: הטכנולוגיה החדשה הייתה רגישה פחות למקצועיות החוואי עצמו – וכך החוואים מעולים לא יהיו בולטים יותר מחבריהם הפחות מוכשרים. למובילי דעת הקהל בקרב החוואים הייתה סיבה ראציונלית לחלוטין להתנגד. Disruption הוא נושא בפני עצמו בתחום אימוץ הטכנולוגיות / מוצרים טכנולוגיים.

    [2] הדבר המדהים היה שעל מנת לפתור את 2 התלונות העיקריות נדרש כחודש עבודה. במקרה אחד היה צריך פשוט לבטל מנגנון מורכב שפותח במשך כמה חודשים.
    הארגון בו עבדתי החליט שהוא הגיע לקץ ההשקעה האפשרית מבחינתו במוצר ולא היה מוכן להשקיע חודש אחד נוסף. אני חושב שזו הייתה נקודה המשמעותית בחיי שהבנתי עד כמה מתודולוגיות Agile יכולות לתרום לפיתוח תוכנה: שנה וחצי ישבנו בחדרי חדרים, מכונסים בעצמנו כמו תלמידים בישיבה חרדית, והגינו במוחינו מה הלקוחות \"צריכים ורוצים\". שנה וחצי לא החלפנו מילה אחת עם אף לקוח פוטנציאלי, שלא לומר אמיתי. מנהל המוצר הגיע מהתחום ולכולם היה ביטחון שהוא יודע מספיק טוב \"מה צריך לעשות\".

    [3] \"המכנה המשותף לתעשיית הסמים ולתעשיית התוכנה הוא שבשניהם מכנים את הצרכן בשם \'משתמש\'\" – ציין איתמר טאייר. אהבתי!

    סיבוכיות: מקבלים את זה בחינם

    אני רוצה לדבר על פשטות. פשטות של ארכיטקטורה ומוצר.

    כמה פשוט וקל לדבר על פשטות:

    • \"בואו נעשה את זה פשוט\"
    • Keep It Simple, Stupid
    • Less is More
    כמה קל!!
    אבל מה היא פשטות, ואיך משיגים אותה?
    מה שמעון פרס היה אומר?
    פשטות דומה ל\"שלום עולמי\" – אי אפשר להתנגד אליה.

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

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

    כמו \"שלום עולמי\", לאף אחד אין באמת מושג אין משיגים אותה.
    ובכן, לכל נהג מונית יש בערך 4 דרכים להשיג שלום עולמי \"תיק-תק\" – אבל הבודדים שכן מנסים להשיג שלום עולמי, מגלים שאין תורה ברורה איך עושים את זה.
    …מתי אמרתם שיוצא הספר \"World Peace for Dummies\"?
    מקור: http://everydaybipolar.wordpress.com/

    ג\'ונגל הסיבוכיות
    למי שכתב אפליקציית \"Hello World\" בחייו ברור שזו אפליקציה פשוטה.
    מוסיפים לה עוד פונקציה, ועוד פונקציה – והיא עדיין פשוטה. לאחר שאנו יודעים שיש לנו בסיס פשוט, ורצון כן ואמיתי לפשטות (אולי אפילו יש איזה שלט ענק במסדרון שאומר \"!Simplicity\" – לוודא שלא נאבד את הדרך) – אנו מתקדמים בקצב. פעם הבאה שנרים את הראש, נשים לב שאנחנו בתוך ג\'ונגל סבוך – ג\'ונגל הסיבוכיות.
    עיקרון #1: התבונה היא לא בייצור פשטות, התבונה היא ביציאה מסיבוכיות ברגע שהגענו אליה.
    אם אתם מפתחים מערכות תוכנה גדולות מכמה שנות-אדם של פיתוח, כנראה שהסיבוכיות היא בלתי נמנעת. במקום לכעוס / להתאכזב \"כיצד הגענו למערכת סבוכה שכזו?\" ולהתחיל לאבד תקווה, לחפש מקום עבודה חדש, או להחליט שהכל בגלל \"מישהו אחר בצוות\" – כדאי לחשוב ולבדוק: \"מה, אם היינו מסירים או משנים אותו, היה עושה את המערכת לפשוטה יותר?\".
    פה יש נקודה שקצת קשה למפתחים, אך יותר קלה למי שנמצא בדרגות גבוהות יותר: הדבר שאתם רוצים לשנות יכול להיות דרישות, עיצוב גרפי, צורת התקנה וכו\'. אל תגבילו את הבדיקה רק לקוד שלכם ומה שאתם יכולים לעשות מבלי לערב אף-אחד מחוץ לפיתוח.
    אפשר וצריך לאתגר את מנהל המוצר, המעצב הגרפי, או ארכיטקט ה Solution: \"הדבר הזה מסבך אותנו, בוא נבדוק ביחד את המשמעות של שינוי\". תופתעו – אבל ניתן לשנות הרבה דברים. פעמים רבות ה\"החלטה\" או ה\"דרישה\" לעשות משהו מסוים היא שרירותית למדי או לא מגובה בעובדות חזקות, ובדיקה פשוטה יכולה לפתוח לכם אפיקי פעולה שלא הייתם מדמיינים אפילו.
    יצא לי באופן אישי להיות מעורב במחיקה של סט יכולות שלם מ Component Model באחת המערכות, לאחר שנוצרה קואליציה דיי גדולה של מפתחים, מתעדים טכניים ואנשי UX שהיא סיבכה להם את החיים. יצא לנו גם להעביר שירות (service) מרכזי ועתיק יומין משרת אחד לשרת אחר – ולצמצם הרבה תקשורת וסנכרון מיותרים. הדברים הללו פישטו את המערכת והסירו נתח משמעותי מהסיבוך [א].

    עיקרון #2: החכמה היא להאריך את הדרך אל הג\'ונגל, עד כדי כך שאולי אפילו לא להגיע אליו…
    אמנם טענתי שלא ניתן להימנע מג\'ונגל הסיבוכיות, אבל בהחלט ניתן להגיע אליו הרבה יותר לאט. להימנע ממנו לא הצלחתי, אולי לכם יהיה מזל.
    אני רוצה להדגיש כמה עקרונות שיעזרו לכם להאריך את הדרך. מדובר במודעות לכשלי-חשיבה הנפוצים בגופי פיתוח.
    \"אנחנו מקבלים את זה בחינם\", או חוסר ההבחנה בין ממשק public ל published.
    נאמר שהיה לכם צורך לבצע חיפוש על שני סוגי אובייקטים במערכת. בגלל שמספר המקרים גדול מ – 1, כתבתם קוד כללי שמבצע חיפוש על n אובייקטים במערכת – הנדסת תוכנה טובה. השלב הבא הוא לומר לכולם (תיעוד, תהליכים או סתם המלצה – תלוי בארגון): יש לנו חיפוש – תשתמשו בו.
    אפילו יותר גרוע: תחשפו UI, WebService או Public API שלקוחות יוכלו להשתמש בו: הרי הקוד שם – וכך אתם יכולים בעלות נמוכה להשיג תועלת גבוהה – כלכלה פשוטה, \"מקבלים את זה בחינם\".
    אז זהו – שלא.
    משחק שח מנצחים כשמכוונים למטרה – המלך של היריב, לא ע\"י אכילת עוד ועוד חיילים. גם ארכיטקטורה של מערכת בונים ע\"י כוונה למטרה מסוימת, לא ע\"י צבירת נקודות בהוספת עוד ועוד יכולות למערכת.
    שאלות הרות גורל (לנושא הפשטות) הן:
    • האם החיפוש של האובייקטים מחזק את מטרות המערכת וייעודה לטווח הארוך? אני מתנצל על הניסוח המתנשא, אך האם חיפוש הוא חלק עקרוני שסביר שהיה מתפתח בכל מקרה? האם הוא סותר עיקרון כלשהו אחר, לדוגמה Real-time או ביזור? אם לא – ייתכן וזה פתרון זמני, שרירותי, שלא תרצו לקבע.
    • האם החיפוש נכון לכל סוגי האובייקטים? האם יש אובייקטים רגישים (מבחינת אבטחה או הכמסה), שמשתנים בתדירות גבוהה, שמשמשים כ Cache או כצעד חישובי?
    • האם אתם רואים צורך לחיפוש \"מעבר לפינה\"? יש לכם תכניות ממשיות להשתמש בו במקומות אחרים? אולי זהו צורך מאוד נקודתי.
    • האם ברור לכם איך החיפוש צריך להתבצע? אולי זוהי תכונה חדשה ולא בוגרת שכדאי ש\"תבשלו בצד\" עד שתיצרו בה עוד תלויות.
    יש הרבה סיפוק בלספק פיצ\'ר חדש.
    אבל, אם אתם רוצים מערכת פשוטה שיהיה קל לתחזק לאורך שנים – נסו לצמצם את השימוש בתכונה החדשה למינימום ההכרחי. נסו להיות \"קמצנים\" ו\"שמרנים\" בפונקציות של המערכת. האם יש לכם כבר תהליך מסודר בארגון של \"מחיקת דרישות\"? – מעבר על הדרישות לפני הספרינט – וניסיון לצמצם אותן?

    תמיד תוכלו להרחיב את המערכת בעוד פונקציונליות, אך ההיפך הוא קשה יותר: Public APIs, ממש כמו יהלומים – הם Forever.

    \"ריבית דריבית\"
    אם תכפילו 1.2 חמש פעמים תקבלו יותר מ 2. משהו כמו 2 וחצי. החצי הוא ה\"ריבית דריבית\".
    אם תוסיפו פיצ\'ר של חיפוש, ועליו יכולת Customization ועליה יכולת X ועליה יכולת Y – הפיצ\'ר הבא (נקרא לו \"Z\"), יהיה יקר יותר מאשר המקרה בו הייתם נמנעים מלהוסיף את יכולות X ו Y. לעיתים – ההבדל בסיבוכיות המערכת הוא משמעותי למדי.
    זכרו את הכלל הבא: העלות של יכולת חדשה n היא זמן הפיתוח של n + זמן התחזוקה של n + זמן גבוה יותר לפיתוח יכולת n+1 וזמן תחזוקה גבוה יותר ליכולת n+1. רקורסיבית (lim: n–>m).
    עקרון שהתייחסתי אליו גם בפוסט על היעילות האמיתית שב SCRUM: הדרך הטובה ביותר לפריון גבוה יותר בפיתוח הוא לייצר פחות פ\'יצרים – וכמעט תמיד יש מה להוריד. YFAGNI[ב]!

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

    הייתה לי פעם שיחה עם איש UX שאני מאוד מעריך. מדוע ה UI של המערכות שלנו הוא לא \"כזה מגניב\" – למרות שאנו באמת מנסים ומשקיעים.
    \"למה שיצא לנו UX מגניב?\" – הוא שאל בתמימות.
    \"כי אתה ממש תותח…?!\" – עניתי.
    \"האא… זה לא עובד ככה…\" הוא החל להסביר. הוא הסביר שלא ניתן לקלוע ל UX מצוין בפעם ראשונה, אפילו איש UX מוצלח. הדרך להגיע לשם היא ע\"י השקעה באיטרציות:

    1. תכנון ה UX
    2. בדיקת שימושיות (על משתמשים אמיתיים)
    3. הפקת לקחים – ותכנון שיפורים
    4. וחוזר חלילה
    רק לאחר איטרציה ועוד איטרציה ועוד איטרציה – ה UX מתחיל להיות באמת אפקטיבי, \"זורם\", ומהנה. (רעיונות דומים אגב מתכנסים היום תחת התחום שנקרא כיום \"LEAN UX\", למשל לעשות usability tests מאוד קטנים, אבל כל ספרינט).

    פשטות בתוכנה – היא דומה. אם ניתן למתכנן הגאון עוד שבוע בחדר המובדד – התוצאה לא תהיה משמעותית. אם נקצה 10% מכל כח הפיתוח כל ספרינט ל Reafactoring ושיפור קוד – התוצאה תהיה משמעותית יותר. האם אין דרכי קיצור? האם אין את המתכנן הגאון שייצור את הפשטות במחי מכחול ב Visio? האם אין את המדינאי שיביא שלום עולמי לו רק יתנו לו איזו שנה אחת בשלטון?

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

    —–
    [א] הערה טכנית: כמובן ש Unit Tests ואוטומציית רגרסיה היא גיבוי רב-עצמה לביצוע שינויים כאלו בפועל.

    [ב] ! You Ain\'t Gonna Need It

    מה בעצם חשוב ב SCRUM? – אג\'ייל על חודם של שני אנשים

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


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

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

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

    \"בעצם כל שנה יש איזה באזז של איזה חברת יעוץ שמציעה לנו לעשות איזה מהפכה\" – ציין מנהל אחד \"ומה יוצא? -קדחת\". חברו הנהן בהסכמה. \"איך אנחנו יודעים שזה לא רק עוד התלהבות שתחלוף לאחר שנה-שנתיים? מי יידע מה זה סקראם עוד 3 שנים?\".

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

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

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

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

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

    דוגמה טובה יכולה להיות מחלקת Security / Performance/ QA שעדיין לא עברה לסקראם. המוצר זקוק לשירותיה על מנת להיות משוחרר, אולם ע\"פ לוחות הזמנים שלהם הוקצו מראש שני שבועות בסוף השנה לבצע עבורכם את השירות. לא… אי אפשר להזיז – לוח הזמנים דחוס וקבוע מראש.
    איך נשחרר יותר מוקדם? איך נתקדם מספרינט לספרינט ללא פידבק על מצב ההתקדמות? … איך? אולי כדאי לעשות קצת פחות סקראם ולהסתדר איתם?

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

    למרות כל זאת, קיננה בי מחשבה מטרידה: מדוע לא ניתן לבצע מימוש של סקראם ע\"פ עקרונות האג\'ייל – קרי מנה מנה, ניסוי וטעייה? האם לא היה הרבה יותר \"אג\'ילי\" לסדר את פרקטיקות הסקראם ע\"פ סדר חשיבות של עלות/תועלת ולהתחיל לאמץ אותן בסדר זה? אולי בשלב מסויים נפסיק להתקדם – אך נשיג מספיק תועלת ונשלם רק על מה שצרכנו?

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

    בשלב הראשון הייתי קצת מאוכזב: הרבה מהתנהגויות ה Agile להן הייתי רגיל לא התקיימו בפועל: לא Visibility, לא Team Empowerment ולא חתירה בלתי-נלאית להפחתת ה waste.

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

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

    חוכמת הניהול שזכתה להערכה והצלחה במשך השנים האחרונות חזרה לפעולה אחת נוספת והנחיתה אילוץ מצמית על צוות הסקראם. אני אגב הייתי גם ה-Product Owner וגם הארכיטקט וניסיתי ככל יכולתי לחשוב קדימה \"למה אנו יכולים להזדקק בשנה הקרובה\".

    אני רוצה להבהיר: באמת ובתמים ניסיתי להתמודד עם האילוץ הזה ולחיות איתו בשלום. ניסיתי גם לדחות אותו – אך ללא הצלחה. התוצאה הייתה דיי מגעילה ושני המפתחים (אנשים נבונים ודעתניים) התקילו אותי בשאלות קשות על מודל הנתונים שיצרתי – ולא היו לי תשובות ראויות.

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

    מלבדי לא היה מעורב בפרויקט אף אדם בעל ניסיון קודם בסקראם. למרות שהחוויה בה היה לנו flow רץ, בעל ערך, בשלב כה מוקדם האירה והשאירה חוויה על כמה מהמעורבים – אך אין לי מושג עד כמה עמוק הם הבינו את כוונת הסקראם באמת. האם הם יחדשו וימשיכו את הפרויקט בכיוונים נכונים? – אין לי מושג.
    ראיתי מספיק פרויקטים של סקראםכאילו מכדי להתרשם מלוחות burndown או ישיבות בעמידה. הנה פוסט קודם שלי שעסק במקרים שכאלו (בסקראם ובכלל).

    חוויה שנייה שהשפיעה עלי היא פרויקט סקראםכאילו אחר שהשתתפתי בו. החזות הייתה חזות סקראם מצוחצחת: burndown charts, סקראם-מאסטרים בולטים, ישיבות daily כל יום ו Retrospectives הלוך-והשוב.
    התבוננות פנימה גילתה אלמנטים רבים למדי של \"מפל מיים\" מסוגנן\": תכנון של חודשים מראש והצמדות לתוכניות \"ויהי-מה\". בניית תשתיות מורכבות ולא נחוצות. נתק בוטה מהלקוחות או אנשים שיכולים לתת פידבק משמעותי על המוצר ועוד.
    להריץ פרויקט סקראםכאילו זה כמו לצבוע רכב מזהם בירוק ולטעון שהוא ידידותי לסביבה [1]. ציני משהו.

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

    אומרים שקבלת החלטה אנושית מתבצעת באחת משני אופנים:

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

    לדוגמה, האם תושב שדרות יצביע למפלגת מרץ הסמולנית[2] שמציעים לעזור לו בקשיי יומו? או לש\"ס/ליכוד כמו \"שכולם פה מצביעים. ככה זה בשדרות.\" ? מרץ יכולה להקים ולנהל מתנ\"סים עד אולימפיאדת קנזס-סיטי ב 2058. כל עוד ההגדרה העצמית החזקה היא \"תושב שדרות\", היא לא תזכה לתוספת קולות משמעותית עקב פעילותה.

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

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

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

    איני מנסה לענות על השאלה האם עדיף לאמץ סקראם ב\"מכה\" או בהדרגה – אני מניח שהתשובה שונה ממקרה למקרה. אם אתם בוחרים כן לאמץ סקראם בהדרגה, הנה העקרונות בעלי התועלת הגדולה ביותר לניסיוני:

    לא… לא מדובר בהעצמת הצוות גם לא באומץ. לא ישיבות סטאנד-אפ (הבנתם כבר את דעתי עליהן…) ולא נראות (Visibility).

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

    • בניית Backlog תוספתי וממוקד ערך. סיפורים המתארים שכבה אחר שכבה של יכולות המערכת – כאשר כל שכבה מוסיפה משהו שלקוח יהיה מוכן לשלם עליו משהו.
    • עבודה באיטרציות – בהן יש דמו / בדיקה של התוצאה כל פרק זמן קצר.
    • המנעות מ over engineering בפיתוח.

    הרציונאל הוא כזה: העיקרון המרכזי ב Lean הוא צמצום הבזבוז (\"eliminate waste\"). ניסיוני הראה שהחלק הגדול משמעותית של ה waste בתוכנה הוא overproduction – פיצ\'רים מגניבים, יפים וטובים – שהלקוח יכול להסתדר בלעדיהם. התבוננו כיצד נראו האתרים המובילים המוכרים לנו בשנת ההשקה שלהם. האם אתם חותרים לאותו מגע מוקדם עם הלקוח גם במחיר מוצר כ\"כ מינמליסטי?
    אם אתם אומרים \"במקרה שלנו אנחנו חייבים מוצר מלוטש\" – רוב הסיכויים ש(גם) אתם מטעים את עצמכם.

    אני משתמש באייפון שלי ב iTunesU החדש. הייתי רוצה חיפוש טוב יותר, לפלטר החוצה תכני וידאו (אני שומע אודיו בזמן נהיגה  – לראות וידאו בזמן נהיגה זה אפילו יותר מדי בשבילי). הייתי רוצה לראות את שמות הקטעים המלאים: במסך האייפון יש מקום ל …The future of ואז שלוש נקודות. אני מוריד פרקים שאין לי מושג במה הם עוסקים. הייתי רוצה שהתוכנה תתנהג אותו הדבר בחנות וב Palyer – יש אפשרויות ניווט שונות לגמרי. הייתי רוצה אפשרות למחוק פרק אחרי ששמעתי אותו – זה בלתי אפשרי. בחיפוש בחנות אני יכול להתבונן רק ב 100 פריטים בכל קטגוריה וזהו – הייתי רוצה להמשיך ולהתבונן גם מעבר. ועוד ועוד.

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

    אני לא היחידי. שימו לב למספר הבא: למרות שהתוכנה נחשפה לציבור הרחב באמצע ינואר, היו בה עד עכשיו כ 600 מיליון הורדות. היא הייתה בפיילוט מוגבל החל מ 2007 ועדיין היא כ\"כ בסיסית ולא נוחה לשימוש. בכל זאת היא הצלחה. אולי היה חשוב יותר לבנות את מאגר התוכן ולבחון את דרכי השימוש בכזו אפליקציה, לפני שמשקיעים ומלטשים אותה.
    האם אתם מחכים 4 שנים כדי להוסיף יכולת פילטור לרשימות אצלכם – או שזה קורה אחרי חודש? נקודה למחשבה!

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

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

    סיכום
    זה מה שאתם צריכים: שני אנשים שיבינו אג\'ייל טוב והם יכולים לספק את התמורה הגבוהה ביותר מאג\'ייל – בהשקעה קטנה יחסית. המבנה הזה יכול לעבוד עם ראשי צוותים וללא SCRUM Masters, ללא burndown charts, ללא planning של הצוות ועוד.

    אתם זקוקים רק לשני אנשים שיהיו במשחק האג\'ייל:

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

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

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

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

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

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

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

    בהצלחה!

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

    [2] כך כותבים שמאלנית במיטב הטוקבקים בארץ. אני מקיש שזו דרך מחוכמת לקשר את המילה האנגלית small בעלת הצליל הדומה, כמובן.

    [3] למרות שמדדים \"מדידים ואובייקטיביים\" הם ערך אג\'ילי וניהולי ממדרגה ראשונה – רק לעיתים מעטות נתקלתי בפרוייקטים שהיו להם מדדים שכאלה.