לכולנו כבר ברור לגמרי מדוע אנחנו רוצים למזג קוד כל הזמן (Continuous Integration), מדוע אנחנו רוצים לבדוק ולהכין קוד כל הזמן, (Continuous Delivery) או מדוע אנחנו רוצים לשחרר קוד כל הזמן (Continuous Deployment).

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

את הפוסט הזה אני רוצה להקדיש ללמידה מתמדת (או: מתמשכת). אפשר לחלק את הידע ל 2 קטגוריות:

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

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

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

פעם עבדתי בארגון בו התלוצצנו שמי שמתקבל לעבוד בארגון, לא יוכל אחרי שנתיים או שלוש להתקבל לארגון מחדש: ראיונות העבודה הטכניים היו בהחלט קשים, אבל פילוסופיית העבודה לא “נשענה” על ידע עמוק של העובדים: נבנו תשתיות פנימיות שמגבילות מאוד את צורת העבודה: למשל תשתיות לעבודה מול בסיס הנתונים – סט abstractions מעל hibernate שלא היה ניתן לראות SQL והיה לאנשים רק דימיון (שגוי לרוב) מה באמת קורה מאחורי הקלעים, או מן שפת XML שתורגמה ל HTML+CSS, שהגבילה את יכולת העבודה ו”חסכה” מהאנשים חשיבה והבנה מה באמת מתרחש בדפדפן.

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

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

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

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

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

מה אפשר לעשות?

אני מגשש בנושא הגדול, המורכב והחשוב הזה, ולכן התחלתי בהשוואה זריזה בין גישות למידה שונות. נתחיל בנושא הקל יותר (נראה לי) – למידה של טכנולוגיות כלליות:

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

• כנסים הם חוויה, אבל לא מקור למידה משמעותי בעיני. מאוד נהניתי מכמה כנסים – וכמה מהם היו פותחי-עיניים עבורי, אבל את הלמידה עצמה, עשיתי מאוחר יותר, מתוך ספרים ומאמרים. אם לא הייתי מוסיף את הלמידה העצמית, הייתי יודע לדקלם כמה ססמאות נוספות, עם מעט מאוד הבנה במה באמת מדובר.
• יש משהו מאוד מלמד לתת לאנשים בתוך הארגון להרצות, הם בוודאי מתפתחים באופן אישי ממתן הרצאה – אבל בשלבי ההתפתחות הראשונים הם עלולים לספק סשנים ברמה לא מספיק טובה. אולי כדאי להתחיל מפורום של צוות/קבוצה, ורק בעקבות הצלחות שם – לזמן לאנשים לבמה רחבה? (נניח: 100 איש). כל סשן בינוני ומטה שמועבר ל 100 איש – הוא פספוס לדעתי, שעלול להפוך לנזק מצטבר (איבוד אמון בפורום, הורדת הסטנדרטים).
• ספרים עדיין “עובדים”, אבל לפלח הולך ופוחת של האוכלוסייה. אני מאמין ש Video Tutorials הם המדיה העדיפה כיום. כמובן שלאנשים שונים, מתאימים דברים שונים – אבל אם לא נתתם למדיה הזו סיכוי מספיק – אני ממליץ (בתור אחד שקרא עשרות רבות של ספרים, אבל גם ראה עשרות רבות של Video Tutorials).
  • למרות מוטיבציה גבוהה של אנשים להיות עם ידע, הלמידה עצמה אינה קלה, ולעתים קרובות לא מתממשת (כמו שכולם רוצים להיות בכושר, אבל קשה ליישם. מסגרת יכולה מאוד לעזור). השלב הקשה ביותר הוא כנראה הקצאת זמן – וארגון שרוצה להצליח כנראה צריך לעזור לעובדים לפנות זמן משמעותי, ולהתחייב ללמידה. למשל: לקבוע ברבעון כמה ימים קבועים מראש (ולא ניתנים להזזה) לצורך הלמידה + לבקש לסכם ולהציג את סיכום הדברים מול הצוות.
• חונך אישי הוא דיי ברירת מחדל, במיוחד כאשר מגיעים Juniors לארגון – אבל הם יקרים מכפי שנדמה: גם בכמות ההשקעה בפועל, וגם מכך שלא תמיד החונך ידע לחנוך בצורה טובה, או אפילו לספק תשובות מספיק טובות למגוון שאלות שיעלו. החניך לרוב לא יוכל לתת אינדקציה לאיכות החניכה, עד שלא צבר כמה שנים טובות בתעשייה – והפידבק יהיה בעיקר סביב זמינות ונחמדות.

בואו ננסה לעשות תרגיל דומה, על ידע פנימי / ספציפי לארגון:

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

