408 Iterating Fast in Regulated Environment

 
שתפו
 

Manage episode 290799313 series 42006
על ידי Ran Tavory && Ori Lahav, Ran Tavory, and Ori Lahav התגלה על ידי Player FM והקהילה שלנו - זכויות היוצרים שמורות למפרסם, לא ל-Player FM, והשמע מוזרם ישירות מהשרתים שלכם. הירשמו כדי לעקוב אחר עדכונים ב-Player FM, או הדביקו את כתובת העדכונים באפליקציות פודקאסט אחרות.
בפודקאסט מספר 408 של רברסים עם פלטפורמה - התאריך היום הוא ה-20 באפריל 2021, כבר הרבה זמן שלא היה סגר (408 Request Timeout?), ואנחנו כבר נפגשים הרבה ומקליטים, והקיץ עוד מעט מתחיל . . . (אורי) יש לנו שניים השבוע! (רן) שניים השבוע, נכון . . .
והיום יש לנו אורח מכובד - שי מ-Next Insurance - שלום שי, מה נשמע?
(שי) אהלן, כיף להיות פה.
(רן) ברוך הבא! מיד ניתן לך להציג את עצמך - רק לפני שתעשה את זה, בוא נגיד שיש לך כאן זכויות רבות פה: היית פעם בצוות של הכנס, מעורב בקהילה שלנו כבר הרבה מאוד זמן, שמחים לארח אותך.
היום אנחנו הולכים לדבר על נושא של איך אפשר לזוז מהר בסביבה של רגולציה כבדה - שזו הסביבה שבא חברת Next עובדת.


אז לפני שניכנס לשם, ספר לנו קצת עליך - מאיפה את בא?
  • (שי) אז אני שי - גר בקרית אונו, מנהל קבוצת פיתוח, אחת משלוש קבוצות גדולות שיש לנו ב-Next.
  • בעולם הפיתוח אני כבר . . . אני יודע, מכיתה ג’? מהימים של VIC-20 ו- ZX Spectrum, כל מיני מחשבים כאלה . . .
  • (רן) כמה זיכרון היה לך ב-ZX? זה 48 או . . . מה היה השני? 64? 128? משהו אחר?
  • (שי) כן . . . אני זוכר ב-VIC-20, שהיו שלבים שהייתי צריך לצמצם את מספר השורות כי נגמר . . . כן.
  • (רן) יפה, בכיתה ג’, . . . עוד לפני שלמדת אנגלית
  • (שי) כן, האמת שככה למדתי אנגלית - ואחרי זה עבדתי, תוך כדי הלימודים וגם אחרי, עבדתי בכמה חברות סטארטאפ, גם בחברות יותר גדולות - מיקרוסופט, Sears - וגם כמה חברות שגדלו מאוד מהר, כמו מרקורי, שהייתה בית ספר מצויין ויצאו ממנה הרבה אנשים טובים.
    • גם המייסדים ב-Next הם כאלה וגם עוד כמה חבר’ה, אז ככה - התגבשנו מחדש ב-Next.
  • מבחינת דברים שאני אוהב או מאמין בהם - אני מאוד מאמין באיזור של Lean ו-Agile - לוקח משם הרבה עקרונות וגם אני אוהב את זה שאנחנו עושים את זה ב-Next, אני אספר על זה טיפה.
(רן) כמה זמן אתה ב-Next?
  • (שי) שנתיים וחצי . . .
(רן) כמה עובדים יש בפיתוח, פחות או יותר?
  • (שי) לא ספרתי בזמן האחרון, באיזור ה . . .
(רן) עשרות? מאות?
  • (שי) 110, משהו כזה . . .
(אורי) בטח נכון ללפני 5 דקות . . .החברה צומחת
  • (שי) כן, לא יודע כמה החתמנו היום . . .צומחים מהר.
  • (רן) כן, נכון לשעת ההקלטה . . .

מאה אחוז - אז שנתיים + ב-Next ועם הרבה נסיון - כתוב לך בקורות חיים החל מכיתה ג’, או שאת זה אתה . . .?
  • (שי) לא, את זה אני משאיר כאנקדוטה.
(אורי) תראה מה זה, רן - אנחנו בקיבוץ לא למדנו אנגלית . . . למדנו אנגלית, אבל לא מזה . . .
(רן) אני עוד התווכחתי עם המורה שלי לאנגלית - כי גם אני למדתי אנגלית דרך הספרי מחשבים - והתווכחתי איתה על איך צריך להגיד את המילים, כי לדעתי זה היה אחרת, כי בספרים זה היה . . .
(אורי) בוא, רן - לא למדנו מהמורה לאנגלית אנגלית בקיבוץ, נכון? . . .
(רן) כן . . .

אז Next Insurance - אני מניח חלק מהאנשים מכירים, אבל למי שלא - בוא, ספר לנו קצת על ה-Business שלכם ועל החברה -
  • (שי) אז אנחנו סטראטאפ טכנולוגי - האמת שאפשר להגיד כבר “מבוסס”, אחרי שגייסנו כבר $881M, לפי שווי של משהו כמו 4 מיליארד דולר בגיוס האחרון.
  • אנחנו מפתחים מוצרים שהם ביטוח דיגיטלי לעסקים קטנים -
    • זו נישה כזאת, נישה “קטנה” מהשוק, משהו כמו 5%, “רק” 140 מיליארד דולר בשנה, אז מספיק לנו שניקח חלק קטן מזה, יחסית.
  • הפיתוח נמצא בישראל, כולו.
  • שלושת המייסדים הם אנשים טכנולוגיים, הגיעו ממרקורי [לא זה], מאוד טכנולוגיים ברקע שלהם, מאוד חושבים שהטכנולוגיה זה מה שיעשה פה את ההבדל.
  • העקרון הוא שאנחנו מנסים לפתור בעיה שהיא מאוד מורכבת - אני תיכף אולי אסביר קצת למה, ואנסה לעשות את זה בצורה שהיא כמה שיותר פשוטה - והטכנולוגיה היא מה שנותן את זה.
(אורי) תגיד - זה נכון להגיד ש-Next היא גם חברת ביטוח?
  • (שי) כן - אנחנו, אנחנו בסוף . . . אנחנו חברת ביטוח לכל דבר ועניין
    • אנחנו מבטחים, אנחנו לוקחים את האחריות עלינו, כן . . .
    • (אורי) אז זה Allstate . . .
    • (שי) ו- GEICO, Progressive, ו-Next. . .
    • (אורי) מנורה!
    • (שי) כן . . . אבל הרבה יותר מתקדם מהבחינה הטכנולוגית . . .
  • (אורי) ברור, ברור - אני . . . פשוט זה חשוב, אני חושב, להבין את העניין של הרגולציה - בסוף, אתם חברת ביטוח, וחלים עליכם כל החוקים של חברת ביטוח . . .
    • (רן) של תה בשעה ארבע וכל זה . . . עגלת תה.
    • (שי) זה פחות . . .

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

(רן) אז ביטוח לעסקים - אמרת קטנים ובינוניים - בארה”ב: אז אני מניח שהשוק הזה גדול . . . דרך אגב, איזה סוגי ביטוחים יש שם - זה למבנים? מכוניות? עבודה? מה סוגי הביטוחים יש שם?
  • (שי) כן - אז יש ביטוח רכב עסקי, יש ביטוח מבנה, תכולה, אובדן כושר עבודה, צד ג’ . . .
(רן) אוקיי . . . אז הביטוח תמיד היה שם, זאת אומרת שזה לא שאתם באתם והמצאתם ביטוח ופתאום כולם קנו, אבל משום מה מתחילים לקנות מכם - למה קונים מכם ולא מאחרים?
  • (שי) מה שהיה לפני שהכנסנו את הנושא של הטכנולוגיה זה שהיה תהליך מאוד איטי ומעיק על הלקוחות
    • זאת אומרת - ללכת לסוכן, לשבת איתו, למלא שאלון
    • הוא הולך ושולח את זה לחברה או שתיים
    • מחכה שבועיים
    • הם חוזרים וחושבים בעצמם “איזה מן עסק זה ולאיזו פוליסה שיש לנו הוא דומה - ולפי זה ניתן לו משהו”.
      • בדר”כ משהו לא מאוד מדוייק - ויחסית יקר בגלל שהוא לא מאוד מדוייק, זה מכסה מה שאתה לא רוצה ולא בהכרח את מה שאתה באמת רוצה.
(רן) אז בעצם הורדתם הרבה מאוד מה-Friction ללקוחות - הם לא צריכים לחכות, לא צריכים להיפגש . . . יכולים, לצורך העניין, להיכנס לאתר שלכם, למלא פרטים ולקבל הצעה . . .
  • (שי) כן, להכניס כרטיס אשראי ולקנות
(אורי) אבל נראה לי שמה שאתה בעצם . . . משתמע מהדברים שלך, שהיכולת שלכם להעריך את ה-Risk, בצורה שהיא אולי אוטומטית ויותר טובה ומדוייקת, מאפשרת לכם גם להוזיל את הביטוח למי שה-Risk שלו . . . אני טועה או ש . . ?
  • (שי) בדיוק זה - אנחנו, בעצם, מיפינו מעל 1,000 סוגי עסקים
    • לכל אחד יש לנו את השאלות הספיציפיות שנכונות לו ולפי זה איך נכון לתמחר את זה ואיזה סיכון אנחנו לוקחים.
    • הרבה Machine Learning מאחורי זה
    • ובגלל זה אנחנו מצליחים לתת משהו שהוא הרבה יותר מדויק ללקוח - וגם יותר זול, כי הוא לא משלם על דברים שהוא לא צריך.

(רן) בסדר, אז עכשיו אנחנו נמצאים בעולם ה-FinTech, אוקיי - עולם שבו אנחנו מתחילים כבר ברגולציה יחסית משמעותית, וספציפית בעולם הביטוחים - ובארה”ב, שזו לא בדיוק מדינת עולם-שלישי, זאת אומרת שיש שם כבר חוקים, אי אפשר להיות קאובוי שם . . פעם היה אפשר, היום כבר לא.
אז אולי, לפני שאנחנו מדברים על פתרונות טכנולוגיים או תרבותיים או פתרונות אחרים שאתם מצאתם, אולי תיתן לנו כמה דוגמאות של איפה שהרגולציה פוגשת אתכם? איפה הרגולציה עושה למפתח התוכנה את החיים קצת יותר מאתגרים?
  • (שי) אז קודם כל, משהו שמאוד הפתיע אותי זה שבארה”ב מאוד מסודר . . . זאת אומרת - זה לא הפתיע אותי באופן עקרוני, אבל להבין לאיזה עומק זה.
  • אז למשל - בביטוח של אובדן כושר עבודה, הנוסחא של החישוב היא נתונה על ידי המדינה
    • זאת אומרת שיש לך בכל מדינה - היא כתבה את הנוסחא, והיא אומרת “ככה בדיוק” . . . אתה פונה ל-API ואתה מקבל מה המקדם סיכון למקצוע הזה במדינה הזאת
    • ואתה מכניס את זה לנוסחא - ובסוף יוצא מספר.
(רן) ויש מקום לתחרות, בתנאים האלה? זאת אומרת - אם יש נוסחא, וכולם משתמשים באותה נוסחא, אז איפה אפשר להתחרות?
  • (שי) בדיוק - אז מה המטרה בעצם של רגולציה? למה יש את זה?
  • בגדול, זה כדי להגן על הלקוח ולייצר את התחרות - וגם, באיזשהו מקום, להגן על המדינה.
  • אז מה שהם עושים זה שיש שם איזשהו רכיב שאתה יכול “לשחק בו”, זאת אומרת - משאירים לך איזשהו "משחק”, עד כדי איזשהו מקדם, שאתה כן יכול גם “לשחק”
    • וזה לפעמים חלק משמעותי מהנוסחא - אז יש מקום לתחרות.
    • וחלק מהמטרה היא שבאמת תיהיה תחרות והלקוחות יקבלו תמחור טוב.
  • אני יכול להסביר קצת גם על למה זה מגן על המדינה -
    • המדינה, בעצם, רוצה שלא יקרה מצב שחברת ביטוח תיתן, נגיד, מחירים נמוכים מדי, תיקח על עצמה יותר מדי סיכונים - ובסוף תפשוט את הרגל ועכשיו לך תטפל בעובדים האלה, זה ייפול על המדינה.
  • (רן) ברור . . .
  • (אורי) אתה יודע מה זה אובדן כושר עבודה של קאובוי? . . .
  • (רן) כן . . כמו שקורה לפעמים - מי שזוכר את הבנקים באיסלנד, או פה ושם כמו שקורה במערכות שהרגולציה עליהן היא רופפת . . . .
    • דרך אגב - גם בארה”ב זה קורה, בואו לא נשלה את עצמנו . . . משבר הסאב-פריים, לא צריך ללכת רחוק עד שנות השלושים, זה קרה ממש לא מזמן [ועכשיו?]
    • אז זה גם קורה שם, אבל בכל אופן - לומדים מטעויות וממשיכים . . .
    • (שי) ומחמירים את הרגולציה . . .

