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 <type of user>, I want <some goal> so that <some reason>.

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

We believe that < building this feature>, <for these people> will achieve <this outcome>.
We will know we are successful when we see <this signal form the market>.

שימו לב: אם יש פיצ'ר שאתם לא יודעים כיצד למדוד ששיפר מדד עסקי כלשהו - עדיף שלא תפתחו אותו בכלל.
עם סיכוי של 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 זה בערך סקראם.