סיכום הפרק

על HoenyBook

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

 

החברה התחילה מחתונות והתרחבה, בעיקר בתקופת ה-COVID, לורטיקלים נוספים. כיום היא פועלת רק בצפון אמריקה, מונה כמעט 300 עובדים, מתוכם 180 בישראל (בעיקר R&D).

 

למה האניבוק צריכה גילדת אנגיג'נירינג?

 

עד לפני כשלוש שנים, כשהאניבוק הגיעה לגודל של כ-180 מהנדסים בישראל, החברה התמודדה עם אתגרים משמעותיים: המעבר מAngular.js לReact התנהל בקצב איטי מדי, היו חסרים תשתיות טסטינג בפרונט-אנד, וה-velocity של צוותי הפיתוח החל לרדת. בועז, שהיה מפתח בחברה שבע שנים, עסק בפרויקטים אלו "on the go" מהצד, אך הבין שהם כבר מורכבים מדי כדי להתנהל בצורה לא פורמלית.

 

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

 

אם הארגון אומר 'אי אפשר 20%', אבל אז אתה מסתכל על ה-velocity של הצוותים, אז רואים שהם לא עושים את ה-20%, הם עושים הרבה יותר מזה – פשוט בצורה מפוזרת ולא מתוכללת

 

איך הגילדה הוקמה?

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

 

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

 

תהליך חשוב בהתחלה היה הגדרת עקרונות הליבה של הגילדה. אחד המהנדסים יזם מיוזמתו מחקר והגדיר 5 עקרונות core engineering principles, שעזרו להבין מה זה אומר בעצם "גילדה שמטרתה לשפר velocity". מהנדס אחר עסק במיפוי הדומיינים של המוצר, עבודה שנמשכה זמן רב ושימשה בסיס משמעותי אחר כך.

 

מה מבנה הפעילות של הגילדה?

 

הגילדה כוללת את כל המהנדסים בארגון – backend, frontend, data scientists, QA automation ועוד. יש מפגש שבועי של שעה לכל הגילדה (All Hands), ובנוסף מפגשים ייעודיים לקבוצות ספציפיות: backend, frontend, AI וכו'.

 

בליבה של הגילדה יש צוות של כ-8 Tech Leads, שכל אחד מהם מתכלל וקטור מסוים (פרפורמנס, טסטים, ריפקטור, מודולריזציה וכו'). יש גם Product Tech Leads – מהנדסים מנוסים שהוצאו מהצוותים ומדווחים לדירקטור, ותפקידם לוודא שהצוותים מסוגלים לזוז מהר ומודעים לדברים החשובים. הם גם מציפים נושאים לפורום ה-Tech Leads.

 

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

 

הגילדה פועלת בגמישות: לפעמים זה "all hands on deck" על פרויקט משמעותי, ולפעמים עבודה מבוזרת בצוותים. התקשורת מתחילה בשיחות מסדרון, ממשיכה בצ'אנלים, ומגיעה לפגישות גילדה שבהן מוצג תוכן רלוונטי.

 

מה ה-Win-Win בפעילות של הגילדה?

 

Win לעובדים:

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

 

Win לארגון:

  • עלייה ב-Velocity
  • פתרון בעיות רוחביות שלא היו נפתרות בצוותים בודדים
  • חיסכון בזמן ובמשאבים (במקום שכל צוות יטפל בבעיה לבד)
  • יכולת להגיב מהר לשינויים משמעותיים (כמו ה-shift ל-AI)
  • שיתופי פעולה בין דיסציפלינות (data scientists עם developers)
  • שיפור איכות הקוד, יציבות ו-production readiness
  • קיצור זמן delivery של פיצ'רים

 

דוגמה: כשהחברה החליטה לעשות shift גדול ל-AI בתחילת השנה, הגילדה הקימה task force מכל הצוותים, איחדה core מצוות ה-Platform, ובשישה שבועות (שבועיים מחקר וארבעה בניית תשתית) יצרה תשתית AI שאיפשרה לכל הצוותים לעבוד עם AI בצורה מהירה ויעילה. בהגדרה של הקבוצה היה לשלב אנשים מכל הצוותים שיחזרו אחר כך ויפזרו את הידע – וזה עבד מדהים.

 

מה האתגרים שהתמודדת איתם?

 

האתגר המרכזי: זו לא בעיה אינג'ינירית – זו בעיה ארגונית!

 

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

 

אתגרים ספציפיים:

 

  1. שכנוע מנהלים והנהלה – להסביר למה צריך 20% זמן לגילדה, ולהראות שאם לא מקצים זמן מפורש, הוא בכל זאת מושקע אבל בצורה לא יעילה (דברים נשברים, support tickets עולה, פאנלים לא עובדים).
  2. מתי לעשות דברים – לא להנחית הכול מלמעלה, אלא לבחור את הדברים הנכונים בזמן הנכון. למשל, פגישות All Hands התחילו רק כשהגילדה הייתה מוכנה, ובהתחלה היו צריכים לשים שלט על מכונת הקפה "אל תכינו קפה בין 4-5 ביום רביעי" כדי שהרעש לא יפריע…
  3. דמוקרטיה מול החלטיות – רוב ההחלטות מתקבלות באופן קולבורטיבי, אבל לפעמים צריך לעצור דברים ולהגיד "זה מוקדם מדי" או "זה שינוי גדול מדי".
  4. לשמור על רלוונטיות – לא להתנתק מה-day-to-day. ה-Tech Leads הולכים לתרום לפרודקט כדי לחוות בעצמם את התהליכים ולהבין איך המהנדסים מרגישים.
  5. מדידה נכונה – בהתחלה היה רצון לאמץ פלטפורמות מדידה מתקדמות, אבל אז התברר שזה מוקדם מדי. אז בועז בחר במדדים פשוטים: dev cycle ו-Work Life Balance כ-guard metric, והבין שקודם צריך את התהליכים הפנימיים שיאמצו את המדידה.
  6. זה לא one size fits all – כל ארגון שונה, וצריך להתאים את הגילדה לגודל, לתרבות ולשלב של הארגון.

 

 

טיפים להצלחת הגילדה

 

 

דמוקרטיה וקולבורציה – מעט פעמים בועז עומד על הרגליים האחוריות ואומר "זה חייב לקרות". רוב ההחלטות מתקבלות יחד עם ה-Tech Leads והצוותים, כי קשה להחליט מה חשוב יותר בין א' לב' בלי לשמוע מאנשים שרואים וחשים את זה.

 

 

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

 

 

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

 

 

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

 

 

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

 

 

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