(רן) כן . . .אבל איפה זה . . . אוקיי, אז סבבה - אני מפתח ואני ב-Happy Happy כותב Java או Kotlin או מה שאתם עושים שם - לא כל כך מעניינת אותי הנוסחא, זאת אומרת - זה לא כל כך מעניין אותי האם הנוסחא מגיעה מה-Product Manager שלי או מאיזשהו State בארה”ב - יש נוסחא . . . [שים לב שה-Product Manager שלך זה אפי, חבל . . ]
למה לי, כמפתח, ביום-יום - למי אני צריך לחשוב על רגולציה? איפה זה פוגש אותי, באופן אישי?
  • (שי) קודם כל, חלק ממה שאנחנו בונים במערכת והחוכמה, זה שלא תצטרך לפתח כל הזמן - וכל פעם שהמדינה תחליט שהיא משנה את הנוסחא בקצת אז תצטרך לשבת עכשיו ולכתוב קוד.
    • אנחנו עושים את זה כמה שיותר דינאמי, נותנים כלים - מה שאנחנו קוראים לו Self-served - למנהל המוצר הביטוחי.
    • חלקם זה דברים שאנחנו “מושכים מהמדינה”, ב-APIs או בעדכונים
    • וחלקם זה דברים שאנחנו נותנים כלים למנהלי מוצר
    • זה חלק מהמורכבות והאתגר בפיתוח הזה - זה אחד
  • השני הוא שיש מורכבות מאוד גדולה כי לכל מדינה יש חוקים מעט שונים, אז אתה רוצה להכניס את זה לתוך הקוד - זה חלק מהיופי בקוד.
(רן) כן, זאת אומרת - יש פה שונות שהיא אינהרנטית (Inherent), לצורך העניין - אתה חייב להתחשב בחוקי המדינה.
דרך אגב - כשמדברים על רגולציה, למי שמגיע לדוגמא מעולם המדיקל - אז שם, לדוגמא, הרגולציה נראית אחרת לגמרי - שם “רגולציה” זה ביקורות תקופתיות ותהליך פיתוח מתועד וניסויים ואישורים וכל זה . . . זה, אני מניח, משהו שעוד לא קיים אצלכם?
  • (שי) הביקורות התקופתיות זה (משהו ש)קורה - גם שם אנחנו עושים את זה כמה שיותר אוטומטי, מוציאים דוחות אוטומטיים, מדווחים . . .
    • יש דיווח כל חודש, שרץ אוטומטית - זה חלק ממה שאנחנו עושים באיזור של הדאטה אצלנו.

(אורי) אז, בעצם, יש דיווח, לצורך העניין, על המספרים הפיננסיים, על ה . . . . איך לקרוא לזה? על הביצועים, לצורך העניין - זאת אומרת, אתה צריך לדווח מספרים.
השאלה האם יש גם פיקוח רגולטורי על התהליכים שלכם? כמו שרן הזכיר - בעולם המדיקל, או ב . . .
(רן) כן, נגיד - שיש אנשי QA, שמוציאים Feature חדש שעבר איזשהו בודק חיצוני, שבדק שזה לפי התקנות וכו’ - דברים כאלה קיימים בתהליכים?
  • (שי) אז אולי, כאילו לשמחתינו, הם יותר מיושנים - אז אין את זה . . .
  • אבל כן יש Audit, זה אומרת - מדי פעם באים ועושים ביקורת ומסתכלים על הפוליסות שהוצאנו:
    • האם הן תומחרו נכון?
    • האם לקנו סיכונים נכון?
    • ו . . .
(אורי) כן, אבל אתה יודע - יסתכלו על המספרים שהוצאתם, בסדר, אבל לא יכנסו לתהליך הפיתוח שלך, אם הוא ככה או אחרת או מי עשה את ה-QA, ו . . .
  • (שי) לא, שם יש לנו חופש - ובגלל זה אין לנו QA . . .
  • (אורי) תודה לאל
  • (שי) כן, לגמרי.

(רן) אוקיי, בסדר - אז הבנו חלק מעולם והאתגר הזה של רגולציה. עכשיו, נדבר על אילו פתרונות טכנולוגיים, תרבותיים, או פתרונות אחרים בעצם בניתם בפנים, כדי להיות מסוגלים להיות ככה - לפני התחרות, לרוץ מהר וכו’.
אז נתחיל בנושא של Continuous Deployment, ש”בעולם העתיק”, לפחות, זו אולי הייתה אחת מנקודות החיכוך או הויכוח המרכזיות סביב מי שרוצה, בוא נאמר, “לשחק את זה בטוח”.
אז איך נראה יום אצלכם, מבחינת Continuous Deployment?
  • (שי) Continuous Deployment מלא . . . כל קוד שאתה דוחף עובר טסטים אוטומטיים, עולה מיידת ל-Production.
  • יש לנו כמה וכמה אפשרויות, בשביל לאפשר למפתח לבדוק את עצמו -
    • יש לו Kubernetes על ה-Branch שלו,
    • ואז יש Staging שבודק את הכל, אינטגרציה עם כל המערכת.
    • אבל אם זה עבר שם וזה ירוק - אז זה עולה מיידת ל-Production
    • סדר גודל של שעה מהרגע שדחפת את הקוד זה יהיה ב-Production, ולקוחות ירגישו את זה.
(רן) זאת אומרת שאתה לא צריך לעשות, נגיד, Deployment באופן מפורש - כל מה שאתה צריך לעשות זה Merge ל-Master - וזה שם. אוקיי.
ופה - נתקלתם באתגרי רגולציה, בעניין הזה? זאת אומרת - בא אליכם רגולטור ואמר לכם “נו-נו-נו, ככה לא תעשו!” או לחילופין “הייתם צריכים להמציא פתרונות שהם לא, ככה, פתרונות בית ספר ל-Continuous Deployment?
  • (שי) האמת שעד היום לא . . . אני מקווה שהם לא מקשיבים, אולי זה ידליק להם איזושהי נורה . . . [הניסוי ב-Bumpers הראה סימנים ש-AWS מקשיבים, אז לך תדע]
  • אבל לא - זו יותר אחריות שלנו לבדוק את האיכות, ובסוף לבדוק שבאמת התוצאות שאנחנו מביאים הן תוצאות נכונות.

(אורי) האמת, כשאתה מסתכל על זה, אז בעצם למה לא? כאילו, להיפך - אם אני יכול “לקודד את הרגולציה”, כטסטים לצורך העניין, שהרגולציה כל הזמן תבדוק שאני עומד ברגולציה - אז למה לא? להיפך, CI יותר בנוי לזה מאשר . . .
(רן) כן . . . דרך אגב, כבר המצאתי Acronym חדש בראש שלי, תיכף אני אגלה לכם . . .
אז יש DevOps ויש DevSecOps, נכון? ויש MLOps - האם יש כבר RegulOps? . . . צריך עוד קצת לעבוד על המיתוג, אבל האם יש איזשהו סט של כלים שאתם פיתחתם, או אולי שאתה מכיר . . .
(אורי) זה CR - Continuous Regulation . . .
  • (שי) כן . . . כשאני חושב על זה ככה, אז כן - יש לנו דוחות שאנחנו מוציאים ברמה השבועית
  • נגיד, ביטוח אובדן כושר עבודה הוא אחד המסוכנים, מבחינת המדינה - והם מבקשים דוחות שבועיים
  • וכל פעם שיש שינוי בפוליסה אנחנו גם מדווחים, אז יש לנו תהליך אוטומטי, וגם המדינה - יש לה API לקבל את זה.
