פודקאסט מספר 367 של רברס עם פלטפורמה - אורי ורן מארחים בכרכור את דניאל ואת גיא מחברת Outbrain לשיחה על גילדות, פערי ידע ומספרי קסם.
הפרק בחסות Wix Engineering (המנוע שמאחורי Wix ומשהו כמו 50% מהחברה), שהם גם ספונסרים של Reversim Summit 2019 (רמז, כן. שריינו תאריכים ובואו בהמוניכם).
- דניאל שטרלניכט - בן 31, 10 שנים רשמית בעולם ה - Front-end (ועוד 10 לא רשמית, אם סופרים מהאתר הראשון בגיל 14); התחלה עם בלוג בשם “עיצוב גרפי וטכנולוגיה” (עדיין קיים, פחות פעיל), ועבודה בחברת WebsPlanet, משם ל - Conduit, משם ל -Outbrain, גיחה ל - Microsoft וחזרה ל-Outbrain בתפקיד Front End Guild Master.
- גיא - בן 40, מפתח Back-end כבר למעלה מ-15 שנים, התחלה עם 9 שנים בחברת Schema (אופטימיזציה לרשתות סלולר, מסטודנט לארכיטקסט ראשי), ולאחר מכן כבר 7 שנים ב - Outbrain, היום כארכיטקסט ראשי ו - Back-end Guild Master.
- ולמען הגילוי נאות - אורי, רועה-גילדות ו-CTO ב - Outbrain.
אז גילדות . . . רן נתקל לראשונה במונח דרך Spotify (לא כרשימת השמעה מומלצת - צמד הסרטונים המעולה שלהם מ-2014). מה זה? למה זה טוב? מי צריך את זה?
- לפני שנדון במה זה, חשוב להבין מה הצורך - הנושא הפך ל”חם” כשהחברה הגיעה לסדר גודל של ~600 עובדים (מתוכם ~150 ב - Engineering).
- 150 נשמע מוכר? קוראים לזה Dunbar number.
- מעל גודל מסויים מתחילים להיווצר תת אירגונים, ובין ארגון לארגון נוצרים פערי ידע, דגשים שונים, תרבות פיתוח שונה וכיוצא בזאת, ונוצר צורך “ליישר” - גם ידע וגם תרבות.
- גם במודל הקלאסי ש-Spotify הציגו יש מודל מטרציוני, שבו הגילדה מאחדת “מקצועות”, ובניצב אליה נמצאים ה-Squads, שמאוגדים סביב מוצר או KPI מסויים.
- מבחינת כרונולוגיה של השראה, מעבר ל-Spotify יש בארץ את הדוגמא של Wix שמימשו את המודל, כך שהיה עם מי להתייעץ.
- מלבד האיים הטכנולוגיים וחוסר שיתוף הידע, מבחוץ היה מאוד בולט שצוותים באופן כללי היו בטוחים שאצלם פנימה הכל מצויין, וכולם מסביב לא מבינים כלום ועושים הכל פחות טוב.
- סקר Tech - Excellence פנימי שנערך על תפיסת ההתקדמות וההערכה הטכנולוגית של העובדים הראה באופן בולט בדיוק את זה - כל אחד היה בטוח שהצוות שלו מעולה וכולם מסביב, ובכן - פחות. זה הדליק נורה אדומה.
- המחיר המיידי של מצב כזה הוא שמאוד קשה לדחוף משימות רוחביות (Cross-group) - ככל שזה תלוי “בצוות שלי” הכל עבד בסדר, אבל עבור שינויים ארגוניים רוחביים (החלפת מערכת Monitoring או Deployment, הפחתת תלות בספרייה שכולם משתמשים, וכו’) נתקענו. חסרו דרך או מנגנון, וראינו את הצורך בגילדות.
מעבר לתוצאות הסקר שהראו את הפער בין רמת הצוות לרמת החברה - האם היה מישהו שממבט-על ראה באמת הבדלים בין איזורים שונים בחברה?
- אורי . . . אפשר לראות שצוותים מסויים טובים באספקטים שונים - צוות שטוב בהבאת מוצר לשוק או במדידה אבל לוקה באיכות, ולעומתו צוות עם איכות מאוד גבוהה אבל מגיע לשוק בצורה הרבה יותר איטית - רואים איכויות שונות בצוותים שונים, וקופץ הצורך לשתף את הידע.
זו כנראה לא בעיה שנצפתה לראשונה ב-Spotify או ב-Wix . . . לחברות טכנולוגיה אחרות ודאי יש בעיות דומות ופתרונות שונים. האם זה משהו שהסתכלתם עליו?
- יש את הפתרונות המסורתיים של צוותי תשתית למיניהם - האפקט של כזה מבנה הרבה פעמים מאט מאוד את הפיתוח, והופך את המפתח “שבקצה” לקצת מנוטרל - הפתרונות ניתנים מלמעלה, ויש פחות יכולת לדחוף שינויים טכנולוגיים.
- צוות של ארכיטקטים שפותר את הבעיות “הקשות” עבור כולם מצד אחד משיג אחידות - אבל מצד שני מעקר את היכולת לעודד חדשנות ופתרונות שמתאימים יותר למצבים ספציפיים.
אז איך נראות גילדות ב-Outbrain?
- ראשית, מבחינת הלוגיסטיקה - ההחלטה הראשונית היא להקצות זמן:
- 90% מהזמן של מפתח שייך לצוות ולפעילות השוטפת
- 10% מוקדשים לגילדה, כשדניאל וגיא יכולים לתכנן אותם לצרכים רוחביים
- חצי מהזמן הרוחבי הזה מוקצה לפעילות משותפת - אחת לשבועיים נפגשים להרצאות, סדנאות, שיתופי ידע מאירועים שונים וכדומה
- חצי נוסף מוקדש ל”מילואים”. לפעמים זה יכול Task Force שמורכב ממפתחים מכל מיני צוותים שעובדים על משימות לטובת הכלל, למשל - שינוי מבנה ה-repositories, עבודה על POC לטובת טכנולוגיה חדשה, או אפילו ראיונות למגוייסים חדשים.
- נוסף על הפעילות השוטפת, הגילדה אחראית גם על הכשרות - כשמפתח מתחיל את הקריירה שלו ב-Outbrain הוא מתחיל ב-Boot camp, כשהגילדה היא זו שאחראית עליו - הכרת התשתיות ודרכי העבודה, וכמובן קבלת פידבק.
- גילדות ה-Back end וה-Front-end עובדות דומה, וחשוב לשים לב לכך שהגילדות הן גלובאליות.
- למשל - גילדת ה-front-end ערכה אירוע של “שולחנות עגולים” - קבוצות של 5-6 מפתחים עם אפליקציה שמגרילה נושא לשיחה - וכל אחד מביא את הצד שלו לדיון. אחרי רבע שעה מחליפים נושא ושוב.
- דוגמא נוספת - אתגר ב-CSS: חלוקה לזוגות, כשהמטרה היא לממש לוגואים של חברות הי-טק ישראליות ב-CSS. יצא יפה, שוחרר ל-GitHub - והיום זמינים שם לוגואים של יותר מ-30 חברות.
האם כל עובד החברה שייך לגילדה? האם אפשר להיות משוייך ליותר מגילדה אחת? אילו סוגי גילדות יש בכלל?
- בגדול, יש 3 גילדות רוחביות - Front-end, Back-end ו - Data Science.
- ארגון ה-Product (ואנשי UX) מהווה מעיין גילדה נוספת.
- אנשי Operations שייכים גם כן למעיין ארגון “אורגני”, כשארגון ה- Cloud Platform מכיל נציגים של גילדות ה-Front-end וה-Back-end.
- ויש עוד חיות היברידיות מעניינות . . .
- בין ה-Front-end וה-Back-end יש מפתחי full-stack, שעושים גם וגם; באופן דומה יש מפתחים בין ה-Back-end וה - Data Science ששותפים לשתי הגילדות.
- בדר”כ יש גילדה מרכזית, דומיננטית, ולשנייה מגיעים מדי פעם כדי להתעדכן, להקשיב ולשתף ידע.
- מה לגבי מנהלי הגילדות - יש עוד תפקידים במקביל?
- גיא הוא גם הארכיטקט הראשי, ומנהל גם צוות של שעוסק בשיפור חווית המפתח (Developer Experience - יש אפילו חולצות!) - הרבה מתכתב עם גילדת ה-Front-end (משם צפות הבעיות…).
- דניאל משקיע 100% מזמנו בגילדת ה-Front-end.
האם הרעיון של הגידלות יצא מעבר לתחומי הפיתוח - מכירות? תמיכה?
- גילדות זה לא רעיון חדש (תזכורת ממשחקי הכס למי שנתקל בנושא לראשונה שם), ויש מקום של כבוד לנפחים וסנדלרים וכו’.
- ב-Outbrain עדיין לא , אבל הוחלט כנראה שיש מקום - יש מבט על מבנים ארגוניים נוספים; היה למשל ניסיון להסתכל על “גידלת כותבים” - מחפשים מי שיכתוב בלוגים ותוכן באופן כללי, ויש רצון לארגן מפגשים סביב הנושא
- “גילדת הלבלרים”? מסתבר שיש גם גילדת נגנים ב-Outbrain, רעיון לפרק עתידי של רברסים…
- חלק מהאירועים שכבר רצים הם בסגנון “אנשים מספרים על הקוד שלהם” ומה קורה בצוות שלהם, וסקר-המשך פנימי שנעשה לא מזמן מראה שפערים אכן מצטמצמים
- מאפשר להחליף פוזיציה פאסיבית של “אצלי הכל טוב ולכל השאר אין מושג” למצב אקטיבי של “הנה מה שאני יודע לעשות טוב ואני רוצה לשתף”
אז התחלנו עם ~150 מפתחים ופערי תפיסה בין הצוותים. נניח שאני בחברה דומה - איך אני יודע שגילדות זה הפתרון? - 150 מפתחים? פערי ידע? חוסר אחידות מקצועית? משהו אחר?
- יש שני סימנים בולטים:
- קצב התקדמות - אם הקצב יורד זה כנראה מצביע על תלות בין צוותים שלא עובדת טוב מספיק. למשל - יש טכנולוגיה שצריך לקדם וכולם מסכימים אבל פשוט אי אפשר לבצע - כנראה שצריך משהו רוחבי.
- תחושה אישית של המפתחים היא גם מנבא טוב
ניקח את מקרה הטכנולוגיה - למשל, צורך בהחלפת מערכת Deployment - גישה אחרת יכולה להיות “בואו נבנה Task Force”: להגדיר צוות שיקח את הפרויקט למשך כמה חודשים ויסגור את זה. הרי סיטואציה של “מילואים” עלולה ליצור גם סוג של חוסר יעילות ו-Friction.
לנושאים של אחידות והעברת ידע הערך של גילדה יחסית ברור. לגבי קידום טכנולגיות ופרויקטים זו שאלה יותר מאתגרת.
- אפשר ליצור Task Force לנושאים כאלה, רק שצריך לשים לב שהיקף המשימה (בדוגמת החלפת מערכת ה-Deployment למשל) הוא די גדול, וכל צוות יצטרך להשקיע בזה יותר מכמה ימים ברבעון. מפתח בסופו של יום לא מגיע לעבודה כדי לעסוק רק בהחלפת מערכת, ולעסוק רק בזה עלול להוביל לתסכול של עיסוק רק בעבודה רוחבית.
- יש הרבה משימות רוחביות, וצריך איזשהו מנגנון שינהל ויתעדף אותן
- במקום לקחת 20 אנשים ספציפיים שיעסקו רק במשימות האלה אפשר להיעזר ב-100 (למשל), שיקחו חלק. זה לא מתאים להכל אבל יעיל בהרבה מקרים.
באילו אתגרים משמעותיים נתקלתם בהקמת הגילדות?
- אחת הבעיות המרכזיות היא מחוייבות (Commitment) - לצאת מהמשימות היומיומיות ולהקדיש חצי יום, שהיה אמור להיות מוקדש לפיצ’ר מסויים בספרינט, עבור משימה רוחבית.
- עוד בעיה - תוכן: לאסוף מספיק תוכן לפגישות כל שבועיים, לעודד אנשים לבוא ולהרצות (לא כולם מרגישים בנוח מול קהל, או באנגלית).
- לנהל משימות עם צוות מתחלף זה מאתגר
- מוטיבציה - כולם רוצים לבוא ולשמוע, הרבה פחות מעוניינים לבוא ולשתף ולחלוק, ולא תמיד קל להראות את הערך.
- עניין Quality vs. Variety - לא כולם מרצים מלידה, ומצד שני לא רוצים לקחת תמיד את אותם אלה שטובים בזה ולשמוע רק אותם - המטרה היא לשתף ידע מכולם.
אחרי שנה - אם יש שיפור?
כן - המפגשים הפכו מהרצאה ליותר דיון, ויותר אנשים מביעים את דעתם.
- הנושא הבינלאומי - בהתחלה היה קשה לשכנע להעביר את התוכן לאנגלית, וגם בנושא הזה יש שיפור
- ההרצאות מועברות בוידאו, יש נציג לגילדה בלובליאנה (מרכז הפיתוח בסלובניה) ומתאמים את ההרצאות (ולפעמים בוחרים באפשרות של מפגשים לוקאליים בכל זאת).
- מה לגבי בעיית המחוייבות?
- ראשית - תיאום מול מנהלים והגדרת החשיבות
- יש Backlog . . . יש הרבה משימות לגילדה, ויש הרבה אנשים - מאפשרים למפתחים לבחור משימות, וכך יש חיבור יותר משמעותי למשימה שמתאימה לך.
- ואם יש עדיפות - זה מה יש . . . לרוב יש לפחות שניים במקביל, ואז כל אחד בוחר את מה שהוא מרגיש איתו יותר בנוח.
האם מפתחים נמדדים על ההצלחה שלהם בגילדה?
- נקודה מעניינת . . . בהתחלה התשובה הייתה לא (על בסיס רצון טוב ומוטיבציה לפי התוכן), עכשיו זה נראה שיש מקום ללכת יותר בכיוון וזה עניין של עיתוי.
- חלק מה-Performance Review? עוד מוקדם לדבר על זה, אבל סביר להניח שה - Guild Master יתרום למשוב.
כשפוגשים אנשים שנתקלים בפעם הראשונה בחברה בנושא של גילדות - האם יש להם איזשהו A-ha Moment (או WTF . . .)?
- תגובה אחת - וואו, זה חלום; תגובה שנייה - זה לוקסוס של עשירים לקחת את האנשים הכי טובים למשימות רוחביות . . .
- לגבי “האנשים הכי טובים” - זו נקודה שהמנהלת HR ב-Outbrain העירה עליו שנקודת המפנה במלחמת העולם השניה עבור חיל האוויר האמריקאי הייתה כשהטייסים הכי טובים עברו לתפקידי הדרכה.
- הגילדה היא מנגנון - למשל במקרה של גיא כארכיטקט ראשי, יש רצון ליצור במקביל ל-Top Down של הארכיטקטורה גם מנגנון Bottom-up של הדרכה, על מנת שהמפתחים ירגישו קשר וחיבור יותר רחב.
האם יש חפיפה עם גורמים חיצוניים לגילדות - מרצים חיצוניים? פרויקטים שנחשפו החוצה ואולי לא היו מבוצעים אחרת?
- הרצאת אורח של רן בר זיק (ונעם רותם!) - על Web Security
- הרצאה של אלעד שכטר על CSS
- יש עוד בקנה . . .
יש עוד תוצרים מעניינים לגילדות -
- הרצאה של מאור פרנקל על Web App Performance Monitoring - יצאה מתוך הגילדות לכנס You Gotta Love Frontend.
- ערוץ YouTube של Outbrain Engineering - עם תוכן מתוך הגילדות, זמין לכולם.
- לא מעט בלוג-פוסטים יצאו מתוך פעילויות בגילדות - זמין ב- Outbrain Engineering Medium
חזרה למספר הקסם של 130-150 - הארגון מתחיל להיות גדול מדי ולהתפצל לתתי-ארגונים, ונוצר הצורך לסנכרן בין כולם וליישר תרבות. במקומות כאלה גילדות הן מנגנון מצויין.
- הארגון גדל, מתחילים להתרחק , נוצרים פערי ידע . . . גילדות הן כלי אפקטיבי כאשר לא כולם אוכלים יחד ולא כל אחד עושה Code Review לכל האחרים.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול