פרק 462 של רברס עם פלטפורמה שנולד ב-4 ביולי (2023) - אורי ורן מארחים באולפן בכרכור את גיא ואלירן מחברת Melio, אחרי הפסקה קלה בהקלטות, כדי לדבר על מתי נכון להפוך את המוצר שלנו לפלטפורמה [Pun intended].
01:06 גיא ואלירן . . .
(רן) ולפני כן, בואו קצת נכיר את החברים. אז גיא - Shoot:
- (גיא) אהלן, קודם כל, כיף להיות פה, תודה שהזמנתם אותנו.
- (אורי) המזגן בטמפרטורה הנכונה?
- (גיא) המזגן בול, כן . . . אז אני גיא ציפורי - היום אני ה-VP R&D ב-Melio.
- לא מעט שנים בתעשייה, סטארטאפים . . . בעיקר סטארטאפים, בגדלים שונים ובעולמות שונים.
- בעולמות של סייבר, ואחרי זה Video Optimization ואחרי זה Real-Estate Technologies
- והיום ב-FinTech.
- זהו, In a nutshell.
- (אלירן) כן, היי . . . . אז אני אלירן גולדשטיין, מנהל פיתוח ב-Melio.
- בתעשייה, בוא נגיד, קצת יותר מעשור.
- עושה בעיקר, בעיקר Frontend ופלטפורמיזציות (Platformization) - אבל לא רק.
- וזהו . . .
02:20 . . . ו-Melio
(רן) מעולה. אז לפני משהו כמו שנה + היו פה אור ואילן מ-Melio [פרק 424 Melio’s payment processor], ואולי סיפרו לנו אז - אבל יכול להיות שחלק מהמאזינים שכחו [?!], אז בכמה מילים: מה היא Melio? מה היא עושה, ומה הצד הטכנולוגי שלה?
- (גיא) אני אתן לך, אתה ותיק יותר . . .
- (אלירן) יאללה, בסדר . . . . אז Melio בעצם באה לפתור בעיה של תשלום חשבנות לעסקים קטנים.
- זה עולם גדול, ומהצד הוא נראה לא כל כך מובן - אבל עסקים צריכים לשלם חשבונות, לספקים שלהם . . .
- ובארצות הברית, זה תחום שמגלגל המון, המון, המון כסף.
- אז Melio בעצם נכנסה לנישה הזאת, של בין עסק קטן - זה יכול להיות עסק שהוא חנות מכולת, חנות יין, . . . . באמת עסקים שבדרך כלל יש בהם עובד אחד או שניים, לפעמים קצת יותר - לבין התשלום חשבונות שלהם.
- באנו לייעל את האזור הזה.
- רק כדי לתת איזה פחות או יותר סדר גודל - זה שוק של משהו כמו 14 טריליון דולר בשנה - שעובר בצ'קים לרוב.
- זאת אומרת, לרוב משלמים את זה עדיין בצ'קים, קצת פתרונות של העולם הישן
- ואם אפשר To digitize - אז למה לא?
(רן) אז כשמשקיעים אומרים ליזם ישראלי “אני אכתוב לך צ'ק”, לפעמים מתכוונים לזה . . .
- (אלירן) ממש ככה . . . .
- אז בעצם, Melio נכנסה לנישה הזו לפני משהו כמו ארבע שנים, הפכה להיות גדולה מאוד, מהר מאוד
- בזכות שיתוף פעולה שלנו עם חברת Intuit, שיש להם את המוצר הנהלת-החשבנות הכי גדול בארצות הברית, ובעולם בעצם - QuickBooks.
- (רן) . . . כל מי שאי פעם עשה מיסים בארצות הברית, כנראה מכיר את Intuit . . .
- (אלירן) כן, הוא יודע - או TurboTax או QuickBooks, הוא ישתמש . . . .
- אז בעצם Melio היא גם מוצר שהוא Standalone-י וגם מוצר שמוטמע בעצם בתוך מערכות אחרות, בתור פתרון תשלום חשבונות.
- אז זה ממש ממש In a nutshell . . . . אנחנו עושים עוד דברים מאז - ובעוד מקומות - אבל זה פחות או יותר Melio.
(רן) מעולה . . . .
- (גיא) אולי אני אוסיף, רק כדי . . . איפה אנחנו נמצאים היום ב-Cycle של Melio.
- אז Melio קיימת קצת יותר מארבע שנים, והזכרת את אילן - אז אילן הוא אחד משלושת ה-Co-Founders וה-CTO של Melio.
- ואנחנו היום משרתים למעלה מ-100,000 עסקים בארצות הברית, ומעבירים עשרות מיליארדים של דולרים כבר היום בפלטפורמה.
- בחברה יש קרוב ל-600 עובדים - קצת יותר מחצי פה בישראל
- “ופה בישראל” זה בעצם בעיקר מרכז הפיתוח - קצת יותר מ-200 Engineers בצוות.
- אז זה, פחות או יותר, איפה שאנחנו נמצאים.
- החברה גייסה למעלה מחצי מיליארד דולר כבר, וממשיכה לצמוח As we Speak . . .
04:58 מוצר פנימי
(רן) אז קודם כל - שיהיה בהצלחה! . . .
- (אלירן) . . . ממש ברגעים אלו צמחנו עוד קצת . . . זה ממש עכשיו,
(אורי) אם תהיו בשקט, אפשר לשמוע את מה שיוצא . . . .
אז אני חושב שכל מי שמפתח, כשהוא כותב איזושהי שורת קוד או כשהוא כותב איזושהי פונקציה - בעצם הוא שואל, באיזשהו שלב הוא שואל את עצמו “אולי כדאי שנעשה איזו ספרייה, אולי כדאי . . . אולי מישהו ירצה לעשות לזה איזשהו re-use . . . אולי ככה . . . .”.
הלבטים האלה עוברים, ואם לוקחים איזושהי דרגה אחת ככה למעלה, אז לפעמים גם נכון לקחת את מה שבניתם ולעשות מזה מוצר - מוצר פנימי. ועל זה אנחנו רוצים בעצם לדבר היום - מתי נכון לקחת כלים פנימיים שכתבנו ולעשות מוצר פנימי? לפעמים זה אפילו מוצר חיצוני, אבל בואו נתחיל, ככה, “בקטן” . . .
אולי נתחיל מאיזשהו סיפור? זאת אומרת - קרה לכם לאחרונה, או אולי לא לאחרונה, אבל שהייתם בנקודת ההחלטה הזו, של “האם נכון לקחת איזשהו משהו שנכתב ולמצר [Productize] אותו?”
- (גיא) אז אני חושב שאחד הדברים שמעניינים אולי בסיפור של Melio, בהקשר של פלטפורמיזציה (Platformization), זה שהפלטפורמה שבנינו בעצם במקור לא נועדה לשרת איזשהו כאב פנימי - אלא דווקא את היכולת שלנו להמשיך לגדול ולהתפתח.
- ואני אספר רגע, היסטורית . . . .
(אורי) אל מול הלקוחות או . . . .?
- (גיא) כן - בעצם, המוצר שאנחנו מוכרים החוצה הוא פלטפורמה . . . .
- היום, יש לנו מוצר Standalone - שגם הוא רץ על הפלטפורמה, תיכף ניגע בזה
- והמוצר שאנחנו מוכרים ללקוחות - לא ל-End Users, לאותם עסקים שהזכרנו, אלא לשותפים שלנו, שתיכף נסביר בדיוק מה ההבדל בין שניהם - הוא בעצם הפלטפורמה.
- וההיסטוריה של Melio היא כזאת - אלירן הזכיר את Intuit, אחד השותפים שלנו - אז ל-Melio היה מוצר Standalone על Melio.com
- שאתה, אם אתה עסק, יכול להיכנס, להירשם - ולהתחיל לשלם לספקים שלך.
- ואז הגיעה Intuit - אני עוד לא הייתי ב-Melio אז, אז Keep me honest here . . . אבל הגיעה Intuit, ואמרה “אנחנו רוצים את המוצר הזה, כחלק מהמוצר של Intuit”.
- והפתרון להיות מסוגלים לדלבר (Deliver) את הדבר הזה בצורה מהירה היה Forking - לוקחים את הקוד, בגדול Copy-Paste, ומתחילים לעשות את השינויים שצריך כדי ש . . . . לתת את החוויה, שצריך לתת ל-Intuit בתוך זה. החלטה . . . .
- (אורי) עד רמת ה-UI?
- (גיא) כן . . . .
- (אלירן) עד רמת . . . כמעט כל חלק במוצר.
- (אורי) זאת אומרת שלקחתם כל ה-User Interface של המוצר - והפכתם אותו ל-User Interface . . . ל-Look & Feel של Intuit?
- (אלירן) בדיוק . . . החוויה שבעצם השותף שמנגיש את המוצר שלך - מתוך המוצר שלו, מתוך האפליקציה שלו - החוויה שהוא מחפש, היא חוויה Native-יבית . . . .
- אתה לא רוצה שה-User שלך ירגיש שהוא עבר בין עולם של QuickBooks לבין עולם של Melio.
- אתה לא רוצה איזושהי חוויה של Redirect או Tab חדש או משהו אחר.
- בעצם, זה בעולם של חוויה שהיא יותר Embedded, ה-Look & Feel חייב להיות מאוד דומה לשפה המוצרית של השותף שמטמיע אותך.
08:03 אז API או Copy & Paste?
(אורי) אז תנו לי לשאול את השאלה, שאולי היא הרמה להנחתה, בסדר? - מה שבדרך כלל עושים בשלב הזה זה API . . .
- (גיא) אז באמת, קודם כל. . .
(רן) לא, אורי - למה לעשות API, אם אפשר לעשות Copy-Paste? . . . זה ה-API היעיל ביותר . . .
(אורי) נכון . . .
- (גיא) אז אני חושב שבאמת הנקודה הזאת של Copy-Paste זו נקודה שבה כל Engineer מצטמרר לרגע בכיסא ואומר “איך זה יישמע כלפי חוץ?”
- הרי איך לא מדברים על APIs או על משהו אחר, על פתרונות אחרים.
- אבל אני חושב שזאת אחת ההחלטות המדהימות והגאוניות שאילן ומתן וה-Leadership ב-Melio לקחו באותה נקודת זמן
- כי זה אפשר ל-Melio להגיע ב . . . אפשר אחרי זה לדבר על זמנים של פיתוח הפלטפורמה, אבל זה אפשר להגיע ל-Production עם Intuit, עם שותף ענק - “באפס זמן”.
- יש לזה מחיר שאנחנו ידענו שאולי נצטרך באיזשהו שלב לשלם - אבל הדבר הזה נתן איזושהי מקפצה מאוד משמעותית ל-Melio,
- ופתח בעצם בנקודה הזאת את Melio ממוצר Standalone למוצר שיש לו עוד מודל Distribution מאוד משמעותי בדמות Intuit.
- ואז, סביב האירוע הזה, גם מתחילים פתאום . . . מתחילות שיחות לגבי איזה עוד שותפים יכולים להיות רלוונטיים כמו Intuit - ואולי ניגע בזה בהמשך
- אבל זה הצעד הראשון - הצעד הראשון הוא איזשהו שכפול, ומתחילים לרוץ על שני Repositories, בגדול, במקביל.
אתה יודע שאתה הולך לשלם את זה מתישהו, ואתה מוכן לקחת על עצמך את החוב הזה, כי אתה חושב שזה ישתלם.
- (אלירן) אפשר להסתכל על Technical במובן הזה יותר כמו איזושהי “הלוואה” - כי בסופו של יום סטארטאפים, בטח בתחילת דרכם, הם מאוד מאוד מאוד Delivery-oriented,
- ואם אתה לא עושה את הפשרות שאתה צריך לעשות . . .
- כל ה-Engineers אוהבים את הדברים ה-Pure-יסטיים ביותר
- כלומר אף אחד מאיתנו לא גאה להגיד “עשיתי Fork ל-Repository שלם!” ו-”התחלתי לפתח פיצ'רים פעמיים!” . . . .
- אז זה בטח לא משהו שאתה מגאה בו.
- (רן) לא - “עשיתי Fork ל-Repo שלם - רק כדי לשנות שורה אחת!” . . . .
- (אלירן) נכון . . .
- אז כן, אפשר גם לגעת גם במקומות האלה - אבל השורה התחתונה היא שבסופו של יום אתה צריך לעשות את הפשרות האלה כשה-Business דורש את זה.
- זאת אומרת, אם בסוף האירוע הזה, ה-Bossiness גדל וה-Distribution Channels שלך הם גדלים פי כמה וכמה - זה שווה כל פשרה Engineer-ית שאתה עושה בנקודת הזמן הזו.
(רן) כל עוד, כמובן, אתה לוקח בחשבון שתדע לנקות אחר כך . . .
- (אלירן) נכון, כן . . .
(רן) . . . ואני מניח שפה - לשם ממשיכים.
זאת אומרת, אוקיי - אז עם Intuit זה עבד טוב ופתאום חשבתם לעצמכם “רגע, יש עוד Use Case, יש עוד לקוח” - מה קורה אז?
- (אלירן) בנקודת הזמן של Intuit, אז באמת הפתרון הוא, אתה יודע - להעלות מ-Instance אחד ל-Instance שני
- אבל כשמגיע ה-Instance השלישי אתה כבר צריך להתחיל לחשוב על זה קצת יותר לעומק . . .
(אורי) אתה אומר “Fork אחד-שניים, זה סבבה - אבל מגירת סכו”ם? זה לא . . . “
- (אלירן) כשהגענו לכפיות הקטנות והמגירה . . . לא.
- אבל בנקודת זמן של פרטנר שלישי או פרטנר רביעי, שהופך להיות איזשהו Distribution Channel
- וצריך להסתכל על זה באמת ככה - היכולת Distribution, כשאתה קופץ עם פרטנרים היא גדולה לאין-שיעור בללכת לעשות User Acquisition או ללכת להביא את ה-User-ים שלך בעצמך.
- אתה מקבל פתאום Out Of The Box, כמות די גדולה של User-ים בתוך המוצר שלך - ועבורם זה לא באמת מעניין אם זה כ-Melio, או מוטמע, או בחוויה כזו או אחרת.
- בפרטנר השלישי התחלנו כבר לחשוב על זה קצת יותר לעומק - ואת הפרטנר הרביעי כבר העלינו על פלטפורמה.
- אז אלו בעצם היו פחות או יותר לוחות הזמנים . . . .
- אנחנו מדברים על מסגרת זמנים של כמה שנים של חברה - זאת חברה די צעירה.
- המקום שאנחנו נמצאים בו ביחס לזמן הוא פסיכי.
- אז המעבר הזה בין להיות מאוד Delivery-Oriented ללהתחיל עכשיו להיות Quality או Scale-Oriented - זו הנקודת זמן הזו.
- (גיא) אז אולי מילה אחת על מה זה בעצם הפלטפורמה של Melio, כי פלטפורמה זה גם מילה ש...
- (אלירן) . . .Buzzword בלתי נסבל . . .
(אורי) אנשים מקימים על זה פודקאסטים . . .
(רן) . . . בהפוך על הפוך . . .
- (גיא) אז היום . . . הזכרנו את Intuit, אבל היום המוצר של Melio - הפלטפורמה של Melio - כבר משרתת, הזכרנו קודם, למעלה מ-100,000 User-ים, שנמצאים במה שאנחנו קוראים לו Channel-ים שונים או אצל שותפים שונים.
- אז היום למשל, אם אתה לקוח של Capital One, אחד הבנקים הגדולים בארצות הברית ויש לך חשבון עסקי ואתה נכנס ל-Online Banking שלך ורוצה לשלם לספקים, אז אתה עושה את זה דרך הפלטפורמה של Melio.
- אם אתה היום Merchant ב-Shopify - נדמה לי שלושה מיליון Merchants, אם אני לא טועה בזה - ואתה היום רוצה לשלם לספקים שלך דרך Shopify, אז אנחנו, הפלטפורמת-תשלומים שם.
- עכשיו, החוויה היא חוויית Native - אתה עושה את התהליך, אמנם יש Melio למטה איפשהו, אבל אתה לגמרי בתוך Melio.
- ב-Shopify, ה-Design System הוא Design System של Shopify, שנקרא Polaris.
- ב-Capital One זה Look & Feel של זה . . . .
- עכשיו, Look & Feel זה אלמנט אחד, כן? כל העניין של “איך אני גורם לחוויה להיראות Native-ית”
- משהו שזה כמה רמות מעל White Label, כי זה לא “הנה החוויה - בוא תשנה לוגו, תשנה צבע . . . ”
- אלא אתה מקבל ממש חוויה Native-ית - ויכול לשלוט בה
- איזה Feature-ים דולקים וקבועים?
- איזה Fee אני גובה על כל Feature?
- איזה Promotions אני יכול לתת על כל Feature, מבחינת Fees?
- איזה טקסטים, טון, כן . . .
- אז בעצם אתה מקבל חוויה Native-ית שאתה יכול לשלוט בה - רמת הגמישות שלך היא כמעט אינסופית, במסגרת הצרכים שלך, של המוצר.
- וללקוח זו חוויה Native, שרצה עד הסוף על אותם Repositories, על אותו Database, על אותו Code Base וכו'.
14:11 נפלאות ה-Design System
(אורי) אז השאלה שלי פה תהיה האם זה באמת רק API מתועד - גישות ל-Server - או שיש גם שכבה, איך לקרוא לזה? . . . קצת שכבת-תצוגה, שרק תציג את ה-CSS שלך, לצורך העניין?
- (אלירן) כן, אז זה טיפה יותר מ-CSS . . .
- אז כן, התשובה היא כן, יש בעצם . . . .
- להגיד “פלטפורמה” זה באמת Buzzword, אז בואו נרד קצת שנייה רגע לפרטים:
- אנחנו מדברים על Web Application, ו-Web Application - יש לו חלק Backend וחלק Client-Facing.
- החלק ה-Backend-י מבצע פעולות במערכת
- הוא כן יכול להכיל קונפיגורציות (Configurations) שונות
- הוא כן יכול להתאים את עצמו Per Partner
- יכולים לרוץ על החלק ה-Backend-י הזה מספר אפליקציות שונות - לחלק מהפרטנרים שלנו יש גם גישה לחלקים שהם Public בתוך ה-API הזה
- באזורים האלה הוא יותר Documented, הוא יותר מונגש להם
- הם יכולים בעצם לבנות שם חוויה מאוד Native-ית, באמת בצד “שלהם” - זאת אומרת, לבנות איזשהו Client שמדבר עם ה-API שלנו ישירות, או דרך ה-API שלהם.
- זה החלק ה-Backend-י.
- בחלק ה-Client-Facing, אחד מהיתרונות הגדולים של Melio הוא בעצם הפישוט של החוויה הזו - זאת אומרת, חוויית ביצוע התשלום הופכת להיות מדבר שהוא די סיזיפי
- זאת אומרת, תנסו להיכנס ל-Mind-set של עסק קטן בארצות הברית - הוא צריך לשלם לספקים שלו כל חודש, בדרך כלל הוא צריך לעבור על החשבונות שנשלחו, לכתוב צ'ק ידנית וללכת ולשים אותו מעטפה, לשלוח אותו בדואר או לתת אותו לנציג של אותו ספק שמספק לו את הסחורה . . . .
- פה - במרחק של שניים-שלושה קליקים, אתה יכול לשלם איך שאתה רוצה, באיזו דרך שנוחה לך . . .
- כרטיסי אשראי, אגב, זה משהו שאתה לא יכול לשלם איתו בדרך כלל חשבונות
- אם אתה כותב צ'ק, Melio בעצם מפרידה את השלב של התשלום ואת השלב של הקבלה - ככה שאתה, בתור עסק, יכול לשלם איך שאתה רוצה- והספק שלך יכול לקבל איך שלו זה נוח:
- אם נוח לו בהעברה בנקאית הוא יקבל את זה ככה, אם נוח לו בצ'ק הוא יקבל צ'ק פיזי.
- אז בעצם, אחת מהבשורות הגדולות של Melio לאזור הזה זה בדיוק זה - ה-Decoupleing הזה בין התשלום לבין קבלת הכסף.
- ואם נחזור רגע למוצר - אז בעצם החוויה המוצרית, ה-Client-Facing, היא חוויה מאוד מאוד טובה - אנחנו יודעים לעשות את החוויה הזו.
- גם כשאנחנו מגיעים לפרטנרים, אנחנו צריכים להסביר להם שהם צריכים להטמיע בעצם את החוויה הזו
- זה קצת מסובך לפעמים, לקבל את אותו ה-Value של החוויה המוצרית אם אתה בונה את זה מעל API
- אם הפרטנר - במקרה הזה Melio - יכול לתת לך גם את החוויית UI כבר, Out of the box מוכנה, ובשפה וב-Look & Feel שלך - אז זה Win-Win-Win, לכל כיוון.
- אז בעצם בצד ה-Backend-י, אני חושב שכולם מכירים פחות או יותר API-ים שהם גנריים, כאלה או אחרים, שיכולים לשרת כמה אפליקציות.
- בצד ה-Client-Facing -אז שם באמת עשינו עבודה שהיא קצת יותר “חריגה”, בוא נקרא לזה, מעבודה רגילה של אפליקציות,
- ובעצם בנינו את המוצר מחדש בשכבות - כשהשכבות האלה, בעצם אפשר לבנות איתן, כמו חתיכות לגו, את אותה חוויה מוצרית.
- אז Design System זה קונספט שנראה לי כולנו מכירים
- אז לבנות Design System למוצר שהוא לינארי - מוצר אחד, שפה עיצובית אחת - כולם עושים.
- אני חושב שכל מוצר שמכבד את עצמו יש לו Design System
- אבל אם אתה בונה את ה-Design System הזה בצורה שהיא Theme-able ו-Customizable, ואתה יכול לקסטם (Customize) את הטקסטים, אתה יכול לקסטם את הנראות . . . .
- וזה לא ממש לדרוס את ה-CSS - זה אפילו יותר קל:
- תשנה את הפרמטרים של הפלטת הצבעים (Palette) שלך, או תבחר את הפונטים של המוצר שלך ואת הפינות העגולות או את ה-Shadow-ים, אם זו השפה העיצובית שלך
- וקיבלת חוויה שהיא, Out of the Box, נורא נורא דומה לחוויה שלך . . . .
(אורי) אתה יודע, ב-Design System בדרך כלל יש אלמנטים - אלמנטים של User Experience: כפתור ו-Dropbox ו-Yada-Yada-Yada . . . עכשיו, זה לצורך העניין, זה של הלקוח - של הפרטנר, של Intuit או בנק כזה או אחר.
אתם משתלבים לתוך ה-Design System שלו? או שאתם - יש לכם Design System . . .
- (אלירן) . . . שיודע ללבוש את התצורה שלו . . .
(אורי) . . . אז יבוא Designer שלו, יבנה את האלמנטים - מחדש . . .
- (אלירן) אז לא - הוא בעצם מקבל את החוויה, קומפלט.
- הוא מקבל את החוויה Out of the Box.
- בוא נחשוב על עולמות של Embedded - אם יש לך אפליקציה, במקרה הזה נגיד של Capital One, של הבנק
- אתה נמצא בתוך הבנק, הכל נראה כמו הבנק - כפתורים כחולים ופונט מסוים . . .
- (אורי) . . . עד רמת הפריזנטור . . . .
- (אלירן) בדיוק . . . ברגע שתפתח את החוויה שלנו בתוך הבנק - זה יכול להיות מוטמע בתוך iframe, לצורך העניין במקרה הזה
- עדיין תיהיה לך את אותה שפה עיצובית
- זאת אומרת, אנחנו מנגישים את האפליקציה ב-Look & Feel של הפרטנר.
(אורי) אני מבין - אבל לצורך העניין לבנק הפועלים, יש את ה-Design System שלו, נכון? אתה נותן לו עכשיו Design System אחר, שהוא צריך לעבוד ולקסטם (Customize) אותו ל-Design שלו, או שאתה איכשהו מתחבר ל-Design System שלו? איך קורה “הקסם הזה”?
- (גיא) אז קודם כל, יש לנו אימפלימנטציות (Implementations) שונות היום.
- בדוגמה של Shopify למשל, יש להם Design System שנקרא Polaris - מאוד strict.
- הדיזיינרית (Designer) שלנו במקרה הזה, ישבה עם ה-Design System שלו - ועיצבה את החוויה
- כאילו, דאגה לזה שזה ייראה ב-Design System של Shopify.
- ובדרך כלל, אגב, אנחנו . . . יש מקומות שהם פחות strict, כמו Capital One, אבל מבחינת ה-Design - אתה תקבל את החוויה
- זו עבודה שאנחנו בדרך כלל עושים.
- כי ההתאמה מהעיצוב שלו לחוויה שלנו תחת ה-Design System שלו היא התאמה שעשינו אותה קלה.
- כלומר, הוא לא צריך לעשות שום דבר - בסופו של דבר, האימפלימנטציה (Implementation) אצלו זה שורת JavaScript שהוא זורק על הדף, ומשם קורה “הקסם” בחוויה שלו.
20:25 תרבות של Copy-Paste?
(רן) יש לי שאלה, ככה, קצת יותר “תרבותית-ניהולית”: אתם נמצאים בנקודת החלטה שבה צריך להחליט האם עושים Copy-Paste, או שעושים עבודה יותר יסודית - ומחליטים לעשות Copy-Paste, וזו כנראה הייתה ההחלטה העסקית הנכונה, מצויין.
אבל באותו רגע גם קיים חשש של “רגע, מה יקרה לתרבות הפיתוח בחברה?” זאת אומרת, עכשיו כל מפתח חדש יבוא, יסתכל על שני ה-Repos האלה ויגיד “לא, רגע, מה קורה פה? כאילו, מה החבר'ה לא יודעים לבנות API? למה הם עושים Copy-Paste? הם לא יודעים לייצר ספריות?” . . . .
איך אתם דואגים, מצד אחד, לקדם את האינטרס העסקי הנכון - ומצד שני, עדיין לבוא ולצייר את הקו הזה על הקרקע, ולבוא ולהגיד “חבר'ה, נכון, עשינו פה את ההחלטה, באיזשהו שלב אנחנו גם אולי נתקן את זה - אבל אתם לא עכשיו הולכים לעשות Copy-Paste על כל Shit קטן שאתם מתכוונים לעשות . . . .”.
- (גיא) אז אני חושב שכמה דברים, חלקם אולי יותר תרבותיים וחלקם יותר Structure-יים.
- בפן התרבותי, אני חושב שאף אחד לא מדבר על זה - שזאת הדרך הנכונה ברמה ה-Engineer-ית,
- אלא אנשים מבינים את ההחלטה, אנשים גם ראו קצת . . . . אני לא זוכר בדיוק בלוחות זמנים כמה זמן אחר כך הם ראו גם את האימפקט (Impact) של ההחלטה
- והם מבינים שמדובר פה בהחלטה שהיא הייתה נכונה - ושהיא בסוף עוזרת לנו לגדול, להתפתח, להבין מי אנחנו, לשלם את המשכורות של כולנו וכו’ . . .
- ואז מתחיל ה-Effort שחלקו הוא גם Structure-י - אלירן, שמוביל את ה-Effort הזה, בעצם מקים קבוצה ומתחיל איזשהו תהליך, שאנשים רואים אותו ומבינים לאן הם הולכים.
- ואז יש את ההבנה של “הדבר הזה לא נעשה כי אנחנו לא מבינים, להיפך” - הוא נעשה כי אנחנו מבינים את הצורך העסקי, אבל אנחנו גם יודעים מה הדבר הנכון לעשות ואנחנו משקיעים בו
- יש שם Investment גדול,
- ובשלב הזה, אנחנו גם לא יודעים האם יהיה לנו עוד שלושה Intuit, עשרה Intuit או זה . . .
- והיום, אגב, הזכרנו כמה מהשמות - אבל אנחנו בשנה הקרובה . . . אנחנו כבר נהיה במאות בנקים אמריקאיים.
- אז היום כולם מבינים גם את ההיסטוריה - גם לאן אנחנו הולכים, וגם הפלטפורמה עוברת אבולוציה כל הזמן
- ואנחנו היום עושים הרבה Investment בפלטפורמה ובכלל בטכנולוגיה ובתשתיות
- ואני חושב שה-Engineering Culture שלנו הוא כזה, שאנשים מבינים ש-Melio זה מקום עם תרבות Engineer-ית טובה ועם אנשים טובים
- והדבר הזה זה משהו שהיה תהליך, חלק מהתהליך.
23:10 אז מי מתנדב לספר את כל זה לפרודקט?
(רן) הייתה הנקודה שבה אמרתם “אוקיי, עד כאן Copy-Paste - מעכשיו עושים הנדסה!” זה קרה איפשהו בין ה-Use Case ה-2.5 ל-3, אם אני הבנתי נכון . . . ואוקיי.
אבל עכשיו יש את האתגר השני - איך מסבירים את זה לאנשי הפרודקט וה-Businees, שאומרים “תביא לי את זה אתמול! יש לי עוד לקוח שדופק על הדלת, מה אתה עכשיו הולך לעשות Refactor ולהוציא חלקים משותפים בקוד, לבנות Design System כפול” . . . .
(אורי) Refactor מצריך המון שעות עבודה - זה מעכב Feature-ים חדשים . . . .
(רן) כן - ואמרת צוות חדש, ועכשיו אלירן צריך להתחיל לעבוד על זה ולגייס אנשים, או להעביר אנשים ממקום אחר . . . כאילו, אתה צריך להצדיק את ההשקעה הזאת, נכון?
- (אלירן) כן . . . אז התשובה היא כן - זה קשה.
- זה קשה גם כארגון, זה קשה גם לתקשר את זה בתוך ארגון - הזכרת, לצורך העניין, מנהלי מוצר
- מנהלי מוצר חושבים “אוקיי, מה ה-Feature הבא שאנחנו צריכים לפתח?”
- אני חושב שאחד מהיתרונות שהיו לנו זה העובדה שהאירוע הזה של הפיצול - הוא חילחל גם למנהלי המוצר.
- הם גם מצאו את עצמם מאפיינים Feature ומחכים שהוא יוטמע בשתי מערכות שונות וסימטריות
- או דואגים שהוא יהיה באחת - אבל הוא לא זמין בשנייה . . . .
- אני חושב שאת ה-Reason מאחורי זה נראה לי שהיה קל להסביר.
- מבחינת ה-Effort, או מבחינת איך עושים את זה בתוך חברה - זה אירוע קצת יותר מאתגר.
- אני חושב שזה דורש איזשהו Double-bet מהחברה או מהנהלה, שבאה ואומרת “אוקיי, זה שווה את זה”
- זאת אומרת - שווה לי להקריב כרגע רבעון או שני רבעונים, להוריד את העצימות שבה אני משחרר Feature-ים לאוויר וממנתז (Monetize) את ה-Flow-ים שלי
- בשביל שאני אוכל לרוץ הרבה יותר מהר אחר כך, או לקחת הזדמנויות עסקיות שאני לא אוכל לקחת אם אני לא אעשה את ההשקעה הזו.
24:51 מה היה גודל ה-Engineering?
(אורי) “אני רק שאלה” בשביל ה-Context - מה היה גודל ה-Engineering כשהחלטתם לעשות את ה-Fork? מה היה הגודל ה-Engineering כשהחלטתם לעשות את הפלטפורמה?
- (אלירן) אני חושב שכשעשינו את ה-Fork, ה-Engineering היה קטן יותר, משמעותית - היינו באיזור ה-אם-אני-לא-טועה 70, אולי אפילו פחות . . .
- (גיא) אני יודע להגיד שכשאני הצטרפתי לפני שנה וחצי, אז שבועיים אחר כך הזמנו עוגה עם המספר “100” - זה היה כשגייסנו את ה-Engineer ה-100
- זה כבר היה כשה-Code Base היה Forked . . . .
- (אלירן) נכון . . .
- (גיא) אז קטן מ-100 - אני לא יודע כמה . . .
- (אלירן) זה אפילו קטן מ . . . אני חושב באיזור שקטן מ-60 או-70, משהו כזה.
(אורי) כשעשיתם את ה-Fork?
- (אלירן) כן.
- (גיא) ואחד הדברים שאני, כאילו, אם אני מנסה למקם את זה על ציר הזמן - אז כשאני הגעתי וישבתי עם אילן, כזה, ב-Onboarding שלי
- אז שמעתי על ה-Fork, הזדעזעתי לרגע עד שהבנתי את הרציונל ושזה מה שהביא אותנו לפה . . .
- ואז, באותה נשימה, כבר שמעתי על ה-Effort שקורה כרגע, של בניית הפלטפורמה.
- כלומר, איפשהו באזור ה”לקראת 100”, כבר אנחנו בתוך Effort של פלטפורמה.
- אגב, לאט-לאט, ככל שעבר הזמן, יותר ויותר Resources עברו לכיוון הפלטפורמה
- באיזורים השונים של הפלטפורמה, בשכבות השונות, באיזורים השונים של המוצר . . .
(רן) בוא, בוא רגע - נדבר במספרים: זאת אומרת, אמרת שאלירן הוביל צוות אחד; היה מעבר לזה - עוד צוותים? קבוצות? כמה אנשים?
- (אלירן) אז בעצם, הרבה יותר קל להתחיל כשאתה Lean ויש לך מעט מהנדסים על ה-Effort.
- לצידי היה שם Staff Engineer בשם עוזי, שהוא איש מקצוע מדהים
- אז בעצם, יכולנו לרוץ מהר מאוד - כשהיינו קטנים.
- ברגע שהדבר הזה עבר Scale-up גדול, ברגע שהחברה עשתה על זה איזשהו Double-bet, אז יש גם איזשהו עניין . . . .
- כי אם אתה מחזיק צוותי פיתוח מקבילים, שעובדים על מוצר שהוא Forked - מה קורה ביום שאחרי שהדבר הזה מתכנס לכדי מוצר אחד?
(רן) מה הבעיה? עושים Merge . . . הכי קל בעולם . . .
- (אלירן) אז עושים Merge גם לצוותים ולקבוצות, כן . . .
- אני חושב שה-Transition הזה, של פוקוס של החברה מלהמשיך ולהשקיע במוצרים המקוריים, שהיו פחות מותאמים ל-Scale-up, ללהתחיל להשקיע במוצר שהוא יותר Scalable - אני חושב שה-Transition הזה הוא מה שגרם לאירוע הזה בעצם להצליח, מבחינת סדרי כוח אדם.
- (גיא) היום, אגב, המושג “פלטפורמה” ב-Melio הוא כבר כל כך שורשי
- אגב, הזכרת את ה-Product Managers - יש גם חלק גדול מה-Product Managers שהם מאוד טכניים
- לפעמים יותר מדי טכניים וקשה לערבב אותם . . .
- היום, כמעט בכל איזור, כל דבר שמפתחים ב-Melio - ה-PM כבר שואל “רגע, אבל אתה עושה את זה Platform-י, נכון?
- כאילו, זה כבר נהיה משהו . . . שהוא מגיע כבר משם
- ולמעשה, כמעט כל צוותי ה-User-Facing Product וה- Engineering teams - כלומר, צוותים שמפתחים מוצרים עבור ה-User-ים - כמעט כולם הם כבר חלק מהפלטפורמה
- ובעצם עובדים תחת ה-Playbook שלנו - של איך מפתחים פלטפורמה.
28:02 אז מה לא Platform-י?
(אורי) מה נשאר לא Platform-י?
- (גיא) יש לנו . . . בעולם שלנו יש צוותי Infra - אבל גם הם, ב-Nature שלהם, הם . . .
- אי אפשר להגיד, לא יודע - אולי גם הם אומרים שהם מפתחים פלטפורמה, לא יודע.
(אורי) להיפך - זה ה-Infra של הפלטפורמה, לא?
- (גיא) נכון, בעולם של . . . כאילו, ה-Infra שלנו זה בעיקר שלוש קבוצות עיקריות -
- זה ה-Data infra; זה ה-Payments; וזה Risk - אוקיי?
- שזה שני עולמות מאוד משמעותיים בעשייה של Melio.
- אז By Definition הם Infra אחד, שמשרת את כל המוצרים - אבל אין שם בעצם . . .
- שם לא צריך לייצר את ה-Flexibility הזה שאנחנו מדברים, מבחינת השותפים
- כי זה פשוט Core אחד שמשרת את כולם.
(אורי) לא, אבל כשאתה אומר ש-Product Manager רוצה “משהו Platform-י”, זאת אומרת שיש דברים שהוא רוצה . . . או שיש דברים שהם “לא Platform-יים” . . .
- (גיא) אז ה”לא-Platform-י” היום זה בעיקר ה-Legacy
- אנחנו היום בעצם, אחד השרידים האחרונים - ה-”Melio.com”, שאנחנו קוראים לו הרבה פעמים פנימית “Purple”, כי הוא בצבע סגול, לעומת המוצרים האחרים - Intuit, שהיה ירוק, וכו’
- הוא היום עובר תהליך מיגרציה (Migration), כלומר - ממש בקרוב, גם Melio.com “הסגול” יעבוד על אותה פלטפורמה, ביחד עם כל השותפים האחרים שלנו.
- ולכן יש עדיין איזה Pockets כאלה, שעוד לא עברו פלטפורמיזציה (Platformization), וכש. . .
- (אלירן) יש גם אזורים שכנראה לא צריכים להיות Platform-יים, שזה נראה לי מה שאתה [אורי] מכוון אליו
- שזה בקצה-קצה, מול הפרטנר - אתה רוצה להשאיר איזשהו Headspace מסוים של גמישות
- שהיא ספציפית נורא, לשותף כזה או לשותף אחר.
- אם אתה מוטמע בתוך מערכת, ויש להם את הדרך שלהם להעביר את המידע או לעשות את ה-SSO, או דברים מהסוג הזה
- זה דברים שבאמת יישארו כנראה Cupelled לפרטנר, ולא משהו שהוא רוחבי.
(אורי) אבל בדרך כלל בחברות, לפעמים יש גוף Professional Services כאלה, שהוא מנהל את זה מחוץ למוצר . . .
- (אלירן) נכון . . .
- אז (א) אנחנו נורא ניסינו להימנע מ-Professional Services . . . .
- אתה לא באמת יכול, 100%, להימנע מ-Professional Services - אבל אתה כן יכול לצמצם את זה.
- זאת אומרת, אם ה-Professional Services שלך הם רק בקצה-קצה - לתפור שנייה רגע את החוויה - אז יש לך את המקום לזה . . .
- אם אתה יכול להישען על מספיק מוצר, שהוא נגיש וגמיש - אתה תוכל לבנות את החוויה, עבור אותו פרטנר, בקלות יתרה.
- אז כאילו, המטרה בסוף הייתה להקטין כמה שיותר את הסיכוי שבו נעשה Professional Services per partner.
- זה התכל’ס . . . .
- (גיא) ובכלל אגב - זה ב-State of Mind וזה כבר בDNA של החברה - להבין שמה שהיא מפתחת זה בעצם פלטפורמה - שגם כשמגיעות דרישות, נקרא להן “ספציפיות”, משותף (Partner) . . .
- צריך להבין - זה שותפים שהם מאוד גדולים ומשמעותיים - זה מסוג השותפים שאתה רוצה להשקיע בהם ב-Professional Services . . .
- אז כשצריך ומגיעה איזושהי דרישה - המחשבה הראשונה זה “אוקיי, זה הגיע מ-Capital One . איך יראו הווריאציות (Variations) שאולי יגיעו בעתיד מזה וזה?” . . .
- ואם אנחנו יכולים לעשות עכשיו משהו עבורם, שגם אחרים ייהנו ממנו, מאותו Learning או מאותה הפונקציונליות.
(רן) “ההכנה למזגן” . . .
- (גיא) כן.
31:24 קשה לא רק בלחם
(רן) בואו נחזור רגע לנקודה שבה אתם מחליטים לעשות את ה-Merge, זאת אומרת לפקטר (Refactor) ולייצר איזשהו משהו שהוא יותר Platform-י.
מה שרציתי לשאול זה איזה קשיים צפיתם שיהיו, ואולי השאלה יותר מעניינת - איזה קשיים לא צפיתם, וגיליתם לאורך הדרך, בעבודה?
- (אלירן) אני אגיד קודם, מהצד “ה-Engineer-י”
- לפתח מוצר אחד שהוא קו לינארי - כולם יודעים, בדרך כזאת או אחרת.
- פה, אנחנו מדברים על מוצר אחד, שיש לו עומק של תצורות שונות.
- זאת אומרת - הוא אותו מוצר: חוויית התשלום היא בערך אותה חוויית התשלום . . .
- (רן) אתה עושה בערך BFS . . .
- (אלירן) בדיוק, בדיוק . . .
- אז בעצם, אז אתה באמת . . . אתה הולך באמת לרוחב גם, ולא רק לעומק.
- אז בעצם, הקושי העיקרי שצפינו הוא באמת ה-Partner Variation - פר חתיכת-מוצר, Per-Flow . . .
- איך זה נראה ואיך זה מתנהג.
- אם הפרטנר ההוא רוצה פה איזשהו כפתור אחר, או איזה Banner מסוים - איך זה משפיע עכשיו על כל אחד מהם?
- ואיך אתה בונה משהו, שיכיל את כל המורכבות הפרטנרית הזאת - ועדיין will contain it.
- אז זה דבר שצפינו . . .
- אני חושב שהרבה מהדברים שלא צפינו זה ה-Impact, אני חושב - גם הארגוני.
- כי כמו שאתה אומר - זה דורש איזשהו Education.
- כשבא מנהל מוצר לפתח איזשהו Feature או לאפיין איזשהו Feature, אתה צריך להגיד לו “כן - אבל תחשוב על איך זה נראה פה ופה ופה ושם” . . . .
- זאת אומרת, אתה לא יכול לחשוב רק, כמו שאתה רגיל לחשוב, על Melio.com [הסגול!].
- ובצד האנושי - גם העלה קשיים . . .
- (גיא) אני חושב שעוד משהו שאולי הבנו שיקרה, וזה נכון גם היום - שלפתח מוצר, כשאתה מפתח Feature, עם וריאציה (Variation) אחת, זה מהיר יותר . . . .
- וזה עדיין ככה . . . כאילו, עדיין, אם עכשיו יש יכולת חדשה שאתה צריך לעשות - אם הייתי צריך לעשות רק לשותף אחד, לצורך העניין, זה עדיין היה לוקח פחות זמן מאשר היום, כשאתה צריך להביא בחשבון את כל הפרמוטציות (Permutations) או את כל הדברים שצריך להתייחס אליהם, או ה-Framework שאתה צריך לעבוד בתוכו כדי לעשות את זה Platform-י.
- אז יש איזשהו מחיר, נקרא לזה, שאנחנו משלמים אותו גם בשוטף.
- יש כמובן דברים, שככל שאנחנו מתקדמים ודברים עוברים יותר איטרציות (Iterations), אז גם אנחנו משקיעים יותר ב-Developer Experience - ודברים נעשים כן יותר פשוטים, יותר קלים
- אבל זה חלק מהמחירים שאתה משלם - גם בתהליך וגם אחר כך.
- אני חושב שגם עוד דבר שקשור לאנשים - אני חושב שזה . . . אתה קראת לזה, שזה אתגר אחר או משהו בסגנון הזה - זה אומר גם משהו על ה-Talent שאתה צריך בארגון, כדי לפתח את הדבר הזה.
- זה . . . נקרא לזה “Talent Density” [הי Reed Hastings], שצריך להשתנות, כדי להמשיך לתמוך ולפתח מוצר עם עומק ומורכבות כזאת.
- זה בעצם . . .
(רן) כלומר ניסיון, בגרות . . . כאילו, מה הפרמטרים?
- (אלירן) כן, אני חושב שיש דברים שמגיעים עם ניסיון, ויש גם, כאילו - מהי “תקרת הזכוכית” של כל אינדיבידואל (Individual) ש . . . כן.
34:53 אז Platform-י או לא Platform-י?
(אורי) יש לי שאלה על הדבר הזה שנקרא Platform-י / לא Platform-י - לפתח משהו עם העומקים האלה, אז בואו ננסה לחשוב איך זה גנרי, כי זה לוקח זמן, ולפעמים מאוד מאוד מסבך את הפיתוח . . .
ואתם יודעים - לא הרבה מוצרים או Feature-ים באמת מצליחים, אוקיי? אז . . . אפילו אחוז נמוך מהם מצליח ומגיע לשימוש.
עכשיו, אם על כל Feature שאנחנו רוצים לעשות, אנחנו נחשוב “איך הוא Platform-י?”, ונשקיע את כל המשאבים כדי שזה “באמת” יהיה Platform-י, ובסוף לא ישתמשו בו - אנחנו בזבזנו המון.
אז השאלה שלי היא האם לפעמים אתם אומרים “שמע, אל תחשוב על זה Platform-י - אנחנו נוציא את זה לפרטנר אחד, ונראה אם יהיה שימוש” . . . ?
- (גיא) אז יש מקומות, שיש לנו High Conviction לגבי משהו שאנחנו הולכים לפתח
- זה אולי הגיע כדרישה מהרבה שותפים, או אולי ראינו תוצאות של משהו,
- ויש לנו High Conviction לגביו
- שם אנחנו כנראה נעשה את זה “Platform-י מ- Day One”, נקרא לזה.
- יש שתי סיטואציות אחרות -
- אחת זה AB test, כאילו, אנחנו עושים הרבה Test-ים של Feature-ים עם יכולות
- ושם אנחנו הרבה פעמים נעשה את זה, נקרא לזה רגע “לא Platform-י” בשביל הפשטות.
- ואחרי זה, based on the results, אנחנו נחליט מה אנחנו . . .
- (אורי) . . . האם אנחנו משיכים זה הלאה . . .
- (גיא) כן, אז זו סיטואציה אחת.
- וסיטואציה שנייה זה שאנחנו עושים משהו ואומרים “אוקיי, בואו נעשה אותו ככה - ואחר כך ניקח את הLearnings, ונהפוך אותו ל-Platform-י”.
- (אורי) כשלפעמים המחיר הוא “אנחנו נקודד את זה מחדש - אבל אנחנו נקודד מחדש רק את מה שעבד, ולא את ה-80% שלא עבד” . . .
- (אלירן) כן, אז אני רוצה להגיד משהו שם
- א' - יש לנו . . הייתה לנו איזושהי פריבילגיה מסוימת, כי בעצם בנינו מחדש מוצר קיים.
- הרבה מה-Learnings מהמוצר הקיים - ה-Confidence שלנו בהם הוא מאוד גבוה
- זה Feature-ים שכבר רצים ועובדים, ויש לך Data עליהם - ואתה יודע שאותם אתה צריך לבנות בהכרח, בצורה שהיא Long Lasting וזה עובד יופי.
- אז זו פריבילגיה אחת.
- הדבר השני הוא יותר, שנייה, איזשהו עניין של State of Mind
- כי בבנייה, בצורה מסוימת, שזה באמת כמו שתיארתי, אתה יודע - איזה מודל כזה של Black Boxes כאלה ואחרים, שמתחברים להם לכדי מוצר
- כל עוד Shit הוא “Contained Shit” - אתה בסדר
- זאת אומרת, אתה יכול, תחת איזה Container ספציפי של Feature מסוים, להגיד “אוקיי, אני אעשה פה קיצור דרך או שניים, כי זה כרגע משהו שאני רוצה רק לבדוק אם הוא עובד”
- “העולם שמסביב” לא צריך להתיישר אחר כך כשאתה משנה אותו
- כל עוד הממשקים בין Feature כזה או אחר הם ממשקים מוגדרים היטב, תעשה את זה, תכתוב את זה שש פעמים - זה לא באמת משנה.
- אז בעצם, השילוב בין שני הדברים האלה מאפשר לנו, לפחות בנקודת זמן הנוכחית, עדיין להמשיך לרוץ ב-Confidence גבוה לגבי ההשקעה שלנו, בתוך הכתיבה מחדש של הדברים.
- (גיא) אני חושב, אגב, עוד משהו שאני חושב שהוא מעניין - ככל שאנחנו מתקדמים, אנחנו מרגישים . . . יש איזושהי “פאטה מורגנה”
- שאתה כבר מבין יותר, יודע יותר - ואי אפשר להפתיע אותך.
- אז כאילו, יש דברים שהם ריפיטטיביים (Repetitive)
- ואז אתה פוגש שותף, שפתאום מזכיר לך שלא - החיים עוד . . . אתה רק בתחילת הדרך, עוד יש לך הרבה מה ללמוד ויש עוד הרבה דברים, שהם חלק מפלטפורמה, שאתה צריך לחשוב עליהם.
- לדוגמה, Deployments - כאילו, אנחנו דיברנו על Repositories ועל פונקציונליות ו-User Interface ו-Backend וזה.
- אבל אז אנחנו מגיעים לשותף מאוד גדול, שאומר לנו בפגישה “איך נראה ה - Deployment Frequency שלכם?” . . .
- ואנחנו בגאווה אומרים לו “אנחנו עושים היום . . .” - פותחים לו את הגרפים - “ . . . סדר גודל של 20 Deployments ביום, בממוצע”.
- הוא אומר “מגניב, אנחנו עושים פעם ברבעון . . . .”.
- ועכשיו, אנחנו אמנם פלטפורמה, וכל ה-Channel-ים רצים על אותו זה . . . אבל פתאום אתה מגלה, שאתה צריך, אולי, לשלוט ב-Deployment Frequency . . .
- עכשיו, איזה רמת מורכבות זה מייצר לנו, כארגון? אז גם הדבר הזה - צריך לתת לו מענה.
- וזה מסוג הדברים, שאתה לפעמים חושב שאתה כבר מבין מה זה “לעשות פלטפורמה” - ואז אתה נתקל רגע באתגר הבא.
(רן) זה למעשה מכריח אותך לעבוד ב-Cycle-ים הרבה יותר ארוכים, לתכנן את ה . . .
- (אלירן) כן, יש חברות שעושות Deploy ל-Production רק “פעם בירח מלא”, כשזה נופל רק על יום שני, בסדר גודל . . . .
- (אורי) לא על יום טוב . . .
- (אלירן) כן, לא על יום טוב . . .
- (גיא) אגב - סיפור אמיתי מאותה זה . . . כשהם אמרו לנו “פעם ב- . . . ויש תאריכים . . . ”
- למעט, אני לא זוכר, יש את ה-Hot Fix הזה - אבל יש תאריכים שבהם לא עושים Deployment -
- אחד זה השבוע האחרון של השנה
- והשני - הם זרקו איזה תאריך ביוני . . .
- ואנחנו מסתכלים אחד על השני - בסדר, סוף שנה אנחנו כולנו יכולים להבין
- גם בעולם התשלומים אגב, ספציפית, זה תאריך שהוא Heavy על המערכת, כי זה השלב שבו כולם ממהרים לסגור וזה . . .
- ואנחנו אומרים “תגידו, התאריך הזה, השבוע הזה ביוני - מה . . . מאיפה זה מגיע?”
- אז הם אומרים “זה ה-Annual Customer Conference שלנו” . . .
- אז בעצם, יש עוד איזה משהו שהוא . . .
- (אלירן) “יש חופשה, זה בדיוק נופל לי על החופשה” . . .
- (גיא) הם לא רוצים להעלות בעיות, לפני שהם פוגשים את הלקוחות - משהו בסגנון הזה.
(רן) כן . . . יכול להיות שיש להם ניסיון בעניין . . .
40:29 מגייסים?
טוב, תודה רבה! אז חבר'ה - היה מרתק, שוב תודה שבאתם.
אתם - תזכירו, נמצאים בתל אביב כזה?
- (גיא) כן, אנחנו יושבים במגדלי הארבעה, הידועים גם בשמם העממי “חג'ג'”.
- כן, משרדים . . .
(רן) מגייסים? מחפשים?
- (גיא) מגייסים, מחפשים - כן:
- ב-Engineering - כמעט בכל תפקיד ובכל Stack טכנולוגי
- וגם ב-R&D בכלל, Product, אנליסטים וכו’.
(רן) יופי - אז תודה רבה! להתראות.
האזנה נעימה ותודה רבה לעופר פורר על התמלול!
אין תגובות:
הוסף רשומת תגובה