(אורי) זה בסדר - היא מקבלת את הדוחות, אבל מניח שיש דברים שאתם יודעים שצריכים להיות בדוחות האלה, או מה זה “דוח טוב” ומה זה “דוח לא טוב” - אז אפשר לבדוק אוטומטית את הדוח, אם יש בו חריגות או . . .
  • (שי) אנחנו עושים את זה איפה שאפשר, לגמרי - כן.
  • (שי) זה לא שזרקת רעיון - אנחנו חושבים על זה כל הזמן על איך אפשר למדוד את זה יותר טוב
    • אבל לצורך העניין - אם אנחנו מקודדים איזושהי נוסחא, ואחרי זה אני אבדוק את התוצאות, שהן באמת יצאו לפי הנוסחא, אז זו אותה הבדיקה.
    • אז אולי אני לא אשבור קומפטביליות (Compatibility), אבל זה לא יעזור לי לבדוק שלא טעיתי בנוסחא, נגיד.
(אורי) כן, בדרך כלל לבדוק נוסחא על ידי נוסחא זה לא זה . . . העניין הוא שבנוסחא, לפעמים, פקטור מסויים מצד-שלישי משתנה לך במקום אחר, או מ-API אחר שהבאת את הפקטור הזה - ופתאום התוצאות מתחילות לקבל סטייה לכיוון מסויים.
אם יש לך את הבקרה הזאת, את ה-Monitoring, שהדוח שאתה בעצם הולך לשלוח לרגולטור - אתה עובר עליו לפני זה ואתה אומר “רגע, יש פה בעיה, אין סיכוי שהרגולטור הולך לקבל את זה” . . .
  • (שי) כן - אנחנו בודקים ויש לנו כל מיני סיכומים כאלה שאנחנו בודקים ורואים שהמספרים מסתדרים.
  • לא יודע, צריך לחשוב . . כאילו, זה עד רמה מסויימת, בוא נגיד.

(רן) היה ולצורך העניין אתם מגיעים למצב שבו אתם נאלצים להיעצר - בין אם זה כי מחכים למישהו או מחכים, אני לא יודע, לאישור או לדברים אחרים - ואתם בכל זאת רוצים להמשיך . . .
בהכנה שעשינו כתבת שיש לכם איזשהו עיקרון שנקרא Be Unstoppable - חשבתי שאולי תוכל לספר לנו על דוגמאות של מה עשיתם כדי שלא יעצרו אתכם, למרות שרצו שתעצרו ...
  • (שי) למשל, היום אנחנו חברת ביטוח - בהתחלה לא היינו חברת ביטוח -
    • ובשביל להיות חברת ביטוח, אתה חייב לפחות במשך שנה למכור פוליסות של אחרים, בתור סוכן
    • אחרי זה - למכור עוד שנה או שנתיים פוליסות על נייר של חברה אחרת, גם אם זה פוליסות שאתה הגדרת
    • ורק אחרי זה הם יחשבו לתת לך להיות חברת ביטוח
  • בסדר, זה לא אמור לעצור אותנו - כי בעצם בשלב הזה, בשלב ההתחלתי, מה שהיה חשוב לנו , גם מ-Lean Startup, זה Maximize Learning, לא Maximize Performance או Revenue או Customers . . .
    • אז מה שעשינו זה שהיינו מוכרים פוליסות של אחרים - אבל היינו מנסים לראות מה אנשים רוצים.
    • למשל - איזה מהשישה סוגים שדיברתי עליהם, של הסוגי הביטוח - יותר כדי להתחיל איתו, כדי שנבין איפה נכון לנו . . .
  • (רן) זאת אומרת - מכרתם Back-to-Back, למעשה, מוצרים של אחרים, רק כדי שתוכלו ללמוד ולהבין מה השוק באמת רוצה, כדי שכשתקבלו - לכשתקבלו - אישור של חברת ביטוח, אז כבר תיהיה לכם את הלמידה הזו.
  • (שי) כן, ובינתיים כבר עשינו כסף, כבר למדנו, כבר ראינו תביעות . . . התחלנו לצבור את הדאטה.
    • מה צריך לעשות, איזה שירות צריך לתת אחרי זה . . .
    • למדנו את כל מה שצריך דרך זה, לגמרי.
    • זו דוגמא אחת.

(רן) אחד האתגרים של חברות שגדלות מהר - ואורי קצת רמז מקודם שאתם גדלים מהר - הגידול בכוח אדם, הגידול בגיוון של הביזנס . . . איך מנהלים את כל זה? האם יש שינויים במבנה הארגוני שיצא לכם לעשות? Squads, גילדות או דברים בסגנון הזה?
(אורי) ויותר מזה - איפה . . . צמיחה גדולה פוגשת רגולציה, כי רגולציה - יש בה גם התמחות, אנשים מתמחים במקומות מסויימים, ופתאום הם עוברים מקום או קבוצה או כאלה . . .
  • (שי) כשהתחלנו, עבדנו בשיטה כזו של צוותים, של Frontend - Backend
  • באיזשהו שלב עברנו לשיטה של Squads - זאת אומרת התחלנו את זה, עוד פעם, באיזשהו ניסוי פנימי, עשינו צוות אחד כזה, ראינו שזה עובד טוב
  • היום אנחנו, יש לנו כבר 11-12 Squads, שמעורבים שם Frontend ו-Backend, ואיש - אנחנו קוראים לזה Insurance Product Manager, ו-Product Manager
    • אז ה-Insurance Product Manager, למשל, נשאר עם אותו Squad שאחראי לאותו מוצר עסקי, והוא זה שמשמר אצלו את הידע
    • יכול להיות שהמפתחים מתחלפים - משתדלים שלא יותר מדי, אבל פעם ברבעון או פעם בשניים יכולים להתחלף אנשים בתוך ה-Squad.
    • גם בשביל לייצר עניין - וגם בשביל להעביר ידע, להעביר פרקטיקות.
(רן) אז Squad, לצורך העניין, זו איזושהי חטיבה מוצרית? - לצורך העניין ביטוחי מכוניות זה Squad? ביטוחי מבנים זה Squad? וכו’ . . .
אני סקרן לדעת - לגבי המנהל, של המוצר הביטוחי, זה אנשים שמגיעים מתחום הביטוח, או שאלו אנשים שמגיעים מעולם המוצר? מה זו ההכלאה הזו?
  • (שי) האמת, חלק מהעניין זה שאנחנו רוצים להיות חברה שהיא אחרת, וקצת מביאה רוח אחרת - הרבה מהגיוסים דווקא לא באים מתחום הביטוח, בכוונה.
    • לצורך העניין, אלה שאצלנו מטפלים בלקוחות צריכים הכשרה של סוכן ביטוח - לקחו אנשים בוגרים מאוניברסיטאות טובות והכשירו אותם להיות סוכני ביטוח, כדי שיבואו ברוח אחרת, ולא ברוח הכבדה של איזו חברה . . .
    • אותו דבר ה-Insurance Product Manager - הוא בא יותר מעולם המוצר, והוא לומד את עולם הביטוח, הרגולציה, מה שצריך . . .
(אורי) והוא כבר יודע לדבר בשפה שאתה לא מבין - או שוכח - מהר מאוד?

(אורי) אני רציתי לשאול . . . זה גם קשור לרגולציה - האם יש לך דרישות מסויימות של Audit? זאת אומרת, אם משהו יתגלה או יגיע אל ה . . . אתה יודע, הוצאת איזשהו נייר, מידע, ללקוח מסויים - והוא היה שגוי. באג - קורה. מה היכולת . . . אני מתאר לעצמי שזו חשיפה מאוד גדולה לחברה - מה היכולת לעשות Back-tracking ולהבין איך זה קרה, למה זה קרה? . . . האם הרגולציה דורשת מכם את יכולת ה-Auditing הזאת?
  • (שי) כן - וזה לא נורא מסובך.
  • אנחנו שומרים כל שינוי במעיין כזה Event sourcing כזה, שומרים את השינוי שקרה לפוליסה, כי לקוחות יכולים לשנות תוך כדי, ואנחנו אז מתמחרים מחדש
    • לדוגמא, אם מישהו, לצורך העניין, הוסיף עוד רכב לביטוח רכב
    • אז אנחנו שומרים את כל השינויים האלה
    • שומרים אפילו את הנוסחא ואת איך שחישבנו ומה היו התהליכים בחישוב - מעיין . . . כמו שאתה רושם במחברת את השלבים של החישוב - אנחנו שומרים את זה.
    • גם בשבילנו, למטרת Debugging - אבל גם אחרי זה אם צריך . . .
  • (אורי) גם את גרסת ה-Deployment של ה-Service שעשה את החישוב?
  • (שי) פחות . . . אבל את גרסת הנוסחא, נגיד, שבה השתמשנו, את גרסת המסמך שהשתמשנו, כן . . .

(רן) אני מניח, אורי, שאתה מדבר מדם ליבך . . . כי דברים כאלה קרו, מה שנקרא הוראות אלה נכתבו בדם” . . .
(אורי) אתה יודע, גם אצלנו [Outbrain] יש . . . כשאתה מעלה גרסא . . . מה זה גרסא? Deployment, לא גרסא כזו של פעם-בחצי-שנה . . . Deployment, ו-Deployments קורים כל הזמן, קורים 250 פעם ביום . . .
אנחנו משתדלים, או [יותר נכון] יש לנו את היכולת להגיד “אוקיי, ה-Deployment קרה פה, בשעה כזו וכזו” ולשים את החתימה הזו גם על המטריקות הביזנסיות (Business Metrics), ככה שאם היה שינוי מסויים במטריקה הביזנסית, אנחנו יכולים ללכת אחורה ולהבין איזו גרסת Deployment שמנו . . .
  • (שי) כן, יש לנו את זה, פחות או יותר.
(רן) דרך אגב, אורי - היום ב-Outbrain אתם עובדים גם ב-Squads?
  • (אורי) אה . . . משהו . . . נכנסים למשהו דומה; זה נקרא Effort team, אבל ללא . . . פחות מתמקדים במוצר אלא מתחילים יותר להתמקד ב-KPI עסקי.
    • ה-Effort - יש לו KPI או קבוצה של KPIs מאותו תחום - והמטרה שלו זה להעלות אותם.
    • ושיעשה איזה מוצר שהוא צריך לעשות כדי לייצר את ה-Impact הזה על ה-KPI.
  • (שי) כן, אנחנו עובדים בצורה דומה - כל Squad הוא לאו דווקא לפי מוצר ביטוחי, כי יש כאלה, למשל, סביב הנושא של Phenomenal Service ללקוחות . . .
    • אז הם מסתכלים על, איך קוראים לזה - OKR או KPI או לא משנה - מסתכלים על NPS, מדד לשביעות רצון לקוחות - והמטרה שלהם היא להעלות את זה ברבעון הזה מ-74 ל-76.
    • איך? אילו פיצ’רים? - כל מפתח יכול לבוא ולתרום לזה ולחשוב על הפיצ’ר.
    • זה מאוד מחבר את האנשים, אני חושב שזה החיבור הזה . . .
    • (אורי) בדיוק - מחבר את האנשים לביזנס.

