פודקאסט  מספר 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 ו…