השקעה אמיתית או יום כיף עם פיצות? רוב הפרויקטים שיוצאים מהאקתונים מעלים אבק בתיקייה על מחשב של מישהו, אבל אנחנו הצלחנו לוודא שכולם יעלו לפרודקשן ואפילו יוטמעו בהצלחה במחלקות
השקעה אמיתית או יום כיף עם פיצות? רוב הפרויקטים שיוצאים מהאקתונים מעלים אבק בתיקייה על מחשב של מישהו, אבל אנחנו הצלחנו לוודא שכולם יעלו לפרודקשן ואפילו יוטמעו בהצלחה במחלקות
יש לכם מושג מה קרה עם הפרויקט שכתבתם בהאקתון האחרון? (צילום: Unsplash)
ב-4 לפנות בוקר, אחרי 19 שעות רצופות, הקבוצה האחרונה עדיין הייתה במשרד. התחלנו בבוקר הקודם, וכשהאור שוב שטף את חלונות הבניין, 16 צוותים כבר סגרו פרויקטים. יותר מ-60 עובדים השתתפו באירוע, והצוותים כללו לא רק מהנדסים, אלא גם נשות ואנשי HR ופיננסים שיצאו עם פתרונות עובדים מקצה לקצה.
זה לא ההאקתון הראשון שראיתי, אבל הפעם היה בו משהו שונה. אני מייחס את ההבדל – ובעצם, את השיפור האדיר באימפקט – לתכנון המקדים. קל לארגן האקתון בן יום אחד כך שיראה מרשים, אבל קשה הרבה יותר לארגן אותו כך שהתוצרים שלו ישרדו בבוקר שאחרי.
אז איך הופכים האקתון מיממה של עשייה למקום שבו נולדים פתרונות אמיתיים שימשיכו לשרת אותנו הרבה אחרי?
אף אחד לא הגיע להאקתון בלי הכנה. בשבועות שלפני האירוע קיימנו סדנאות בסיסיות על כלי AI ולמדנו מ-Use cases אמיתיים, כדי שגם מי שמעולם לא כתבו פרומפט ידעו מאיפה להתחיל. במקביל, ביקשנו מכל צוות להגיע עם רשימה של תהליכים ידניים ומייגעים מהיומיום שלו – לא רעיון מופשט, אלא בעיה קונקרטית שהוא רוצה לפתור.
במקרה שלנו רוב המשתתפים לא היו אנשי פיתוח, ולכן התמקדנו בהכשרה על Claude וכלי Vibe Coding. לאורך הסדנאות הצגנו את ה-Best Practices לעבודה עם הכלים, ובנינו יחד מוצרים, סקילים ואייג’נטים ראשוניים – כדי שכל משתתף ומשתתפת יחוו הצלחה עוד לפני ההאקתון.
שבועיים לפני האירוע, כל צוות הגיש את הרעיון שלו לאישור. המטרה הייתה לוודא שיש לו היתכנות וערך אמיתי, כדי שלא נשקיע 24 שעות בבניית משהו שלא יגיע לשימוש בפועל. עוד לפני יום האירוע, כל צוות כבר ידע בדיוק מה הוא בא לפתור.
אלה שלושת הפרמטרים המרכזיים שעמדו מאחורי כל אור ירוק שנתנו לרעיון:
ביום שאחרי האקתונים, רוב הפרויקטים נוטים להישאר בתיקייה על מחשב של מישהו ונזנחים שם. כדי למנוע מצב כזה, צוות ה-DevOps שלנו הכין מראש ארכיטקטורה ייעודית ב-GitLab. פרויקטים חדשים קיבלו סביבת עבודה משותפת ומוגדרת מראש, ופרויקטים שהתבססו על מערכות קיימות תויגו תחת קונבנציית שמות אחידה. כל התוצרים רוכזו במקום אחד, במקום שיתפזרו בין מחשבים אישיים.
הכנו מראש טמפלטים שאפשרו גם לצוותים לא-טכניים להקים את הפתרונות שלהם בצורה פשוטה ואחידה. בנוסף, לכל צוות הוצמד איש טכני כמנטור או כחבר צוות פעיל לאורך ההאקתון. מבחינתנו, זאת הייתה הזדמנות לחשוף אנשים לא-טכניים לאתגרים ולדרכי חשיבה על בעיות טכניות – ולקבל מבט רחב יותר על התמונה הגדולה.
בנוסף, קבענו מראש כלל פשוט: כדי שפרויקט ייחשב מוצלח, הוא צריך להיות בשל מספיק כדי לעלות לפרודקשן. זה שינה את אופי העבודה במהלך היום עצמו. צוותים לא בנו דמו שעובד רק על הבמה, אלא בנו משהו שצריך להמשיך לתפקד גם בשבוע שאחרי. מה הופך פרויקט לבשל מספיק? כחלק מתהליך אישור הרעיונות, ליווינו והכוונו את הצוותים להביא את הפתרונות שלהם לפרודקשן באופן מלא בתוך 24 שעות. זה כולל:
כבר בשלב ההרשמה לאירוע, ביקשנו מכל צוות להסביר לא רק איך הוא יבנה את הכלי, אלא איך הוא מתכנן לגרום למחלקה שלו לאמץ אותו ביומיום. שאלה כזו בשלב כל כך מוקדם מכריחה אנשים לחשוב על השימוש בפועל הרבה לפני שהם כותבים שורת קוד אחת.
לפני ההאקתון, כחלק מתהליך אישור הרעיונות, ביצענו תכנון ראשוני של הטמעת הפתרון במחלקה. תהליך הטמעה יכול לכלול סדנאות, חפיפה מסודרת והגדרת אחראי מחלקתי שיוביל את אימוץ הפתרון. דוגמה טובה לכך היא צוות ה-Onboarding, שבנה אפליקציה שמאפשרת ללקוחות חדשים להזין את הנתונים שלהם באופן עצמאי ולראות עדכונים במערכת בזמן אמת. זה חוסך לצוות עבודה ידנית רבה, ולכן האימוץ של הפתרון היה כמעט מיידי. לצורך ההטמעה פתחנו בורד משימות ייעודי, וחילקנו את העבודה בין חברי צוות ה-Onboarding. כך, כל חבר צוות הוא שותף ליישום הפתרון והטמעתו, ולא רק משתמש בו.
לצד הפאונדרים והמנהלים שישבו בפאנל השיפוט, צירפנו את אביעד – אייג'נט שיצרנו במיוחד לאירוע. אחרי כל ההצגות של משתתפי ההאקתון, הוא עבר על התמלול המלא שלהן ודירג את הצוותים לפי אותם קריטריונים שבהם השתמשו השופטים האנושיים. הירידה שלו לפרטים הפתיעה אותנו, כי הוא זיהה זוויות ניתוח שלא תמיד עלו בדיון של השופטים עצמם.
בשלב הראשון הכרנו לאביעד את כל הרעיונות שהוגשו, כולל איזו בעיה כל רעיון נועד לפתור, מהו הפתרון שהכלי מציע ואיך ניתן להטמיע אותו. לאחר מכן סיפקנו לו את חמשת הפרמטרים המרכזיים שלפיהם השופטים תכננו לדרג את הצוותים. בשלב הבא הרצנו עליו מגוון טסטים, הצגנו לו הסבר מפורט על כל פתרון, כולל הדגמה מתוך הדמו, ובדקנו אם הוא מצליח להעריך אותו בצורה עקבית. בדרך גם תיקנו מגוון מקרי קצה.
בסיום ההצגות אספנו את התמלול של כל דמו והעברנו אותו לאביעד, תוך שווידאנו שהוא יודע לאיזה צוות ולאיזה דמו הוא מתייחס. אביעד התבקש לדרג כל דמו לפי חמשת הפרמטרים, בציון של 1 עד 5 לכל פרמטר, בדיוק כפי שהשופטים התבקשו לעשות.
החלטנו לדרג את הקבוצות באמצעות חישוב ממוצע הציונים של כלל השופטים, כולל אביעד, ולכן לציון של אביעד ניתן משקל זהה לזה של כל אחד מהשופטים האחרים. לפני ההכרזה על המנצחים, בדקנו שהציונים שנתן אביעד נמצאים בקורלציה סבירה עם ציוני שאר השופטים, ואכן ראינו שהוא מעריך את הדמואים באופן דומה לרובם. לאחר מכן שוחחנו איתו כדי להבין את השיקולים שעמדו מאחורי ההערכות שלו, והיה נראה שהוא מבין היטב את המורכבות ואת הערך שהפתרונות של הקבוצות מייצרים.
באחת ההצגות אביעד נתן ציון גבוה באופן משמעותי מרוב השופטים, בעיקר בפרמטר שבחן את היקף המשתמשים שיוכלו להפיק ערך מהפתרון. כאשר ביקשנו ממנו להסביר את ההחלטה, הוא הראה לנו כיצד הפתרון יכול לשרת שתי מחלקות נוספות, ולא רק את המחלקה שהצוות הציג, ואף תיאר כמה מקרי שימוש רלוונטיים עבורן. זה היה מעניין – גם פרקטית וגם משום שאף אחד מהשופטים האנושיים לא עלה על האפשרות הזו.
אחת המטרות בתהליך שבנינו הייתה למנוע דעיכה של ההתלהבות סביב הפרויקטים. וזה עבד: שבועות אחרי ההאקתון, אנחנו ממשיכים ללוות את מובילי הקבוצות בפגישות דו-שבועיות, על מנת לוודא שהכלים שהם בנו לא ישארו בגדר ניסוי – אלא יגיעו לשימוש מלא בשטח. רוב הארגונים מדלגים על השלב הזה, אבל לדעתי הוא זה שקובע אם ההאקתון היה השקעה אמיתית או יום כיף עם פיצות.
המטרה של הפגישות הדו-שבועיות היא לעבור על הסטטוסים, לתעד משימות פתוחות שצריך לפתור כדי ליישם את הרעיונות, ולוודא שהכל מתקדם כמתוכנן. חילקנו את הפרויקטים בין כמה אחראים שאמונים על דחיפת הפתרונות שעליהם הופקדו. בפגישות איתם צפים לעתים פערים טכניים שמצריכים תמיכה מ-R&D ו-DevOps, ולשם כך יש לנו את ה-CTO שמלווה אותנו ודואג לספק את המשאבים הרלוונטיים. בעיות תפעוליות בחיבור למוצרים נוספים בארגון מצריכות את התמיכה של מחלקת ה-RevOps, ועבור פערים בשימוש נכון ביכולות AI נעזרות הקבוצות בצוות שלי, AI Operations.
היום, כמה שבועות לאחר ההאקתון, שני פתרונות כבר הוטמעו באופן מלא במחלקות שלהם. את הערך שהם מייצרים נוכל למדוד בעוד כשלושה חודשים.
אמנם עבר מעט זמן יחסית, אבל הפרויקטים שהצוותים הצליחו לבנות בלילה אחד גרמו לי לחשוב מחדש על האופן שבו אנחנו מתכננים קדימה ומחלקים אחריות סביב AI בארגון. הסייקלים הטכנולוגיים כל כך קצרים היום, והיכולת ליצור פתרונות מבוזרת בין כל המחלקות – לא רק אצל המהנדסים. זה מחייב חשיבה אחרת על תכנון קדימה.
אם אתם מתלבטים איך להתחיל, רוצים להרים אירוע דומה אצלכם, או סתם סקרנים לגבי אביעד, אתם מוזמנים לכתוב לי בתגובות ואשמח לשתף מהניסיונות, הטעויות וההצלחות שלנו.
הכותב הוא Director of AI Operations ב-Agora
אגורה היא פלטפורמה גלובלית לניהול השקעות בנדל"ן, המשלבת תוכנה, שירותים ובינה מלאכותית ייעודית לענף הנדל"ן. המערכת מרכזת את כלל תהליכי ניהול ההשקעות – מגיוס הון וקשרי משקיעים, ועד דיווחים, חלוקות, חשבונאות ומיסוי. כיום, יותר מ-1,400 חברות המנהלות נכסים בהיקף של מעל 300 מיליארד דולר משתמשות באגורה כדי לייעל את פעילותן במקום אחד.
קרא את הכתבה המלאה במקור