(רן) כן . . . מה שכל הזמן עומד לי על קצה הלשון זה לשאול: תגיד, איך אתה מוצא עניין בתחום הזה של הביטוח, האפור הזה, של אקטואריה והערכה וסיכון וכל זה? . . . איך אתה מצליח?
ונניח שאתה כן - איך אתה מצליח לרתום את אחרון המפתחים, שיבוא ויביע עניין ותיהיה לו מוטיבציה להבין את הביזנס, להבין את הלקוח בתחום, שאני חייב להגיד - לי הוא נשמע אפור ומשעמם, מה אני אעשה . . .
  • [אפי קצת ענה פה, אחרי העניין של הענקת הפרסים הפיקטיביים והבדיחות-הופכות-בטן . . .]
  • (שי) אה . . . האמת שזה קצת אתגר, אולי כשאנחנו מדברים בהתחלה אז כולם חושבים שזה אפור.
  • כשנכנסים לפרטים, אני חושב ש . . . [זה ניהיה ממש אפור?]
    • א. אנחנו נוגעים באנשים - אנחנו עוזרים לאנשים;
      • הרי בסוף, מה זה עסקים קטנים? זה כל פרילנסר שעובד, כל חשמלאי . . . לכל אחד יש מישהו כזה במשפחה, וזה מאוד ברור למה הוא צריך את הביטוח, איך אנחנו יכולים לעזור לו . . .
      • המטרה שלנו היא שהוא לא יחשוב על הביטוח, אלא שהוא יחשוב על העבודה שלו, ואנחנו נטפל לו בכל הביטוח מסביב.
      • אז זה אחד
    • השני (ב) - אנחנו רוצים שבאמת . . תראו, אני חושב שבוא נגיד, בתור מפתח - חלק מהכיף זה לדעת שיש לקוח שישתמש במה שעשית ולראות אותו משתמש בפיצ’ר, זה גם גאווה וזה גם כיף.
      • מה שאנחנו עושים זה סשנים כאלה של - אנחנו קוראים לזה Shadowing:
      • למי שמפתח את הכלים, לסוכנים שלנו וזה - פשוט יושבים עם אחד האנשים האלה שעה, לפחות שעה ברבעון, וממש מסתכלים מה הוא עושה
      • הם בארה”ב אז עושים Zoom, ופשוט מקשיבים לשיחות - הם רואים איך הוא עונה, איך הוא משתמש בכלים . . .
    • (רן) עם לקוח? זאת אומרת - עם אחד הלקוחות, בעצם?
      • (שי) הלקוח הוא לקוח פנימי - נגיד שהוא הסוכן הפנימי שלנו - ומתקשר אליו הלקוח שלנו [החיצוני], המבוטח - ואומר “אני רוצה לשנות משהו בפוליסה” - והוא עונה לו “אין בעיה, בוא אני אעשה את זה איתך” ורץ על המסמכים ועושה את מה שצריך.
      • זה כיף לראות (א) באיזו מהירות הם עובדים על הכלי ואילו ביצועים הבאנו.
      • אבל (ב) לפעמים זה גם מעצבן לראות שהוא לקח מפה ועשה Copy והסתכל בשני דפים - ואז המפתח אומר ”רגע - אתה צריך את זה מהמסך ההוא? אני אביא לך את זה, אין בעיה”.
      • ועושים אחרי זה . . . אוספים קצת מהדברים האלה, ואנחנו עושים אחרי זה שבוע שנקרא “בליץ” - פשוט לוקחים כמה פיצ’רים כאלה ונותנים להם . . פותרים להם כמה מהטוויקים (Tweak) האלה שעוזרים להם.
        • לפעמים זה דברים קצת יותר מורכבים
      • וזה כיף - כיף לדעת שמישהו עבד קשה, או חשב שככה זה - ואתה אומר “לא, זה תוכנה - אפשר להזיז הכל: הזזנו לך” - ועכשיו הם יעבדו יותר נוח, יותר קל.
      • אנחנו עושים את זה עם לקוחות פנימיים שיש לנו - ואנחנו עושים את זה גם עם לקוחות חיצוניים:
        • אנחנו מקליטים את הסשנים, ורואים מה הלקוחות עשו
        • כמובן Obfuscated - לא רואים פרטים, כרטיסי אשראי וכאלה, אבל רואים
        • אז עשית מסך חדש ואתה רואה שבנאדם נתקע שם על איזה כפתור - אתה מתחיל לחשוב “אולי לא נתתי שם נכון? אולי חסר פה איזה נתון?” כל מיני דברים - ואפשר לעזור לו ממש.
      • אז זה מאוד מחבר את האנשים, לראות בעיניים שעשינו טוב למישהו - אני חושב שזה מאוד כיף.
(אורי) איזור או תחום - וזה לא משנה איזה תחום - כשאתה נכנס אליו, אתה מתחיל להבין את ה-Domain בצורה יותר טובה - בסוף, מפתחים רוצים לשפר משהו,
  • הם נכנסים לאיזור הזה, הם מבינים את הבעיות - וזה מחבר אותם הרבה יותר - אפילו אם זה ביטוח . . .
(רן) כן . . . תראה, גם אני נמצא בתחום משעמם . . . אנשים מסתכלים על זה מבחוץ - אבל מבפנים הבעיות מעניינות, מאתגרות - עדיין, זה . . . אבל הייתי חייב לשאול

(רן) איך אתם מטפלים בנושא של Technical Debt? זה נושא שכל חברה - במיוחד חברה שגדלה מהר - מתמודדת איתו. מה הדרך שלכם?
  • (שי) אני חושב שאחרי שמבינים את המורכבות הזאת - שיש הרבה מוצרים והרבה מדינות . . .
  • המטריצה פה מאוד רחבה, והקוד - קל לו שיסתבך . .
    • אם עכשיו בא איזה . . . במדינה מסויימת צריך . . .אם מבטלים את הפוליסה צריך 45 יום, כשבכל המדינות האחרות זה 30 יום.
    • אז אפשר להוסיף שם איזה If על המדינה הזו, ואפשר לעשות משהו יותר טוב . . . חשוב לנו לתקן את זה
    • חלק מזה אנחנו עושים תוך כדי . . .
(רן) אז ה-KPI שלכם זה לעשות grep על הקוד כל יום חמישי במדינות של ארה”ב, ושהתוצאות יהיו כמה שיותר נמוכות? כמה שפחות? . . .
  • (שי) אפשר להגיד . . . אנחנו לא עושים את עם grep, אבל אפשר להגיד.
  • אז אנחנו עושים את זה גם Ongoing, כל הזמן, וחלק מהעניין ב-PR-ים זה להסתכל על הקריאות והנכונות של הקוד וכו’.
  • וחלק אנחנו עושים - פעם ברבעון אנחנו עושים שבוע, עוצרים הכל
    • אומרים ל-Product “תשכחו מאיתנו לשבוע, אנחנו מסדרים דברים”
    • וזה המקום לעשות דברים שלוקחים יותר מ-refactoring כזה של כמה שעות
    • או לפעמים אנחנו קוראים לזה Gardening, שזה תיקונים קטנים - לשנות שמות של מתודות כדי שיהיה יותר קל לקרוא, יותר ברור.
    • אבל בשבוע כזה אפשר לעשות גם מהפכות יותר משמעויות - אנחנו עושים כזה פעם ברבעון.
(אורי) מי מחליט אילו מהפכות עושים בשבוע כזה? מי מתכנן את השבוע הזה?
  • (שי) זה כל צוות לעצמו.
(אורי) הצוותים? ויש לפעמים . . .אני פשוט זוכר את זה מאצלנו - יש את ה Tech-debt של הצוותים, שהם מאוד אוהבים לדאוג לזה ואתה נותן להם את הזמן לדאוג לזה וכו’ - אבל יש גם “Tech-Debt ארגוני”
  • למשל - להחליף Infrastructure מסויים, אוקיי?
  • להחליף או לשדרג גרסא של משהו . . .
אם לא תעשה את זה בצורה מאורגנת, אין אינטרס לצוותים להכנס בכלל לצרה הזאת . . .
  • (שי) יש דברים כאלה, שהם יותר רחבים . . . יכולת להגיד שאם כל צוות קובע לעצמו, אז שיקבע לעצמו גם באיזה שבוע, זה לא חייב להיות כולם באותו השבוע, להסתדר, נכון?
  • אז אנחנו כן עושים את זה ככה, כדי שכן יהיה אפשר לעשות את הקפיצה הזאת ביחד, באותו שבוע, איפה שצריך.
  • לפעמים יש דברים יותר גדולים, יותר ארוכים - חלק מהשיח שלנו עם ה-Product זה בעצם להקצות לזה זמן, ואנחנו פשוט מקצים לזה אנשים.
    • אם זה משהו שצריך לעשות רבעון שלם - אנחנו נשים על זה בנאדם שירוץ על זה.
    • אז הוא יושאל מהצוות שלו, לצורך העניין, על המשימה הזאת - יעבוד על זה רצוף, ואחרי זה יחזור.