• תיעוד טוב יכול להיות מאוד יעיל (כנראה, למשל תיעוד של ספריות OSS) – אך מעולם לא עבדתי בארגון שהצליח לייצר תיעוד בעקביות: בכמות ובאיכות.
• אני מאמין שתיעוד בקוד הוא מאוד שימושי, כפי שכתבתי באריכות בפוסט קוד ספרותי = סופן של ההערות בקוד. הפוסט מתאר אלו הערות בקוד הן מיותרות, ועדיף שייכחדו, ואלו הן שימושיות (בגדול: דברים שאפשר לפספס מקריאת הקוד, תמונה גדולה, עקרונות, עבר וכוונות עתיד). יותר קל ליצור תרבות של תיעוד בקוד – כי קל יותר לכתוב אותו ולהסביר את הערך שבו.
• כשהארגון גדל מצטבר בו ידע וכללים, כגון Coding Conventions ו Best Practices. יש כאלו שמתנגדים לכל סוג של סדר / חוקים ורוצים להיות “Rock Stars” – ראיתי שוב ושוב את הנזקים המצטברים של הגישה הזו. לא צריך להגזים, וחשוב להשאיר חופש לסגנון אישי – אבל סדר ואחידות בדברים הבסיסיים (לחווייתי ארוכת השנים) יוצרים הרבה יותר תועלת מנזק. בלי תיעוד של הכללים האלו – קשה להפיץ ותחזק אותם. גדילה מסיבית של הארגון יכולה בקלות לגרום לאיבוד של לקחי-העבר, וגם הטובים שבהם. לקחים צריך לתחזק, לחדש, ולהתאים.
• כלי שנראה מאוד שימושי ויעיל להפצה ואכיפה של קונבנציות של Coding Convention ו Best Practices פנימיים לארגון הוא כלי Static Analysis שניתן להרחיב ולקסטם לחוקים הספציפיים של הארגון. מאסתי מזמן מכלים שאוסרים על שורה להיות מערבר לאורך מסוים או מחייבים אותי להוציא constant מכל מספר שמופיע בקוד – אני מוקיע את הכללים האלו, וממליץ לבטל אותם! מצד שני, הצגתי אולי עשרים פעמים בארגון את כללי הבסיס של מבנה טבלאות שהוחלט עליון (חייב להיות primary key שהוא GUID או Autoinc, להוסיף 2 עמודות לזמני יצירה + triggers שימלאו אותם, שימוש ב UTF8 – לא משהו חריג), ושוב ושוב היו פספוסים ואנשים שלא שמעו מעולם על הכללים (שגם מתועדים היטב). פעם אחת יצרנו חוק של Static Analysis שלא מאפשר לעשות ל commit אם יש חריגות – ונראה שהידע החל לעבור, ובלי כמעט השקעה נוספת. כל כלל הוא הזדמנות ללמד, ולכן חשוב מאוד לא רק להציב את החוק אלא להסביר אותו, ולהפנות למקורות. למשל: מדוע למשל חשוב ב MySQL שיהיה Primary Key ומה העלות של Primary Key גדול (בבתים). בנקסט אנחנו משתמשים ב Detekt (לשפת קוטלין) ו Danger (לשפת TypeScript) לכתיבה של Custom Static Analysis rules.
  • התאוריה המקובלת היא ש 70% מהלמידה בפועל מתבצעת מתוך או תוך-כדי עשייה בפועל, וזה הרגע המתאים ביותר ללמוד בו – כאשר הנושא 100% רלוונטי אלי, ואני זקוק לידע בו. Code Analysis tools (עם הסברים מפורטים בצד) – מצטיינים בקליעה לרגעים החשובים הללו.
  • בלי קשר, כל סוג של למידה כדאי לקשור לצורך נוכחי, למשל: קורס SQL לקחת בעת עבודה על פיצ’ר מורכב בבסיס הנתונים, ולהתמקד בצרכים הספציפיים – ולא בעת ההצטרפות לחברה, שאולי שנתיים רצופות לאחר-מכן לא יעשה בידע שימוש משמעותי.

אחרית -דבר / סיכום

ציינתי ועסקתי בכמה טכניקות וכלים להפצת ידע. זו הרמה הטקטית.

הרמה האסטרטגית בהפיכת ארגון לארגון שבו “זורם ידע, באופן מתמשך” – דורשת עבודה… אסטרטגית. למשל: קביעת יעדים משמעותיים ואי התפשרות עליהם. למידה היא השקעה שפירותיה ניתנים רק לאחר זמן, ויש המון פיתויים לדחות אותה. כיצד הופכים למידה משמעותית ותמידית לערך בארגון שנלחמים עליו, ממש כמו Continous Delivery? הרבה ארגונים מוכנים להקריב הרבה בכדי להגיע ל Continuous Delivery הנכסף, אך האם לכל הארגונים הוא ייתן תרומה זהה או גבוהה יותר מ Continuous Knowledge Delivery?!

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

הגדרת מומחיויות: איש QA, איש אוטומציה, Release Manager, איש Operations (בטעות נקרא: DevOps), DBA ועוד – עוזרות לפשט את הניהול בטווח הקצר, אבל יוצרות Silos של ידע (ואי-זרימת ידע) שיקשו עלינו בעתיד.

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

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

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

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

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

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

בקיצור: הרבה שאלות, קצת פחות תשובות.

אתם יותר ממוזמנים להוסיף את התובנות שלכם בנושא.

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