"זה נראה כמו סיפור הצלחה"

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

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

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

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

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

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

קרוב לוודאי שזה נשמע מצחיק (השתדלתי), אבל התיאור אינו שונה כ"כ ממאמצי אימוץ שונים שנתקלתי בהם: SCRUM, Object-Oriented ו test-automation - ואלו הן רק כמה דוגמאות ("to name the few").

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

הדגשים העיקריים מניסיוני הם אלו:

התמקדו בתוצאות - והזהרו מהתמקדות ב"חזות המקצוען"
ב SCRUM צוותים ממהרים להציג לוחות Burn-down Charts ולעשות Stand up meeting.
אם אח"כ, בישיבת ה Retrospective, רק ה Scrum Master מדבר ומחלק ציונים לכל האחרים - כנראה שמשהו התפספס (סיפור אמיתי). אם יש לכם שני ספרינטים של Design ואז שני ספרינטים של "מימוש" ואולי עוד ספירנט "בדיקות ו Stabilization" - כנראה שמשהו התפספס (המשך של אותו הסיפור).

פעם ראיתי ראש צוות שלמד Object-Oriented באמצע הקריירה (הוא בא מ Kernel C). הוא יצר מחלקה "פונקציות", מחלקה "קבועים" ומחלקה "משתנים" (והמשיך לפתח פרוצדורלית, כמובן). "הבנתי את הסיפור" הוא הכריז. "נחמד, קצת עושה סדר - אבל אני לא מבין למה עשו מ OO כזה רעש..."

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

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

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

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

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

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

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

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

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