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 זה בערך סקראם.

רשמים ראשוניים מ GOTO; Berlin 2014

זה עתה חזרתי מ-3 ימי כנס \";GOTO\" שהתרחש בברלין.

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

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

Martin Fowler מגיע למתחם Kosmos – לתת את ה Keynote הראשי. חבר הסביר לי שהמבנה נבנה בתקופה הסובייטית – ושיש עוד רבים ממש כמותו.

כנסי ;GOTO הם סדרה של כנסים שרצים ברחבי ארה\"ב ואירופה (שיקאגו, ברלין, אמסטרדם, אורהוס, וקונפהגן) ומתמקדים ב Software Craftsmanship, ארכיטקטורה, אג\'ייל, DevOps, וטכנולוגיות \"חמות\".
הרבה מרצים מפורסמים מגיעים לשם כ\"דרך קבע\": Martin Fowler, Kent Beck, רוד ג\'ונסון, בכירים באמזון, עובדי ThoughtWorks השונים, ועוד. כמעט לא תמצאו שם אנשים מגוגל או מסטראט-אפים אלמונים, אלא יותר מרצים שהם מחברי ספרים (איני יודע אם זו דרישה מפורשת), מובילים של קהילות (למשל מובילת קהילת הפייטון באנגליה), או לקוחות של ThoughtWorks (למשל: חברות ביטוח ובנקים) ושל אמאזון (למשל: נטפליקס).

נדמה לי שהשנה הייתי הישראלי היחידי בכנס.

מה נשתנה?

חוץ מכך שהייתי ב QCON London 2008 (סדרת כנסים \"אחות\" של ;GOTO) – אני עוקב כמעט כל שנה אחרי תוכן כנס GOTO בכדי להתעדכן בטרנדים העכשוויים.

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

ז\'רגון

כמה ביטויים ששמעתי בכנס שוב ושוב, ושאני לא נוהג לשמוע כ\"כ ביום-יום:

  • a Unicorn – כינוי לחברות שהן thought Leaders בנושאי טכנולוגיה, כמו פייסבוק, נטפליקס, או Etsy, בניגוד ל Horse – חברות \"רגילות\".
    \"ההבדל היחידי בין unicorns לסוסים – הוא PR\" – מיהר אחד המרצים לנסות ולאזן את ההייפ. כן, גם אצל ה unicorns הקוד נרקב (\"code rots\").
  • Shaving Yaks – פעולה ארוכה ומתישה, שבסופה אף אחד לא זוכר כיצד ומדוע היא התחילה:
    \"?!Why the hell, were we shaving this Yak\"
  • Bounded Context – רעיון מעולם ה DDD, שמציע פתרון ל business logic מורכב מדי לתחזוקה.
    הרעיון הוא להגדיר \"הקשרים מוגבלים\" (bounded context) במודל,
    לדוגמה: יש לנו מערכת לניהול לקוחות. במקום ליצור מודל אחד שמטפל גם במכירות וגם בתמיכה (support), אנו יוצרים שני מודלים, בלתי תלויים, של העולם (לקוח, מוצר, עסקה) שכל אחד מתמחה בהקשר המוגבל שלו: מכירות או תמיכה.
    הרעיון הועלה כמה פעמים בכנס – כדרך לפרק מערכת מונוליטית גדולה למיקרו-שירותים.
  • Two-pizzas Team – ביטוי שצמח באמזון, ואומץ ע\"י SCRUM לבטא צוותים של \"בערך\" 8 אנשים (או 16 בחורות ממש רזות 🙂 ) – מה שניתן להאכיל בעזרת 2 פיצות אמריקאיות גדולות.
  • T-Shaped Person – תיאור המבטא איש מקצוע רצוי, בעל רוחב (קו אופקי), וגם עומק מקצועי (קו אנכי). הרוחב מתבטא בהכרות עם נושאים שונים והיכולת לתקשר היטב עם אנשים מתחומים שונים.
    באחת המצגות המציג הציג שארכיטקט אמור להיות π-Shaped Person, כאשר לו רגל של הבנה טכנית עמוקה, ורגל שנייה של הבנה עסקית עמוקה.
רעיונות שחזרו על עצמם שוב ושוב בהרצאות

  • Micro-Services היו כנראה ה-Highlight של הכנס, ומדברים עליהם כבר כארכיטקטורת \"ברירת-המחדל\" למערכות ווב בענן. 
  • Breaking Down Silos (למשל עם DevOps או עם ה Business) – בכדי להשיג אג\'ייל אפקטיבי. 
  • אג\'ייל (וסקראם בפרט) דורשים תיקונים. סקראם הוא מעט נוקשה, ולא כ\"כ פתוח לשינויים.
  • התלהבות גדולה מ Docker – ככלי ל Continuous Deployment מהיר יותר.
  • התלהבות מה Netflix Chaos Monkey (סיפרו עליו ב 3 הרצאות שהייתי, כולל ה keynote) – תהליך שתפקידו להרוג שירותים אמיתיים ב production בכדי לאתגר את מנגנוני ההתאוששות של המערכת.
  • שימוש ב Strangler Pattern על מנת לבצע מעבר הדרגתי בארכיטקטורה. בעיקר מ Layered Architecture ל Micro-Services Architecture.

ה Keynote הפותח (מרטין פאוולר)

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

  1. Software Development in the 21st Century – שבעצם עסק ב Micro-Services והחיבור הטוב שלהם לענן ול Continuous Deployment.
  2. מצגת ללא כותרת – מכיוון שהוא התקשה למצוא לה כותרת. אולי הקהל יוכל לעזור לו.
ההרצאה הראשונה הייתה מבוססת בעיקרה על הפוסט של מרטין ממרץ השנה על micro-services, וכללה מעט הסברים חדשים. בקיצור, מרטין מתאר שם 9 תכונות מקובלות של מיקרו-שירותים:

  1. Componentization via Services
  2. Organized around Business Capabilities
  3. Products not Projects
  4. Smart endpoints and dumb pipes
  5. Decentralized Governance
  6. Decentralized Data Management
  7. Infrastructure Automation
  8. Design for failure
  9. Evolutionary Design
נושא המיקרו-שירותים שווה פוסט בפני עצמו. האמת שיש לי כבר פוסט כזה בעבודה, נקווה שאגיע ל delivery…

ההרצאה השנייה היתה אוסף של רעיונות שונים, ולכאורה לא קשורים:

הרצון לבצע כמה תיקונים ועדכונים ל SCRUM – לאור הניסיון שנצבר
התלונה העיקרית הייתה בכך שה PO הוא ה\"מוח\" היחידי בכל הנוגע להגדרת המוצר – והמפתחים הם רק מבצעים.
מרטין סיפר על מקרה שקרה באמזון – בו מתכנת באמזון הציע פי\'צר חדש: \"לקוחות שקנו מוצר X קנו גם מוצר Y, עם קישור למוצר Y\". הרעיון עלה ל VP Marketing שביטל אותו במקום: \"לא צריך להפריע ללקוחות בזמן תהליך הקנייה, שהם כבר שם – לא מפריעים להם!\". המתכנת בכל זאת הלך ו\"דחף\" ל production את הפי\'צר – שהראה מיידית (בעזרת A/B testing) עליה של 3% ברווחים. ה VP התעצבן על המהלך – אך לא יכל ללכת נגד צמיחה של 3% ברווחים בהשקעה כ\"כ קטנה[א].

מלבד כך ש AB Testing היא לא פרקטיקה של סקראם (אלא Lean Startup) – הרעיון העיקרי הוא שלמתכנתים יש יתרון בהבנת ה feasibility של פיצ\'רים – והם יכולים לתרום הרבה. \"השתקה\" שלהם, מפאת קולו היחיד של ה PO – נראית כמו טעות היסטורית גדולה.
מרטין המליץ שבמוצר יהיה Conversational Stories – שנוצרים במשותף ע\"י POs ולא-POs. בכל זאת, עדיין ההמלצה היא לתת משקל רב יותר ל POs (למשל: לקבוע priorities, בהנחה שזה לא כלי לייבש כל מה שלא הגיע מה PO).
עוד אלמנט היה האחריות של המפתחים לדאוג למשתמשי ולקוחות המערכת (ולא רק לרזומה שלהם עצמם – באימוץ טכנולוגיות חדשות). למשל: בהגנה על פרטיות ואבטחה על המשתמשים – אפילו אם ה PO לא דוחף לשם ביזמתו.
Dark Patterns
Dark Patterns הם דפוסים של מערכת, שנוהגת בהטעיה / חוסר צדק כלפי המשתמש. לדוגמה: חנות אונליין שמוסיפה בעת הרכישה של מוצר מסוים, ביטוח או אחריות בתשלום – שהלקוח בכלל לא ביקש. הניסיון הוא שהלקוח לא ישים לב וירכוש בנוסף מוצר שלא התכוון לרכוש – מה שאנו מכירים בלבנט היטב כ \"שיטת מצליח\" (קרה לי פעם – זה באמת מעצבן!).
בשלב זה מרטין נכנס למצב תוכחה וממש גער במפתחים \"אם המנהל שלכם אמר לכם להכניס כזה פיצ\'ר למוצר – זה לא פוטר אתכם!\".
\"…אל תגידו \'רק מילאתי פקודה\'. אתם שותפים באחריות!\".
לא היה ברור לי אם מרטין הבין את משמעות המשפט הזה לקהל הגרמני, ועוד בכמעט-צעקה. אני בלעתי את הרוק כשהוא קרא את הקריאה הזו.
בסופו של דבר הוא דווקא יצא מזה יפה: הוא לא קרא לאנשים להתפטר (מה שלא סביר לדרוש) – הוא אמר להם כך: \"עשיתם משהו רע, וזה באחריותכם. עכשיו יהיה עליכם למצוא משהו טוב לעשות – על מנת לאזן את זה\". הנה דרישה שאנשים יכולים לחיות איתה.
קריאה לפעולה
עוד 2 עניינים שעלו, כקריאה לפעולה מהמפתחים הם:
  1. להשפיע ולתרום למאבק בפרטיות ברשת האינטרנט. הייתה לו הרצאה נוספת שלמה בנושא, בניסיון להסביר ש: \"לא עשיתי כלום רע\" היא לא סיבה שלא יעקבו אחריכם. ברגע שעקבו כבר אחריכם – יש מידע שניתן לנצל כנגדכם. לדוגמה: היה לי משבר בחיים שאני לא מתבייש בו, אבל פרסום מגמתי שלו בשלב מאוחר יותר בחיים – יכול לפגוע בי.
  2. להימנע מ Alienating Atmosphere (אווירה גיקית עמוקה) בתעשיית התוכנה, שמרחיקה \"אנשים חברתיים\" ונשים מהתחום.
    למה לדאוג? כי באופן הזה התעשייה מאבדת הרבה כישרון. הנה מאמר שהוא הזכיר – כיצד אחוז הנשים בהייטק שבארה\"ב פחת משמעותית לאורך השנים, אולי בעקבות \"מתקפת הגיקים\" על התעשייה.
בסוף המצגת עלה למרטין \"לפתע\" רעיון לשם למצגת, ואז השם הופיע בשקף האחרון: \"Professionals, not just code monkeys\".

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

    סדנה: Continuous Delivery

    עוד לפני הכנס עצמו, היה יום שלם של סדנאות לימוד בקבוצות קטנות. מאוד התעניינתי ב System Thinking של מייקל נייגארד, אבל בחרתי בסוף בפרקטי – והלכתי לסדנאת Continuous Delivery של Jez Humble.

    ג\'ז (קיצור של Jessie שזה קיצור של Jayson, אני מניח) הוא הבחור שכתב את הספר המפורסם \"Continuous Delivery\" וגם העביר בהמשך הכנס הרצאה בהשראת הספר החדש שלו: \"The Lean Enterprise\" (שנראה לי שבעקבותיה ארכוש אותו).

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

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

    • מערכות ווב – שם אין טעם לעשות Continuous Delivery, אם ניתן לעשות Continuous Deployment.
    • מערכות Packaged (למשל SQL Server), ומערכות Embedded – שם לא ניתן לעשות Continuous Deployment, אך עדיין יש ערך רב ב feedback התמידי, ולכן עושים Continuous Delivery.

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

    הוא עבר על use-case כיצד HP העבירו את תהליך פיתוח ה Firmware שלהם למדפסות שלהם – ל CD. רוב העיסוק היה באופן בו נבנה והתפתח ה deployment pipeline שלהם.

    המעבר \"עלה\" בשנתיים של כמעט-השבתה של התהליכים השוטפים, אבל ההישגים – היו משמעותיים. כמות פיתוח הקוד החדש (Innovation) – עלתה פי 8!
    בצד ימין, סה\"כ התשומות לא מתחברת ל 100%. 23% נמצאים בתחזוקת האוטומציה (בדיקות בעיקר) – מה שעשוי להראות ב waste – עד הרגע בו משווים כמה זמן נותן סה\"כ ל innovation – שזהו בעצם יצירת הערך היחידה בכל התהליך.

    ה Use-Case הזה מתואר במפורט בספר בשם Large-Scale Agile Development.

    מקור: Jez Humble

    עוד תובנות ספורדיות:

    • חשוב מאוד להחזיק את ה App Configuration במערכת ניהול הקוד – על מנת שיהיו גרסאות מדויקות.
    • מייבן הוא כלי מחורבן לביצוע CD. ה build life-cycle שלו הוגדר בעולם פרה-CD-י. Gradle הוא לא יותר טוב.  הוא ציין לטובה רק את Rake (של רובי).
      ה mitigation העיקרי למייבן הוא להפסיק להשתמש ב snapshots – כדי שיהיה אפשר לשחזר במדויק build שכשל – ולאבחן מה הייתה התקלה.
    • התייחס לפוסט Google Platforms Rant לגבי מדיניות micro-services עבור CD והאופן לנהל גרסאות של APIs.
    • בדיון על גרסאות קוד, בחור גרמני עצר את הדיון וקרא: \"אבל versioning על REST API נחשב כ bad practice…\".
      ג\'ז לא חיכה: \"אתה צריך להחליט: אתה רוצה CD או לא? אם כן – אל תתן לאיזה כלל של REST להפריע לך.\"
      \"אתה יודע מה? אני אדבר מחר עם ג\'ים וובר (מחבר של ספר מפורסם בנושא) – אני בטוח שהוא יהיה בסדר עם זה… כן לג\'ים לא תהיה בעיה…\".
      הוא אמר את זה בצורה מצחיקה למדי, ונראה לי שהצליח גם לא לפגוע בבחור שהעלה את זה.
      אהבתי את הגישה: באמת לפעמים עקרונות לא לגמרי מסתדרים זה עם זה – וחשוב להבחין מה חשוב לנו יותר.
    • עברנו על מספר פתרונות לתצורות CD, ובעיקר:
    • אי אפשר להוכיח Releasability, רק להפריך אותה (בעזרת בדיקות ואוטומציה).
    • כאשר build נשבר (ברמת ה CI) – יש לחזור מהר מאוד (דקות) למצב תקין ע\"י revert של השינויים האחרונים. את הניטור עושים offline. באופן דומה מאוד – עושים זאת ב production.
    • הוא לא מתלהב מגיט עבור CD / CI – וממליץ כ mitigation לעבוד על trunk (או master) בלבד.
      בגוגל, 10,000 מהנדסים עובדים רק על trunk גלובלי שכולל כמעט את כל הקוד של גוגל (מלבד אנדרואיד ו chromeOS, מסיבות היסטוריות).
    • מדד שהוא ממליץ לעשות לו אופטימיזציה הוא Time To Restore Service.
    • עקרון: deploy the same way to every environment.
      • היה לו סיפור על נטפליקס שבדקו קוד על MRI (ה VM הרגיל של רובי) – כי קל לדבג, אבל ב production עבדו עם JRuby (שהוא מהיר בהרבה, ואמור להיות זהה). כצפוי: באג בלתי-צפוי ב JRuby גרם להם להשבתת פעילות מאוד לא נעימה.
    • עקרון משנה: only build packages once. מצד אחד שיקול ביצועים (לא לעשות אותה העבודה פעמיים), מצד שני – ייתכן שבנייה מאוחרת יותר (בעיקר בסביבת CD) תיצור image מעט שונה.
    • עיקר האתגר ב CD הוא לא הכלים ו/או הטכניקות, אלא בעיקר ליצור DevOps Culture. בחלק זה היה לו סיפור מדליק על נומי (NUMMI) – שיתוף הפעולה בין טויוטה וGM, שיצר הצלחה מדהימה – ש GM לא הצליחו לשחזר. אלו סיפורי שחר ההיסטוריה של Lean שהם תמיד מעניינים…
      • הוא המליץ על הספר Toyota Kata 
      • בלי, ועם קשר, המליץ על הספר The Phoenix Project כתחליף מודרני ומכוון IT לספר \"המטרה\" (ספר שנכתב ע\"י בחור ישראלי, והיה דיי מהפכן בכל העניין של ניהול תהליכים ע\"פ אילוצים)
      • המלצה נוספת – The Corporate Culture Survival Guide. אין מה לומר, הבחור אוהב ספרים.
    • לראשונה שמעתי מישהו קורא ל Router (רכיב רשת) – \"רוטר\". דיי הגיוני, אני יודע שבארה\"ב קוראים ל Route (למשל Route 66) לסירוגין כ ראוט 66, או רוט 66.
      חלק גדול מהסדנה (כמעט חצי) – עסק בביצוע בדיקות. החלק הזה היה קצת יותר משעמם עבורי – כי זה נושא שכבר טחנתי רבות לאורך הקריירה.
      במקום פירמידה – הוא הציג את סוגי הבדיקות השונים במטריצה.
      • גם הוא התלונן על חוסר הבהירות במינוח של בדיקות פונקציונליות / קבלה / אינטגרציה (נושא שעלה אצלנו לדיון לאחרונה בעבודה).
        • בזמן הכנס, פחות או יותר, מרטין פאוולר פרסם עדכון לפוסט ישן על בדיקות יחידה, שמכיל דיון על Solitary Tests ו Sociable Tests. כמה נוח – אנו מנהלים בדיוק דיון מקביל בעבודה, ואין כמו גורו בינלאומי, בכדי לתמוך ולתת הרגשה שאנו בכיוון הנכון.
      • קריאה מומלצת Google Testing Culture
      • ציין את PageObject כדפוס מוצלח לבדיקות Acceptance.
      • עודד למחוק מהקוד בדיקות שכבר לא תורמות / לא רלוונטיות (בגלל שינויים בדרישות).
      • הבחין בין Acceptance Tests (\"מקטע בודד של פעילות\") ל Journey Tests (המכסים flow גדול של acceptance), ושוחח קצת על הבחירה ביניהן (כמובן שגם וגם – אבל כמה ומתי כל אחד).
      • \"בדיקות לא-יציבות הן יותר גרועות מבדיקות חסרות-תועלת\" (כי אז אנשים מפסיקים לסמוך על בדיקות).
      נושא גדול אחרון היה ההתמודדות עם בסיסי נתונים בסביבת CD:
      • DB Versioning – רעיון שלכל שורה בבסיס הנתונים יש גרסה (בדומה ל multi-tenancy), וכך ניתן להריץ בדיקות של בסיס הנתונים במקביל / לעשות deploy הדרגתי.
      • טכניקה נוספת לבדיקות: לעשות טרנזקציה ו rollback בכל בדיקה.
      • שימוש של In-Memory DB (למשל: H2) לבדיקות בלבד – בכדי להשיג מהירות גבוהה. מחיר בעייתי נדרש: שוני מסביבת ה production.
      • יכולת Fork DB של Heroku – שיכול לעזור מאוד לבדיקות. אולי ניתן לעשות זאת עם backup/restore גם בצורה מקומית.
      • טכניקות שונות ל nZDM (קיצור של near Zero Downtime for Maintenance) בכדי להחליף \"גרסה\" של בסיס נתונים ב production (או לבצע migration ל schema) – תוך כדי צמצום ההשפעה על הלקוח הסופי. הכוונה היא להשאיר את המערכת חיה, אך למשך זמן קצר (דקות) – לא לאפשר למשתמשים לבצע כתיבות לבסיס הנתונים (או לאגור אותם בצד בנוסח CQRS – ולעדכן אח\"כ).
      • noSQL – כדרך לעקוף רבות מהבעיות. מה לעשות: noSQL, micro-services ו CD מתאימים זה לזה – ובמקום הזה בסיסי-נתונים רלציוניים משתלבים פחות טוב.
      מקור: Jez Humble

      סיכום

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

      שיהיה בהצלחה,
      ליאור

      ——

      [א] בסשן אחר שאל המציג את הקהל: \"כמה מכם יכולים לדחוף מ production פיצ\'ר לאחר שה VP Marketing אמר שזה רעיון רע?\" (כמו בסיפור של אמזון).
      באופן מפתיע למדי, כעשרים אחוז מהקהל הרים יד. אולי בגלל שהיו הרבה סטארט-אפיסטים (?!) אולי גם האווירה הליברלית של ברלין.

      הכנס להוראת הנדסת תוכנה בישראל – רשמים

      רציתי לשתף כמה חוויות מכנס הנדסת התוכנה שהתקיים במכללת כנרת.

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

      הרשמויות

      אתחיל בקטנות:

      1. ראשית ראיתי קבוצה של חבר'ה (סטודנטים) דתיים ממש ליד קבוצה של חבר'ה (סטודנטים) שדיברו ערבית. אמנם זו לא הייתה שיחה משותפת – אבל הקרבה הפיסית בין הקבוצות עוררה תחושת נוחות שאני לא מורגל להתקל בה ביום-יום.
      2. הכנס כלל בעיקר אנשי אקדמיה ורק אנשי תעשייה בודדים (כך התרשמתי).
      3. אנשים מהאקדמיה סיפרו על ניכור מצד התעשייה. מישהי אחת סיפרה שכאשר היא באה לבצע מחקרים על תהליכי עבודה בארגונים היא נוהגת להציג את עצמה כשייכת לחברה x אחרת ולא לאקדמייה – וזה שיפר בצורה משמעותית את שיתוף הפעולה שהיא זוכה לו.
        אני כנראה ביום-יום שותף או תורם (מצד התעשיה) לאווירת הניכור שהיא נתקלה בה – והסיפור הזה עשה לי משהו. האם באמת התעשייה "לא ממש זקוקה" למחקר האקדמי?! אני לא חושב שזו נקודת מבט גורפת, אך בהחלט אני מכיר את נקודת המבט שרואה את המחקר האקדמי כתורם קטן לתעשיית התוכנה בכלל.
      4. הופתעתי לטובה מהרצון הרב של כמה מהמציגים ללכת בדרך לא-קלה בכדי לספק תואר יותר מעשי ויותר מועיל לסטודטים ולתעשייה. אפילו היו שם מרצים מהטכניון (!).
        למי שלא מכיר, הבדיחה המוכרת אומרת שהטכניון הוא המוסד האופטימלי לרכוש מיומנויות של למידה-עצמית: יש מבחנים קשים ומרצים גרועים – כך שהדרך היחידה לשרוד היא פשוט ללמוד לבד.
      5. שמחתי לראות פרוייקטים במכללה (כנרת, נדמה-לי) בהם דורשים מהסטודנטים לעבוד בצוות של ממש (7-8 סטודנטים כאשר כל זוג או שלישיה אחראי על מודול – ולא קל להסתדר), לעבוד עם קוד שלא הם כתבו, ולדלוור משהו – למרות שהוא לא "מושלם". זה נשמע לי כמו צעד משמעותי קדימה בהכשרת מהנדסי תוכנה.
      6. הסשן שלי עבר בשקט יחסי ובהקשבה. אוהד, אפילו, הייתי אומר. ככלל, אנשי אקדמיה הם אנשים תרבותיים 🙂
      7. ראיתי גם אנשי אקדמיה שנראו לי מנותקים. כאלו שטענו שזה לא תפקידה של האקדמיה לחנך מהנדסים, אלא רק חוקרים ("שילכו ללמוד במקום אחר"). או כאלו שלא ממש מבינים את כוחות השוק (פיתחו חלופה עדיפה, לכאורה, ל UML, אבל התעלמו מעוצמת הסטנדרט. כמו לשכנע אנשים לעבור מאנגלית לאספרנטו "כי זו שפה טובה יותר").
      8. למדתי שהמכללות מנסות לקדם את מעמדן של ההכשרות המקצועיות (Certifications, כמו CSDP).
        מדוע? כנראה כדי להעמיד פ'יצר בולט שאין לאוניברסיטאות ולבדל מכללות יותר טובות מאלו הפחות טובות. עבורנו, חלק מאנשי התעשייה (הפלצנים?) – כל המכללות נראות אותו הדבר.
      9. שוחחתי מעט לאחר הכנס על הרשמים שלי עם מנהלת גיוס של חברת הייטק כלשהי. היא סיפרה לי שהיא נתקלה בבוגרי מכללה (בארודה? – לא מכיר) שהועדפו ע"י בוגרי טכניון שהתמודדו על אותה המשרה. "הם פשוט היו טובים יותר" – היא אמרה.
      הנוף מפריע! לא פעם תפסתי את עצמי בוהה בנוף ומאבד קשב למה שנאמר.

      הנה המצגת שהצגתי – היא יצאה שונה ממה שפרסמתי פה בבלוג.
      ככה זה: אני סוגר מצגות לילה לפני.

      ליאור

      הרצאה במסגרת Infrastructure and CyberCon 2014

      לפני מספר ימים העברתי הרצאה במסגרת כנס Infrastructure and CyberCon 2014.
      את הכנס מארגנת חברת ג\'ון ברייס והכנס מיועד לאנשי IT / אבטחה. משה פרבר העביר סמינר על אבטחה בענן והזמין אותי כמרצה אורח לדבר על Federated Identity (בקיצור FI). על FI כתבתי כבר בבלוג, אם כי ניגשתי לנושא קצת אחרת מאשר בפוסט. ניתן למצוא את השקפים בלינק הזה.

      "תואר החלומות" – הסערה

      וואהו. אני חייב להודות שהופתעתי!

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

      1. העורך של גיקטיים מבין משהו בבחירת תכנים.
      2. נגעתי בנושא טעון למדי. הייתי מנסח אותו כ: "עד כמה תואר אקדמי הוא יעיל?"
      מפה לשם היו הרבה רעיונות, דעות (חלק קטן מהן נראו פשוט מקובעות: "תואר בהנדסה חייב  ל… ") ופרשנויות.
      יופי! אני שמח מאוד על הדיון.

      מה לקחתי מהתגובות? (לטווח המיידי – הכנס)

      אני מודה לכולכם על התגובות – אני חושב שהפקתי מהן כמה המלצות משמעותיות.
      אני כותב את הפוסט בתחושת מחויבות לספק כמה הבהרות: כמה רעיונות שניסיתי להעביר בצורה מסוימת פורשו ע"י רבים בצורה שונה + הצלחתי לשפר כמה רעיונות אחרים.
      הנה תקציר:
      • "תואר החלומות" הוא איננו תוכנית מבושלת – הוא היה אמצעי טכני להציג רעיונות (שדווקא בהם התמקדתי) בצורה מוחשית יותר. רעיונות כגון:
        • התמקדות בצרכים של רוב הסטודנטים – ולא של מיעוט (לו ניתן להקדיש תואר מיוחד, נקרא לו "מדעי-המחשב")
        • הכרה בכך שידע הפך זמין יותר מבעבר, וכנראה שניתן וכדאי להסתגל בהתאם ולקצר את מחזור ההשכלה (כמה זמן לוקח עד שמתחילים לעבוד).
        • בחינה מחדש של הערך (value) של כל נושא שנלמד, ללא הגנות מיוחדות, וצמצום ה waste.
        • מהנדסי תוכנה (שאני חוויתי) מתמודדים הרבה יותר עם בעיות ארגוניות / מערכתיות / אנושיות – מאשר עם אלגוריתמים. למה להשקיע בשני פי X יותר מבראשון? (יצירת השכלה שעונה על הצרכים המעשיים)
        • כמה רעיונות טכניים שנראים לי לא אופטימליים באוניברסיטה (לימוד ה stack הטכנולוגי מהברזלים למתכנת – ולא להיפך, שמהניסיון שלי הוא כיוון יותר יעיל; התמקדות בשכבת הפשטה אחת מתחת לעבודה השוטפת – ולא שלושה, כפי שמקובל לעתים רבות וכו\'…).
      • לא הייתה שום מחשבה / רמיזה על הפחתת הרמה האקדמית של החומר הנלמד. אמנם זרקתי כמה באזזים על שמות הקורסים – המטרה הייתה לחדד את משמעות הקורס.
      • אכן נתתי משקל רב יותר לפיתוח ווב / מערכות מידע ממה שיש צורך (תודה לכל המגיבים). אני מניח שזו הייתה הטיה אישית שלי לנושאים שהתעסקתי בהם בתקופה האחרונה.
      • אכן חתכתי את המתמטיקה לגמרי – ובהחלט אפשר לתת לה מקום של כבוד כנושא לבחירה (בכלל, תואר אקדמי הוא מנגנון עם מעט התאמה אישית לסטודנט – וזה נראה לי פספוס).

      לצורך התרשמות בלבד

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

      זכרו:

      • זה לא מלוטש
      • עכשיו אחת בלילה 🙂
      • זו דעתי – ואני לא טוען שזו אמת מוחלטת.

      "אז מה אתה מציע?"

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

      הנה מייל מעניין ורלוונטי שקיבלתי (פרטי השולח שמורים במערכת) – והתשובה שנתתי. ניסיתי.

      שלום ליאור,

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

      תגובתי:

      היי מיסטר-X,
       
      זו שאלה לא פשוטה. לא בגלל החומר הנלמד בתואר, אלא בגלל היוקרה של התארים האקדמיים.
      תואר אקדמי יוקרתי (אוניברסיטה טובה) + ציונים גבוהים (בעיקר במקצועות המחשב) – פותחים דלתות בחברות רבות.
       
      החלטה ללכת בלי תואר היא פחות סטנדרטית ולמרות שהיא יכולה לחסוך כמה שנים – היא יותר קשה באופן אישי (לפחות במצב הקיים).
      עובד איתי בחור שלא עשה תואר, הגיע ל SAP (חברה מכובדת) על בסיס הכשרה בצבא. למרות שהוא מצוין דווקא בנושאים "אקדמיים" (תכנון, יעילות וכו\') – הוא הרגיש צורך להשלים תואר בגלל "מה שהוא מפסיד שלא עשה תואר". הוא התחיל תואר השנה – ובנתיים מאוד מתבאס ממנו.
       
      אני חושב שבמצב היום יש עדיפות לבוגרי אוניברסיטה.
      אני לא רואה כמעט שום תועלת לבוגרי "הנדסת תוכנה" בקבלה לעבודה על פני "מדעי המחשב" – זה עניין אישי אם אתה מוכן להשקיע הרבה זמן בלימודי מתמטיקה לא-קלים (יש כאלו שפשוט נהנים מעיסוק במתמטיקה).
       
      מה אני יכול להמליץ?
      להישאר באוניברסיטה, לא "להתאבד" על קורסי מתמטיקה או בקורסים תאורטיים למדי (למרות שזה יכול לפגוע בממוצע, עדיין אכפת יותר מציונים בקורסי מחשבים) ולא להסתפק במה שאתה מקבל מהתואר מבחינת ההשכלה.
      למצוא מסגרת העשרה עכשווית ש"מדליקה" אותך, כגון:
      • meetups כלשהם (ניתן למצוא ב http://www.meetup.com/ או http://www.geektime.co.il/eventsboard/) – אל תחשוש להגיע כי "אתה עדיין סטודנט".
      • למצוא בעל עסק קטן שישמח להשתמש בתוכנה כלשהי – ולכתוב לו אפילו במחיר זעום (הניסיון של כתיבה ללקוח אמיתי – היא מעשירה ומתגמלת יותר מכל כתיבת תוכנה "למגירה"). יכול גם מאוד לעזור בקבלה לעבודה.
      • לקרוא כמה ספרי מופת בהנדסת תוכנה (גם אם יעברו על הרעיונות שהספר מבטא בתואר, הם לרוב יכוסו בצורה רדודה יחסית למקור).
      • משהו אחר…
       
      מקווה שעזרתי,
      ליאור

      סיכום

      הנה עוד פוסט חפוז שהתחלתי לכתוב ב 12 וחצי בלילה… ואין לי מושג איך הוא יסתיים 🙂