(אורי) יש לכם . . . - אתם עובדים הרי ב-Squads - יש גילדות, או משהו, שנגיד, מאחד את כל אנשי ה-Backend או את כל אנשי ה-Frontend וכו’ . . . [367 Guilds at Outbrain]
  • (שי) כן, אז יש לנו כזה
  • התחלנו מגילדה ל-Backend וגילדה ל-Frontend
    • היום ה-Backend לבד, נראה לי , זה מעל ל-70 איש
  • עשרות Services - יש כבר Services שמפוזרים על כמה צוותים, אז התחילו גם גילדות קטנות, של כמה צוותים שעוסקים בנושא מסויים ומשתמשים בעצם באותם Services ועובדים על זה ביחד - אז הם עושים מיני-גילדות של דברים כאלה, אז גם זה יש.
(אורי) אצלנו, נגיד, כחלק מהאחריות של הגילדה - זה גם ה-Tech-Debt הארגוני:
  • זאת אומרת - יש פרויקטים ארגוניים, שהגידלה אומרת “עכשיו, את זה צריך לעשות לרוחב כל הצוותים וכל ה-Services” - ואנחנו במאות Services.
  • “נא, כל צוות - תנו . . .” יש שבוע ברבעון שכל עובד מושאל לגילדה, ל”מילואים”, זאת אומרת - תמיד יש “כוח מילואים בקו”, שמטפל כל הזמן ב-Tech-Debt ארגוני, והגילדה אחראית לסידור העבודה הזה.
  • לא רק למי שמגיע - זה קשור לצוות - אבל גם מה הוא עושה ובמה הוא מטפל.
  • (שי) אז רק שאני אבין - אתה אומר שלאורך הרבעון, בכל שבוע זה יהיה מישהו אחר, יש תורנות כזו, “מחליפים קו” כל שבוע [אבט”ש?]?
  • (אורי) לא - יש שבוע ברבעון, שמפתח מוקצה לגילדה.
    • הצוות יכול, במהלך הרבעון, להגיד “אוקיי, אני בשבועות האלה והאלה משאיל בנאדם לגילדה”
    • זה גורם לזה שלאורך כל הרבעון, לארכיטקטים של הגילדה יש עוד כוח עבודה, “במילואים”, שמטפל כל הזמן ב-Tech-Debt הארגוני, ויכול, או שסביר להניח, שהם יטפלו ב-Tech-Debt הארגוני שקשור ל-Services שלהם.
    • זאת אומרת - כשצריך להחליף גרסא של משהו, או לשדרג Infrastructure מסויים - אז הם יעשו את העבודה הזאת, על ה-Services של הצוות שלהם.
  • (שי) אבל יש “גרעין” לגילדה, שהוא . . . ?
  • (אורי) יש את הארכיטקטים של הגילדה, שהם כל הזמן שם.
  • (שי) הבנתי

(רן) מה שרציתי לשאול אותך, שי - אז אמרת שיש שבוע אחד ברבעון, שבו כל צוות עושה את עבודות ה”תשלומי ה-Technical Debt שלו” - אבל האם זה לא יוצר מצב שבו דוחים את הדברים לאותו השבוע? זאת אומרת, האם זה לא מייצר מצב שבו בכל שאר השבועות ברבעון לא עושים?
אז כן, הזכרת כל מיני Grooming ופעילויות “גינון” קטנות, אבל השאלה היא, אתה יודע - אם יש שבוע שבו עושים את התיקונים הגדולים, האם בכל שאר הזמן . . .
  • (שי) הנטייה לדחות לשם את הדברים? . . . אנחנו מאוד משתדלים להימנע מזה.
  • בטח אם זה יום-יומיים, אז עדיף לא לחכות ולא להשאיר את הדברים לשם.
  • חלק ממה שאנחנו עושים מבחינת התכנון בהקשר הזה - “ההסכם” שלנו עם ה-Product זה שבכל הצוותים יש לפחות 20% ל-Technical
    • ואז זה אומר שאם יש לנו Estimate על משימה שתיקח 10 ימים - אז היא לא תיקח שבועיים, אלא 4 ימים בשבוע הראשון ועוד 4 ימים בשבוע השני - ונשארו עוד יומיים בשבוע השלישי.
    • וככה אנחנו פורשים את זה.
  • זה אמור להשאיר מספיק זמן גם לאיפה שרוצים לחרוג טיפה ולהגיד “אוקיי, נגעתי פה, ובשביל Boy Scout Rule צריך להשקיע פה עוד יום ולעשות Refactoring” אז נעשה את זה.
  • ואם יש עכשיו Production error אז תקפוץ על זה ותעשה את זה
  • אז אנחנו משתדלים להקצות לזה זמן - וזה סוג של משמעת עצמית, צוותית . . . כן.
  • (רן) דרך אגב - אני לא יודע אם אתם עוד שם, אבל יש את הקונספקט הזה . . למי שקרא את ה SRE Book של Google, בטח מכיר את הנושא של Error Budgets
    • זאת אומרת - הזכרת שאם יש תקלות ב-Production, אז משקיעים עוד יום
    • אז שם זה קצת יותר מפורמל (Formalized), ואומרים שלכל צוות יש איזשהו “Budget של שגיאות” - ואם הוא חורג מה-Budget הזה, הוא לא יכול להמשיך בפיתוח של פיצ’רים חדשים, אלא חייב להשקיע בתיקונים של ה-Technical Debt, שימנעו את התקלות הבאות
    • זאת אומרת שהם באים ואומרים “אוקיי, זה בסדר שיש תקלות - אבל אם הגזמת אז, חבוב, תעצור” -
      • תעצור את פיתוח המוצר, זה אפילו לא לשיקול דעתך - ובוא תתקן את התשתיות שלך
      • וספציפית - תתקן את הדברים שגרמו לאותן שגיאות.
    • אז זה יכול להיות שבוע ברבעון, אבל זה יכול להיות גם חצי-רבעון - אם לצורך העניין היו לך הרבה מאוד שגיאות, אז אתה “תאלץ” להשקיע בזה, תשקיע בזה יותר זמן כי פשוט כבר היית בחוב ענקי.
  • (אורי) אבל זה גם, כאילו - זו “הענשה” שגורמת קצת ל”דיר באלאק” אצל ה-Product Manager, שלא רוצה לתת זמן ל-Tech Debt, כי הוא יודע שבשלב מסויים הוא יגיע למקום הזה שיעצרו לו את הפיתוח.
  • (רן) כן, זה סוג של איזשהו מנגנון של איזונים ובלמים, שבה לאזן בין הרצון של . . . נקרא לזה “אנשי ה-Product”, או לפחות אלה שיש להם את “כובע ה-Product” על הראש
    • הרבה פעמים זה גם מפתחים - גם מפתחים רוצים לייצר פיצ’רים, לא רק אנשי Product
    • אבל איזשהו איזון בין “אנשים עם כובע ה-Product על הראש” לבין אנשי ה-Production
    • כששוב - אלו יכולים להיות אותם מפתחים, אבל הם גם אלה שרוצים שהמערכת תיהיה יציבה
    • אז זה איזשהו סוג של מנגנון אובייקטיבי, [שבא] לייצר את האיזון הזה ביניהם - אבל כזה שהוא דינאמי
      • גם שבוע ברבעון זה אובייקטיבי, אבל זה לא דינאמי: זה שבוע ברבעון.
    • אבל כן - אני מניח שזה משהו שמתאים גם לחברות שהן קצת יותר “מתבגרות” - ואתם עדיין לא שם.
  • (שי) נגיד, באיזור של שגיאות מ-Production ודברים כאלה - אמרנו משהו כמו כמו “Zero Bug Policy”:
    • יש פה איזשהו מקדם שאפשר . . . אבל עד 10 לקבוצה
      • קבוצה גדולה, כן? 40-50 איש - עשרה באגים כאלה פתוחים
      • אם יש מעבר - עוצרים ומתקנים
      • אנחנו מצליחים בדר”כ לתקן תוך כדי, אז אנחנו משתדלים לא להגיע לעשרה
  • איפה נתקלנו בזה? דיברנו על רגולציה - יש לנו צוות שלם שעסוק ב-Compliance - בדיוק בדברים האלה
    • לראות שלא טעינו ולא זה . . .
    • ואם הייתה שם איזושהי שגיאת Audit - גם את ה-Product זה לא מעניין וגם את המפתח זה לא מעניין - “שה-Compliance ישברו את הראש”
    • אבל מה לעשות שהם לא יכולים לתקן את הקוד? אז שם בדיוק עשינו Budget כזה - ושם, לפי ה-Severity של הבעיה, סופרים נקודות
      • והצוות לא יכול לעבור X נקודות
      • ואם הוא עובר - עוצרים ומתקנים את הבעיית Compliance הזאת, שאף אחד לא רצה לגעת בה.
    • אז הגענו גם לזה, אני חושב, באיזור מסויים - איפה שראינו שזה, יחסית, “מוזנח”.
    • בדברים האחרים אנחנו מצליחים כן לעבוד על זה - כולל אם יש משהו שצריך, ככה . . .
      • דיברתם קצת קודם על “הענשה” [ענישה] - אנחנו מעדיפים לא להעניש, יש לנו עיקרון של Play as a Team
      • מעדיפים לעזור אחד לשני - משהו שמגיע גם מהמנכ”ל, שאומר, כשבאים ושואלים אותו “יש לי פה . . . אני יכול לעזור למישהו אבל אז אני לא אעמוד ביעדים שלי”, אז הוא אומר “קודם כל תעזור למישהו - בסוף אתה גם תצליח לעמוד ביעדים, וגם הוא יעמוד ביעדים”.
      • אז למשל כשל-Product . . . אנחנו באים אליהם ואומרים שנתקענו באיזשהו איזור בעייתי שנתקלנו בו, ואנחנו רואים עכשיו שלרבעון הבא לא נצליח לעמוד בדברים כי יש פה קוד שהסתבך לנו, ואנחנו רוצים לעשות Refactoring משמעותי, להפריד Services, מה שזה לא יהיה - אז אנחנו מקבלים את הזמן
      • זאת אומרת - אנחנו מצליחים להגיע להסכמה של “יאללה, קחו בנאדם, שימו אותו בצד שיעשה את זה” - וברבעון הבא נוכל לרוץ יותר מהר
      • אם עד עכשיו זה עובד לנו די בסדר - נחכה עוד שבועיים, נגמור את הפיצ’ר ואז - זה גם בסדר, או שתעשה את זה ברבעון הבא.
      • אבל הצלחנו עד עכשיו לטפל בזה ככה.
  • (אורי) גם ככל שחברה גדלה מהר יותר, אז ה-Business גדל מהר יותר, כמות הפיצ’רים וה-Complexity של הקוד עולה אקספוננציאלית - ואתה מוצא את עצמך כמעט כל הזמן ב-Refactoring . . .
  • (שי) כן, זה קורה - אנחנו רואים צוותים שגדלו, Services שגדלו וצריך לשבור את ה-Service לכמה חלקים - משקיעים גם בזה.
    • זה חובה, אני חושב - כי אחרת זה בדיוק העניין של “לרוץ מהר”, אתה חייב לתקן את זה, כי אחרת אתה תתחיל לרוץ מאוד לאט.

(רן) טוב, שי, אנחנו כבר ככה כמעט לקראת סוף הזמן - אני מנחש שאתם . . . הזכרנו שאתם גדלים ומגייסים, אז מה אתם יכול לספר לנו בעניין?
  • (שי) אנחנו מגייסים המון . . . אנחנו מגייסים המון, ויש המון תפקידים
  • גם ארכיטקטים, גם ראשי צוותים, גם מפתחים
  • מחפשים אנשים שאוהבים אנשים, אוהבים את הלקוחות, אוהבים לעשות טוב ללקוחות
  • וגם שאוהבים ללמוד ולהיות מקצוענים - אנחנו מאוד משקיעים בלמידה של אנשים, לא רק בתחומי הביטוח אלא גם בתחומי הפיתוח יותר.
(רן) קצת על ה-Stack הטכנולוגי שלכם - איך הוא נראה?
  • (שי) אנחנו, ב-Backend, אני חושב שהיינו, אולי, חלק מהמשוגעים הראשונים שעשו Kotlin ב-Server-side - והיום הכל Kotlin,
    • זאת אומרת - התחלנו עם קצת Java, אבל מאוד התלהבו מזה - אנשים שהם מפתחי Java נכנסים לזה מאוד מהר ואוהבים את זה
    • קצת קשה להם לחזור אחורה . . .אבל מאוד אוהבים Kotlin.
    • עם Drop Wizard, הרבה MySQL, זה כל ה-Backend.
  • וב-Frontend יש לנו Angular ,יש React, יש Node
    • משתדלים לעדכן גרסאות, להיות בקדמה של הגרסאות האלה.
(רן) מעולה - איפה אתם יושבים, דרך אגב, בישראל?
(אורי) אגב - כמה אנשים בחברה, בסך הכל?
  • (שי) אנחנו היום, אני חושב, באיזור ה-500 . . .
(אורי) אוקיי - והרוב באמת סוכנים כאלה?
  • (שי) לא . . . שמע, יש סדר גודל של . . . דיברנו על 120 בפיתוח, ויש עוד הרבה במוצר . . .
    • יש משהו כמו 100 סוכנים בסך הכל, אני חושב.

(רן) אוקיי - היה תענוג. שי - תודה רבה שבאת
(שי) תודה לכם
(רן) ובהצלחה!

עודו רפרנס שלא נכנס להקלטה -




הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

330 פרקים