Dev of the Day – כשמפתחים ונציגי תמיכה עובדים ביחד

Startup For Startup

                                      

ליאור:            היי ערן.

ערן זינמן:       היי ליאור.

ליאור:            היי כולם. הגעתם ל-Start Up for Start up, הפודקאסט שבו אנחנו משתפים מהניסיון, מהתובנות והידע שיש לנו כאן ב- monday.com וגם מחברות אחרות, והוא מיועד לכל מי שסטארט-אפ מדבר אליו, לא משנה באיזה כיסא הוא יושב ברגעים אלו. [מוזיקה]. אז היום אנחנו נדבר על קונספט שאנחנו בחברה קוראים לו dev of the day. ובצורה מסורתית ומבאסת קוראים לו “המפתח התורן”. והמטרה של הפרק הזה היא בעצם להסביר מה מתכלל התפקיד הזה בתוך החברה אצלנו, איך הגענו לתובנה שזו דרך שאפשר לפתור בה דברים, ואיך עושים לזה scale. עכשיו, זה שאלות שכרגע נשארות מאוד עמומות, אבל תישארו איתי, מבטיחה שהולך להיות מעניין. ולטובת העניין הצטרף אלינו היום גיא אסינובסקי. שהוא מפתח בחברה כבר שנה וחצי. ויש לו גם תפקיד ייחודי סביב הנושא הזה של ה-dev of the day, נכון גיא?

גיא:               כן. היי ליאור, היי ערן.

ערן זינמן:       היי גיא.

ליאור:            היי גיא. [צוחקת]

גיא:               אז באמת בנוסף לתפקידי כמפתח באחד הצוותים ב-RND יש לי אחריות שהיא כוללת ברגיל שלה quality וה-dev of the day. שעוד שנייה באמת נסביר מה זה. זה בכלל איזשהו מהלך שאנחנו אוהבים לעשות ב-RND, לתת איזשהם תפקידים רוחביים לאנשים שמשפיעים על כלל ה-RND ולפעמים אפילו על כלל החברה.

ליאור:            אתה לא יושב כאן כי אתה ה-dev of the day התמידי?

גיא:               לא. ספציפית היום האמת אני כן dev of the day, אבל אני לא התמידי.

ליאור:            איך זה יכול להיות שאתה יושב בחדר סגור עם פלאפון סגור ואתה dev of the day, איך זה מתכנס?

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

ליאור:            איזה אחריות. אז באמת שנייה כדי שנוכל להבין מה התפקיד של dev of the day בmonday-, בואו נבין רגע מה הייתה הבעיה שזה בא לפתור. אז רן, את הקונטקסט הזה תיתן לנו אתה אולי.

ערן זינמן:       בכיף. זה משהו שנתקלנו בו בתחילת החברה. אני חושב שכל חברת תוכנה עוברת דרך התהליך הזה. של איך מחברים בין ה-customer success ל-RND. יש המון המון פידבקים שמגיעים מלקוחות, כל הזמן. במיוחד תוכנה שיש לה שימוש יומיומי. על באגים, אפילו לא באגים, אפילו אנשים שעשו איזו שהיא  פעולה בטעות ורוצים לשנות משהו, לשחזר איזשהו משהו. איזשהו use-case ספציפי שהם לא מבינים כאילו למה זה קרה להם ככה ולא אחרת. וה-CS לא תמיד יכול לענות. לפעמים הוא צריך או מפתח שיבדוק את הבאג, או מפתח שיעשה משהו ב-database בשביל לעזור ללקוח. ומה שהיה לנו בעבר שהיה מאוד מתסכל זה שאנשי ה-CS מצד אחד שמנו להם יעד של לענות מאוד מאוד מהר לטיקטים. ואז הם הגיעו בריצה ל-RND, וה-RND “רגע, מה אתם רוצים ממני? אני באמצע ישיבה, מה אתם רוצים? אנחנו באמצע פיצ’ר”, contact-switching תמידי. שום פריוריטיזציה בין עיקר לטפל. אולי יש עכשיו באג שאף אחד לא מצליח להיכנס למערכת, אולי זה רק באג שקורה ליוזר אחד מתוך אלף. זה יצר המון המון בעיות. גם עוד בעיה שקרתה לנו זה שכל פעם באו לאותו בן אדם. כאילו, היה איזה שהוא go-to person כאילו ב-RND והוא פשוט לא הצליח לעבוד. וכל השאר, פשוט ככה קרה, שפחות באו אליהם. ואמרנו בסדר, אי אפשר להמשיך ככה, זה לא scalable.

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

ערן זינמן:       לגמרי, זה לגמרי, כי מצד אחד אנחנו-

ליאור:            כאילו, זה setting for failure מה שתיארת כרגע, זה-

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

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

ערן זינמן:       לגמרי.

ליאור:            ואולי אם גם נגיד אותה מלא פעמים אז משהו ישתנה מהותית.

ערן זינמן:       כן. אבל לא היה את ה-interface הזה. זאת אומרת, לא היה את המתודולוגיה ואת התהליכים בשביל לתמוך בדבר הזה, זה היה מאוד מאוד רנדומלי.

ליאור:            ואז נכנס, נכנסה הפונקציה של ה-dev of the day. אז גיא, תספר לנו רגע איך זה נראה היום.

גיא:               אז בעצם היום זה תורנות, של 24 שעות, שעוברת בין כל המפתחים. היום זה כבר לא מפתח אחד [צוחק]. יש בערך 20, שעושים את התורנות הזאת. וזה תפקיד שיש לו כמה כובעים. כובע אחד זה באמת הקטע הקלאסי הזה של מפתח תורן, זה להיות זמין, עם הלפטופ, תקלות, הטלפון מצלצל, כל-מיני דברים כאלה. אנחנו פחות נתמקד בזה. יותר נדבר על מה קורה במהלך היום. וגם איך כולם יודעים עם מי לדבר. אז נגיד ה-dev of the day עכשיו הוא נמצא על דשבורד, הדשבורד העיקרי שלנו. כל יום, יש שם את השם. הcustomer success- יודעים עם מי לדבר, ולמי לפנות במה ויש בעיות.

ליאור:            כל החברה יודעת.

גיא:               כל החברה יודעת, ובעיקר כמובן ה-CS הם אלה שככה בממשק מול ה-dev of the day.

ליאור:            כן, אבל תיקח את זה אפילו לרמה היותר בסיסית שאם עכשיו מישהו לא יודע מי ה-dev of the day אז הוא יכול לשאול וכל אחד אחר ידע לענות על זה, אז לא צריך לחפש את האדם שיודע מי ה-dev of the day. לזה אני מתכוונת.

גיא:               נכון. אבל באמת ככל שגם באמת החברה גדלה, ה-scale בתוך החברה גדל, אז ה-dev of the day הפך להיות גם ה-point of contact ל-sales ול-partners, לא רק ל-CS, ולשאלות מכלל המחלקות בעצם בחברה. וכולם בקלות יכולים לראות מי זה ולפנות אליו דרך הבורד של ה-dev of the day. שזה גם איזשהו שינוי שעשינו, לא לבוא ולהציק בכתף עכשיו אתה יכול לעזור לי, אתה יכול לענות לי. אלא אם כמובן זה דחוף, אבל זה כבר גם, נשים את זה לרגע בצד. דברים שוטפים, שאלות שוטפות, שיכולות להיות להן מענה תוך- במהלך היום, שמים, פותחים tickets בעצם, pulse בבורד של ה-dev of the day. ה-dev of the day יודע שהוא כל כמה שעות, כל שעה, לא משנה, דוגם את הבורד ומטפל בדברים שיש ונותן את התשובות.

ליאור:            אוקיי. אז בעצם אותו ה-dev of the day עכשיו אחראי לתת מענה ל-CS על כל הבעיות שעולות באופן פרטני? זה מה שאתה בעצם אומר?

גיא:               אז בגדול-

ליאור:            נשמע לא יעיל.

גיא:               נכון, נכון. אז-

ליאור:            גם לא כיף. [צוחקת].

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

ליאור:            מה זה אקסטרים, זה לאמלל ממש את ה-dev of the day?

גיא:               לפעמים, אבל אנחנו משתדלים שלא [צוחק].

ליאור:            מה זה אומר אקסטרים?

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

ליאור:            תיאום בין המפתחים אתה אומר.

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

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

ליאור:            אז בוא נבין שנייה מתוך דוגמה איך זה נראה בפועל, הלכה למעשה.

גיא:               אז דוגמה ממש ממש טובה למשהו שפתרנו זה, הייתה בעיה שהייתה חוזרת על עצמה, אנשים היו מוחקים בטעות בורד, פולס, column או משהו כזה, ולא הייתה דרך במערכת לשחזר את זה והדרך היחידה בעצם של היוזר זה לפנות ל-customer success, להגיד שחזרו יל את הבורד, יש לי עוד שנייה מצגת ונעלם לי כל המידע ואני מזיע פה ונורא לחוץ. וה-CS מהצד שלהם יודעים שאין להם שום דרך לעזור בעצמם. הם יודעים שהם צריכים לפתוח טיקט בפולס ב-dev of the day בורד לעשות את זה. המפתח יודע שהוא צריך ידענית ב-database לעשות את הפעולה הזאת כי אין שום דרך לעשות את זה. ושוב, כשלעצמו זאת פעולה שלוקחת כמה דקות. אבל א’ התהליך הזה end to end, ליוזר הוא הרבה יותר ארוך מאשר אם הוא היה יכול לעשות את זה בעצמו לדוגמה. ודבר שני, כשהדברים האלה מצטברים ו-

ליאור:            כן, זה סיפור על חוסר יעילות מכל ה, כאילו-

גיא:               ממש, מכל הכיוונים.

ליאור:            lose-lose-lose מה שנקרא.

גיא:               לגמרי. ומצד שני, כשהבן אדם עושה את זה פעם אחת אחלה אבל כשהבן אדם צריך לעשות את זה שלוש פעמים כפול 15 מפתחים, זה כבר הופך להיות אישיו. וכמובן זה רק דוגמה אחת מתוך כל-מיני דברים אופרטיביים כאלה שקורים. ובעצם מה שעשינו בנקודה הזאת זה קודם-כל בעצם לזהות את זה. וזה מתקשר לנושא של מה שדיברנו של לעשות איזשהו רטרו כל חודשיים, כל שלושה חודשים, על הסיפור הזה. לנסות למצוא תבניות ודברים שחוזרים על עצמם. ראינו שהנושא הזה של שחזורים הוא בעייתי ביותר ומשמעותי, ושיש לו פתרון ברור ב-product שאפשר לפתור את זה. בדמות recycle bin שזו פונקציה שכולנו מכירים מכל מקום. ובעצם להתייחס לזה כפיצ’ר שצריך להיכנס ל-roadmap, לאינטראקציות הקרובות. עם priority יחסית גבוה. כי איך שזה פוגע בתפוקה של המפתחים זה מאוד ניכר לעין. ושל ה-CS, וכמובן בזמן תגובה ובכל מה שדיברנו.  והדבר הזה-

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

גיא:               נכון. ובדרך-כלל יש יחס מאוד ישר בין כל שלושת הגורמים האלה.

ליאור:            ואני אומרת גם, זה נראה לי מקרה… שוב, לא מתיימרת, אבל נשמע לי שזה מקרה שקל להכריע שחשוב להתייחס אליו בצורה שהיא יותר scalable, נכון?

גיא:               נכון, נכון. זו באמת דוגמה ממש ממש קלאסית לסיפור הזה. ואז זה לא נפתר איזה בן חורג של “טוב, צריך לעשות איזה משהו זריז”. היה לזה את ה-design, היה לזה product, היה לזה פיתוח כמו שצריך, זה פיצ’ר שנכנס ל-pipeline כמו כל הפיץ’ כמו שאנחנו מפתחים. לקח את הכמה שבועות לפתח את זה. זה נכנס. כמובן, knowledge base, הכשרה של ה-CS, איך מפעילים את הפיצ’ר, איך מסבירים ללקוחות איך להפעיל את הפיצ’ר. וזהו, ומאז כבר שנה וחצי-

ליאור:            שחרר צוואר-בקבוק משמעותי.

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

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

גיא:               נכון.

ליאור:            אני מניחה שהפעולה הזאת של לחזור ל-database ולשחזר היא אחת הפשוטות.

גיא:               נכון.

ליאור:            אבל חייבים פה את ה-meta data של ה-

גיא:               של ה-להבין את ההשפעה.

ליאור:            של החזרתיות, כדי להבין שזה כזה גדול וכזה משפיע.

גיא:               נכון.

ערן זינמן:       וזה בדיוק האימפקט שאני חושב שזה מייצר. זאת אומרת, השינוי שגיא תיאר הוא שינוי אדיר ב-product. אני בכלל תמיד בתפיסה שלי על כל בן אדם שפותח טיקט יש עשרה או 15 שלא פותחים טיקט, ופשוט מתייאשים. משנים את דעתם על המוצר, חושבים שהוא גרוע. כמה effort צריך בשביל לבוא ולפתוח טיקט. הווליומים של הדבר הזה הם לדעתי עשירית ממה שזה משפיע ביומיום. וזאת דוגמה ל-product לא טוב שהיה לנו. ואם הייתם שואלים אותי, ב-roadmap שלנו אף פעם לא היה “בוא נעשה recycle bin”. זה לא היה מעניין. זה לא פיצ’ר שחשבנו שיש לו אימפקט, זה לא פיצ’ר שחשבנו שיקדם את המוצר. אבל אחרי שאתה מבין שאנשים מתלוננים על זה שזה פוגע להם בחוויה, שזה פוגע להם בממשק משתמש בעצם בתוך התוכנה, אתה מבין כמה זה אימפקט. זה לא פיצ’ר שתמיד נולד מתוך המקום הזה של “הנה, אנחנו מקדמים את החברה צעד קדימה”, אלא משהו שנולד מ-pain. ואם לא היה לנו את הפונקציה הזאתי ואת הראייה הרחבה הזאת של הנה זה מציק ליוזרים ברמה יומיומית, לא היינו מגלים את זה. ואני חושב שזה שהפיתוח עשה את זה זה תרם לזה. אני חושב שיש עוד רמה, מעבר לזה, וזה נהיה עוד יותר מסוכן, עוד לפני שאנחנו עובדים עליו, שלפעמים ל-CS, ל-customer success עצמו יש כלים לפתור את הבעיות. באים לקוחות ומתלוננים. יש ל-customer success איזשהו admin panel או משהו כזה, והם נכנסים ל-admin panel ופותרים את הבעיה. הם בעצמם. וזה silent killer. זה משהו שמצאנו לו איזה work around, הפיתוח לא מרגיש אותו, אבל הוא הורג את המשתמשים. צריך לזכור, כל אחד שפותח טיקט, עשרה לא פותחים. זה הורג עשרה אחרים. אז ה-CS יודעים שגם דברים שהם רפטטיביים שמצליחים לפתור אותם נכנסים בסוף ל-dev of the day, כי חשוב שה-RND יהיה מודע לזה שהמון לקוחות בעצם נתקלים בסיטואציה הזאתי ובאתגר הזה, כדי שגיא והצוות יוכלו בעצם להסתכל על זה בצורה רוחבית הוליסטית ולראות איך אפשר לתרגם את זה מחר לאיזשהו פיצ’ר ושינוי בעצם במוצר.

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

ליאור:            תן דוגמה למקרה שבו אתה באמת חושב שעדיף,

גיא:               אז אני יכול להגיד שעשינו איזשהו פיצ’ר שהוא חלק מאיזשהו compliance שהיינו צריכים, לתת ללקוח את האפשרות שכשהוא סוגר את החשבון להוריד את כל המידע שלו. זאת אומרת, download של כל הבורדים וכל האפדייטים לתוך אקסלים ש, זו מין מחויבות רגולטורית שהייתה לנו לתת ללקוח. ולפי קצב הבקשות שכרגע ראינו את הדבר הזה קורה, החלטנו שזה כרגע מספיק טוב שזה יהיה אפילו ברמה של איזשהו script שנכתב ל-dev of the day אבל הוא, הושקעה בו מחשבה כדי לפתוח את זה, כי לפני זה לא ידענו איך לעשות את זה בכלל וזה לקח מלא מלא זמן. ואמרנו, לפי הקצב של הבקשות האלה אנחנו יכולים להעביר את זה שזה יהיה בצד של ה-CS, ואולי מתישהו נעשה את זה כפיצ’ר אמיתי שיהיה במערכת עצמה.

ליאור:            כלומר היום כשמישהו רוצה להוריד את כל המידע, להעביר את כל המידע של כל ה-account שלו בעצם, אתה מדבר ברמת ב-account, נכון?

גיא:               באמת ה-account, כן.

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

גיא:               בדיוק. כן. כי, זאת אומרת, ההבדל הוא שלפני זה הוא פתח את הטיקט הזה וזה יכל לקחת שבוע או שבוע וחצי, והיום הוא פותח את הטיקט הזה וזה יקרה כנראה באותו היום. וזה בדיוק ההבדל. ופה המורכבות של לעשות את זה במוצר עצמו, יש פה מורכבות הרבה יותר גדולה, והחלטנו שלא להיכנס אליה. וזה העניין של המורכבות של לטפל בבעיה מול הכמה שזה, ה-value שזה נותן. ואני ושחר כל הזמן on it, ושחר, זה לא חייב להגיע ל-dev of the day כדי ששחר יתריע לי שיש דברים רפטטיביים שחוזרים ב-CS והוא אומר שמע, בוא נמצא לזה איזשהו פתרון במוצר עצמו. ו-

ליאור:            מי מקבל את ההחלטה הזאת, למשל בדוגמה שנתת על ה-export?

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

ליאור:            המעורבים בדבר, כן.

גיא:               כן. שהסכימו. וככה זה קרה.

ליאור:            מתוך data. שוב, מתוך זה שהגעת למסקנה ש-

גיא:               מתוך שאני יודע בדיוק כמה בקשות כאלה היו מאז שאנחנו תחת הרגולציה הזאת. ושזה לא דרש כרגע את ההשקעה הזאת לעשות את זה במוצר עצמו. [מוזיקה]

ערן זינמן:       אנחנו תמיד מסתכלים על שלושה פרמטרים. על volume – כמה בקשות כאלה יש. מה ה-pain שזה גורם ליוזרים, ומה ה-effort שייקח לנו בעצם לפתח את הפתרון. ולפעמים אנחנו מתפשרים על אחד הפרמטרים. זאת אומרת אם אנחנו רואים שה-effort הוא מאוד גבוה אז אולי אנחנו נמצא איזשהו walkaround שיפתור את ה-effort. ואם אנחנו יודעים שה-volume גבוה אבל ה-pain הוא נמוך יכול להיות שאנחנו נפתור את זה, כי כל-כך הרבה אנשים נתקלים בזה למרות שזה מפריע להם קצת, שהאפקט המצטבר של זה הוא מאוד מאוד משמעותי. מסתכלים על כל הפרמטרים האלה. Having said that, יש לפעמים מקרי חירום. וזה גם מאוד מאוד מעניין. כי דיברנו פה המון המון על השגרה, אבל יש לפעמים מקרי חירום. שרת שנופל, account שאי אפשר לגשת אליו, דברים שהם מבחינתנו הם show stopper.

ליאור:            שזה משהו שגם dev of the day מטפל בו?

גיא:               זה גם dev of the day מטפל פה, אבל פה באמת יש יותר עניין של גם הרבה ככה הכשרה שאנחנו עושים ל-CS של להבין מה זה show stopper. כי זה קל להגיד המערכת למטה, זה show stopper ברור. אבל אולי אני לא יכול לעשות sign up רק מאירופה, זה כן show stopper, אבל יש דברים שצריך לתת להם קצת יותר מחשבה, של האם עכשיו צריך להתריע על כולם או לא. ובמידה וזה באמת show stopper, או גם אם יש ספק או אין ספק, אם לא בטוחים אז מתריעים. ואז ה-dev of the day ובדרך-כלל כל הפיתוח עוצרים את כל מה שהם עושים, וכל מי שיכול להיות מעורב מעורב בזה כדי לפתור את הקרייסיסים האלה כמה שיותר מהר. זה דווקא בהקשר הזה זה קל במירכאות, זאת אומרת זה דברים שלא צריך process ולא צריך-

ליאור:            שיש בהירות לגבי מה שצריך לעשות כאן.

גיא:               כן, לא צריך process ולא צריך כלום, צריך שכולם יעשו את זה.

ליאור:            כן, אבל מה שכן ייחודי כאן זה שיצרתם שפה משותפת עם ה-CS כדי לוודא שכולם מבינים מתי מתריעים ומתי לא.

גיא:               נכון.

ליאור:            אחרת זה “זאב זאב” מה שנקרא.

גיא:               נכון, נכון. וזה רק חלק מהדברים, גם, בערך אחת לרבעון, איזו שהיא  מצגת שאני ושחר עושים לכל ה-CS, גם ה-CS גדלים, אולי המחלקה שגדלה עם האחוזים הכי גדולים פה בחברה. אז כל הזמן יש אנשים חדשים שצריכים לעבור את ה-training הזה, של איזשהו יישור קו לגבי איך פותחים טיקטים ב-dev of the day, מה הדברים שצריך לשאול את הלקוח לפני שהדברים האלה מועברים למפתח – בגדול, מה כל הדברים שאיש ב-CS יכול לעשות בעצמו כדי לנסות לפתור את זה לפני שזה מועבר ללקוח. וחלק מזה כמובן זה גם מתי להתריע שזה תקלה חמורה ואם זה גם אמצע הלילה אז להעיר וכל מה שצריך לעשות כדי לעשות את זה.

ליאור:            וגם איזה מידע לאסוף כדי שאותו מפתח יידע לפתור את הבעיה.

גיא:               נכון, נכון.

ערן זינמן:       עשינו שיפור משמעותי בדבר הזה. זה עדיין אתגר מאוד מאוד גדול. בהתחלה, כמו שגיא תיאר את זה, אז זה נולד שוב, מכאבים, שבעצם אנשי ה-CS נתקלו באיזו שהיא  בעיה, למשל ללקוח נעלמו בורדים. ממש, data נעלמה מהמערכת, ואף אחד מה-RND לא נתן לזה פתרון במשך שלושה ימים. ואז כשגילינו את זה אמרנו “וואו, איך לא באתם, זה הדבר הכי חמור בעולם, לוקח איבד חלק מה-data שלו”, עשינו איזשהו יישור קו. אבל יש פתאום כל-מיני אזורים כאלה שהם עדיין אפורים. יכול להיות שכל לקוח מאבד טיפה מידע, אבל יש פה איזו שהיא  תופעה שהיא רחבה, אוקיי? זה כאילו, לפעמים אנחנו צריכים להסתכל על מיני-תופעות שקורות בתוך המערכת, שכל אחד בפני עצמה היא לא ביג-דיל, אוקיי? זה משהו שאנחנו אומרים אוקיי, זה לא urgent. אבל אם מישהו מסתכל על זה בצורה רוחבית הוא אומר רגע, יש לנו פה כנראה איזשהו באג או משהו שמשפיע רוחבית על כל היוזרים. אז אחד מהדברים שאנחנו גם מנסים תמיד להגדיר ל-CS זה – והם גם עושים עבודה אצלם, שחר עושה את העבודה המקבילה שנוגעת בעצם ב-CS – לראות אם יש איזשהו מכנה משותף בין כל הטיקטים, כי לפעמים המכלול של הטיקטים בעצם מצייר איזו שהיא  תמונה שכל אחד בצורה אינדיווידואלית לא מצייר.

גיא:               אני רוצה לתת עוד איזו שהיא  דוגמה קטנה לגבי מה שערן אמר. הנושא הזה של אני מתכלל את הסיפור הזה הוא באמת נכון כדי למצוא פרטנרים כמו ה-recycle bin, דיברנו על זה, אבל יש דברים ב-scale הרבה יותר קטן שגם הם נפתרים ע”י הטוענים עצמם. זה איזשהו שינוי שעשינו שאני חושב שהוא מאוד מאוד עזר לנו, של להגדיר את ה-dev of the day במהלך היום, שהוא לא מתעסק בשום דבר מהאיטרציה שלו בכל היום. זאת אומרת, הוא רק על טיקטים של dev of the day, ואם אין כאלה, יצרנו איזשהו backlog מתוך בדרך-כלל טיקטים של dev of the day של דברים קטנים במערכת שאפשר לעשות. ומה שזה גרם בעצם זה שכל מפתח מנסה לפתור בעיה כמה שיותר מהשורש. עכשיו, זה לא אומר עכשיו לפתח פיצ’ר שבועיים. אבל זה אומר באמת לראות פתאום יוזר שהוא בסטטוס מחוק מופיע לו משהו מוזר ב-database. אז אפשר לתקן ליוזר הזה את הדבר הזה, להחזיר את זה חזרה את הפרמטר והכול יהיה סבבה. אפשר רגע לחשוב, ונגיד, זה באמת מקרה שקרה לפני כמה ימים, שמצאנו איזו שהיא  בעיה, פתאום ראינו יש 5000 יוזרים שהעפנו מה-database שיש להם איזו שהיא  בעיה בנתונים, שמשהו שם לא מסתדר. מצאנו איזשהו באג, הוא לא היה חמור במיוחד, אבל זה, מדובר על נתונים נכונים, זה מאוד מאוד חשוב.

ליאור:            והקשב הזה זה מה שאפשר את ה-

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

ליאור:            ירד הלחץ הזה.

גיא:               בדיוק, וכשזה point of contact לכל המחלקות בחברה ה-mindset פשוט התחלף, אז האחריות הזאת של דברים לא רפטטיביים היא גם עליי אבל היא גם על המפתחים עצמם שעושים את התורנות הזאת, שזו נקודה מאוד חשובה.

ליאור:            שזה מחבר אותי לשאלה יותר גדולה, של איך בעצם מודדים את העבודה של ה-dev of the day.

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

ליאור:            טיקטים איפה, רגע, של מי למה?

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

ליאור:            מה אתה לומד מהמספר הזה?

גיא:               קודם-כל אני לומד את המספר. זה הדבר הראשון שאני יודע, זה שיש את המספר ועכשיו אני יכול לשאוף לזה. השאיפה היא בגדול לאפס dev of the day. כי כל dev of the day הוא באמת מעיד על איזשהו חוסר, או במערכת, או ב-back office, או knowledge base, או הבנה, או באג – ואם הוא באג אז הוא צריך ללכת לבאגים, שעליהם אולי נדבר קצת בסוף הפרק, אבל הם לא דברים אופרטיביים שאני צריך לטפל מעכשיו לעכשיו. אז זה צריך לשאוף לאפס. אני לא יודע אם אנחנו באמת נגיע לאפס, אבל זה צריך להיות לפחות, איך אני אגדיר את זה? אפס דברים שחוזרים על עצמם. רק דברים חדשים כל פעם צריכים להתווסף לשם ולא דברים שאני כבר ראיתי וטיפלתי. וזהו, ו-

ליאור:            ואת המדד הזה אתם מסמנים לכם?

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

ליאור:            אין קפיצות.

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

ערן זינמן:       ואפרופו, עכשיו אנחנו בדיוק לוקחים את זה לשלב הבא. כי אחד הדברים שהבנו הוא שיש את הדברים שה-CS יודעים לקטלג אותם כבעיות או שהם לא יכולים לפתור. אבל, וממש ניהלתי עם זה שיחה עם תום חלפני שבועיים, שאמרנו אוקיי, אבל עדיין נפתחים המון המון טיקטים ליוזרים ביום הראשון שלהם במערכת. שהם לאו דווקא באגים או דברים שצריך לשלוח ל-RND, אבל הן בעיות. ומה שאנחנו עכשיו עושים, זה אנחנו ממפים בעצם את כל הטיקטים שקורים ביום הראשון או ביום השני ליוזרים. כי גם אם זה לא באגים per se, או דברים שלא ברורים, יש שמה כל-מיני דברים שלא ברורים לגבי המוצר. יש שמה כל-מיני דברים שלא ברורים לגבי ה-pricing. יש שמה כל-מיני דברים שלא ברורים לגבי איך להזמין יוזרים. והתחלנו למפות את זה ואמרנו רגע, אלה בעצם באגים, או בעיות ב-product, שהם לאו דווקא בא היוזר ואומר “יש לכם בעיה ב-product.” אוקיי? הוא שואל איזו שהיא  שאלה, משהו לא ברור לו, בתהליכים, ב-user experience, באיך הוא עושה משהו, וזה friction. ובעינינו friction זה משהו שה-product אמור לפתור אותו. אז זה עוד אינפוט שהוא לאו דווקא עכשיו איזו שהיא  שריפה שצריך לכבות, אבל הוא אינפוט מה-CS שמשפיע גם על ה-RND, ושוב, אלה דברים שאנחנו בחיים לא היינו מכניסים ל-roadmap אם היינו צריכים לחזות אותם או להגיד שהם יעשו אימפקט, אבל האימפקט שלהם הוא אדיר. אם אנחנו נצליח להוריד את אותם חמשת הדברים שמייצרים friction ביום הראשון או השני, אין לי ספק בכלל שתהיה עלייה ב-conversion, שאנשים ידעו איך להשתמש בתוכנה יותר טוב-

ליאור:            ושה-churn ייראה אחרת.

ערן זינמן:       לגמרי. אז זו דוגמה לאיך לקחת אינפוט שהוא רך, שהוא שאלות של אנשים, דברים שנראה להם לגיטימי לשאול, ולהפוך אותו ל-action item בעצם בתוך ה-product עצמו. [מוזיקה]

ליאור:            איזה עוד מתודות יש לנו חוץ מה-dev of the day כדי באמת לתת מענה לדברים שעולים מתוך ה-CS?

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

ליאור:            והם לא ברמת ה-dev of the day למה?

גיא:               הם יכולים להיות ברמת ה-dev of the day אבל לפעמים פשוט יש יותר מדי מהם, ואז לא רוצים להשבית מישהו שלם אה, זה, וימים כאלה מרוכזים זה, יש לזה גם תופעות לוואי מדהימות אחרות, כל הפיתוח עובד על משהו אחד, על מלא משימות קטנות שאתה עושה-

ליאור:            גיא, תופעת לוואי זה דבר רע. אתה מתכוון להגיד שיש לזה עוד אימפקט ו… [צוחקת]

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

ליאור:            ותסביר לנו רגע מה זה הימים המרוכזים האלה.

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

ליאור:            cheese זה גבינה בפעם האחרונה שבדקתי.

גיא:               נכון.

ליאור:            אז אנחנו קוראים, משתמשים במילה גבינה ל?

ערן זינמן:       אני אסביר.

ליאור:            תסביר [צוחקת].

ערן זינמן:       האמת שהקרדיט פה מגיע לרועי, הוא יום אחד בא אליי ואמר לי תקשיב, יש איזשהו blog-post שקראתי מ-Blizzard. מי שלא מכיר, זה היוצרת משחקים הכי גדולה בעולם. על, שהם דיברו שם על cheese. והוא אמר לי cheese זה בעצם הלכלוך הזה שיש בין האצבעות ברגליים. אמרתי לו “איכס, יא מגעיל.” [צוחק].

ליאור:            איייייכס.

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

ליאור:            וואי איך ביאסת אותי עכשיו.

ערן זינמן:       למה?

ליאור:            כי תמיד אני חשבתי שהבורד הזה שנקרא cheeses זה כאילו גבינות-

ערן זינמן:       אבל זה הקטע. אז מה שאנחנו עשינו-

ליאור:            ועכשיו הבאת [צוחקת]

ערן זינמן:       אז מה שאנחנו עשינו זה-

ליאור:            פרשנות אחרת שקשה לי להיפתר ממנה.

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

ליאור:            זה כמו לסדר את המגירה הזאת בבית שאף פעם לא מגיעים אליה.

ערן זינמן:       בדיוק, בדיוק. ואז אתה מסתכל על הארון, אתה אומר “וואו, איזה כיף זה היה.

ליאור:            המוזנחים האלה, או השיחת טלפון הזאת שאתה אף פעם לא עושה או הצ’ק שאתה לא מפקיד.

ערן זינמן:       והמוצר פתאום נראה מיליון דולר. זה כאילו בדיוק הדברים האלה שפתאום המוצר נראה מיליון דולר וכאילו אתה אומר איזה סיפוק, כאילו, לכל מי שיש OCD זה כאילו הדבר הכי מספק שקיים בעולם. ו-too be honest, לא היינו מגיעים לזה בחיים. ואני חושב שעיניי זה איזשהו statement של החברה, שאנחנו אומרים חבר’ה, זה חשוב, הדברים האלה, הפיקסל הזה, הוא חשוב, ואנחנו חייבים לקחת את הזמן ולהקדיש אותו לעשות את הדברים האלה. כי ה-details חשובים כמו המאקרו. בעינינו.

גיא:               אני ממש ממש מסכים עם זה. בעיקר זה פשוט מעלה את ה-awareness של הדבר הזה, שאחר-כך אם אתה רואה את הדבר הזה אז אולי אתה תפתור את זה בין משימה למשימה בלי כזה להכניס את זה עכשיו לאיזה backlog או דברים שאף פעם לא נגיע אליהם. אז מדי פעם לעשות דבר כזה, או כמו שערן אמר על ה-cheeses, אותו דבר ל-quality. מין באגים קטנים כאלה שהם כאילו לא מספיק חשובים אבל נורא מציקים ולוקח שנייה לפתור אותם, אז לתפור כאלה שכל הפיתוח, 15 חבר’ה, יום שלם, זה כוח עבודה עצום, מתעסקים רק בדבר הזה, ובסוף מראים עשרות משימות שסיימנו באותו יום. זה באמת ממש מספק, זה אחלה מוטיבציה, זה אחלה גיבוש, זה מעלה את ה-awareness, יש לזה כל-כך הרבה דברים חיוביים נוספים על זה, שזה ממש כיף.

ליאור:            כל כמה זמן אנחנו עושים יום כזה?

גיא:               אז האמת, זה לא איזשהו עניין מתודי. זה עניין של הרגשה, ותחושה. וזה באמת גם פה מגיע ה-value שלי כמישהו שמתכלל את הדברים האלה בצד של הבאגים ו-dev of the day ורואה את זה, לצ’יזים יש לנו אואונרים אחרים גם. וזו איזו שהיא  החלטה שאנחנו מקבלים שאנחנו אומרים אוקיי, בואו עוד שתי איטרציות, נעשה יום כזה, מרגיש שמתחיל להצטבר, הטונוס קצת יורד, כל-מיני דברים כאלה. אז אני דווקא מאוד מאוד אוהב את זה שזה בא מהרגשה ומאכפתיות ולא מכזה כל חודשיים טוב, הגיע הזמן, רוצים, לא רוצים, זה נראה הרבה פחות כאילו אמיתי וכואב מאשר כאילו לעשות את זה-

ליאור:            ואז יש התלהבות גם אותנטית כשזה ככה קורא בצורה מחוברת למציאות.

גיא:               נכון, נכון. בפועל הייתי אומר שזה קורה אחת לרבעון give or take, אבל באמת, לא בודקים מתי האחרון כדי לקבוע את הבא, זה עניין של- וזה הרבה פעמים גם באמת בשינויים. אם עכשיו עשינו קפיצה מטורפת ב-product כמו בחודשים האחרונים אז מן הסתם שכמות הצ’יזים והבאגים וה-dev of the day עולה כי זה כל-מיני ריקושטים מהדברים האלה, אז צריך יותר בדחיפות לעשות. אם זו תקופה שמתעסקים יותר בתשתיות אז יש פחות כאלה. אז זה מאוד מאוד נזיל וחלק מהכיף.

ליאור:            מה עדיין מאתגר?

גיא:               אז בנושא הזה של ה-dev of the day, מה שעדיין מאתגר זה שעם כל הדברים הבאמת טובים שעשינו אנחנו עדיין לא מצליחים להוריד את זה לרמה כזאת שזה שקוף כמו שהיינו רוצים. ואני חושב שהרבה מה-

ליאור:            שקוף למי? לא הבנתי.

גיא:               שזה יהיה ב, זאת אומרת שזה כמעט לא ידרוש זמן מפתח. זאת אומרת, אם ה-KPR שלנו יגיע לאפס dev of the day זה אומר שהמפתח אפס זמן מהאיטרציה שלו מתעסק בדברים שלdev of the day. ואנחנו עוד לא שם, ואנחנו האמת די רחוקים משם. ולפעמים אפילו למפות את האתגרים זה נורא קשה, בגלל שב-dev of the day זה כל הזמן דברים חדשים. הם אמנם אחר-כך חוזרים על עצמם, אבל זה דברים חדשים שחוזרים על עצמם. אז למצוא את הפטרנים האלה זה עבודה שכל הזמן צריך לעשות. אני חושב שיש לנו עוד כברת דרך לעשות בצד של ה-CS בהכשרות, בעיקר בגלל הגדילה המאוד מאוד משמעותית שם. וגם הכשרות בצד של הפיתוח שאנחנו צריכים לעשות כדי למנוע כמה שיותר את הפינג-פונג, אולי אני אגיד על זה מילה, יש פינג-פונג, בעצם אם עכשיו ב-CS פתחו טיקט ואני עכשיו dev of the day ואני קורא את זה וחסר לי מידע. אז אני מעביר את הטיקט בחזרה ל-CS ואני אומר תשיגו לי בבקשה את א’-ב’-ג’, ואז הם מחזירים את זה חזרה. כל פעם שקורה כזה פינג-פונג, לא יודע, זה בערך ב-20 אחוז מוריד את הסיכוי שהדבר הזה ייפתר. כי עובר זמן, וזה כבר לא משתחזר ולאף אחד לא איכפת ו-

ליאור:            ואז זה עובר ה-dev of the day של היום שעבר, ושעבר, ואז צריך את הקונטקסט מחדש.

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

ליאור:            וואו, זה ממש בעייתי.

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

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

גיא:               בדיוק. ואז לקרוא thread מלא הודעות זה, ולהיכנס לקונטקסט ודברים כאלה. גם בנושא הזה אנחנו עשינו איזשהו שינוי שאמרנו שאם מישהו מתחיל לטפל בטיקט הוא יסיים לטפל בו גם אם הוא לא dev of the day.

ליאור:            יקבל עליו ownership גם אם הוא כבר לא ה-dev of the day.

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

ליאור:            להגדיל ראש שם ולקחת את ה-

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

ערן זינמן:       בעיניי אתגר מאוד גדול הוא איך עושים לזה scale. ואני לא מדבר על איך מספיק מפתחים עונים על dev of the day, אלא איך עושים דווקא scale בבני אדם. כי ככל שאנחנו גדלים ב-CS מגיעים עוד אנשים, ופתאום ההגדרות מיטשטשות, של מה זה באג, מה זה cheese, אולי לאנשים שונים יש סטנדרטים שונים. אנחנו, אני מאוד בגישה של לדקדק בפרטים והכול מאוד מאוד חשוב, אבל יכול להיות שמישהו שהיום מגיע ב-CS אומר “טוב, יש פה לכמה לקוחות בעיה אבל אני לא אטריד עכשיו את dev of the day כי אני יכול לפתור את זה בעצמי.” אז איך מייצרים את ה-education הזה. אגב, גם אצל המפתחים. זאת אומרת, יכול להיות שמפתח יקבל dev of the day ואז הוא יכול להחזיר ל-CS, “תקשיבו, זה לא בעיה. זה ככה מאז ומתמיד ובוא לא נפתור את זה.” אז איך עושים scale ל-state of mind, איך עושים scale ל-

ליאור:            לרגישות.

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

גיא:               אני ממש ממש מסכים עם זה, וזה באמת עניין של מישהו התלונן שמשהו קורה, זה עובר ל-dev of the day, ה-dev of the day אומר “אה, זה לא משתחזר לי.” אז ברור שאני לא מחזיר את זה עכשיו ל-CS, כאילו, לי זה ברור, אני רוצה שזה יהיה ברור גם לכולם. כי אם הלקוח התלונן, קרה לו, וכמו שערן אמר לפני, על אחד שמתלונן יש 15 שלא התלוננו, אז זה משהו שקרה אם הוא כבר דיווח לנו, זה משהו שקרה. אז אולי יש תנאים מסוימים, אולי אפשר להוסיף כל-מיני דברים, איזשהם, יותר מידע במערכת כדי שאנחנו נדע בפעם הבאה שזה קורה, זה גם פתרון לגיטימי לבוא ולהגיד אוקיי, הוספנו יותר מידע עכשיו במערכת, פעם הבאה שזה יקרה אנחנו נדע למה. זה גם פתרון. אבל העניין לתת איזו שהיא  התקדמות ולפתור משהו במקסימום שאנחנו יכולים באותו רגע.

ערן זינמן:       אפילו אם זה לא באג, הוא כנראה לא הבין משהו.

גיא:               כן.

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

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

ערן זינמן:       לגמרי.

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

גיא:               כן. אז נתחיל מסיסמה שאין קיצורי דרך, אבל בוא רגע נדבר קצת יותר. אז למדוד. דבר ראשון זה למדוד, ולמדוד מההתחלה. כי ברגע שיש מספר מול העיניים יודעים עם מה צריך להתמודד. אולי המצב הרבה יותר טוב מה שאנחנו יודעים, אולי המצב הרבה יותר רע ממה שאנחנו חושבים כאילו. אז מציאות מול הפנים זה הצעד הראשון בלהבין מה האתגר שאנחנו עובדים איתו. זה הדבר הראשון. הדבר השני, דיברנו על זה שהתפקיד הזה של המפתח תורן, הקלאסי, הוא תפקיד די מבאס, בואו נודה על האמת. ואני חושב שזה אתגר מאוד מאוד רציני להפוך אותו לתפקיד עם אימפקט כמו כל הדברים שאנחנו מנסים לעשות פה. ואני חושב שכל הדברים שדיברנו עליהם בתחילת הפרק, עם המדד וה-KPI ולהוריד את זה ולחקור דברים מהשורש ולפתור אותם ב-product, כל הדברים האלה, בעצם הופכים את זה שבן אדם מסיים את ה-dev of the day, אני לא אגיד שזה היה יותר כיף מלעבוד על פיצ’ר באיטרציה, בוא לא נגזים. אבל הוא מסתיים בזה שהוא אמר אני השארתי את ה-dev of the day יותר טוב ממה שקיבלתי אותו היום בבוקר, ולא רק עשיתי אותו מאותו דבר. ואני חושב שזה הבדל מאוד מאוד מהותי באיך שכולנו ניגשים לזה. ושוב, יש עוד הרבה מה לשפר. גם עם כל הדברים שאנחנו עושים, אבל אני חושב שזה הנקודות המרכזיות שהייתי נותן למי שמתחיל עם זה. זה למדוד ולעשות את התפקיד הזה אפקטיבי.

ערן זינמן:       אני חושב ש, כיזם או כמישהו שמנהל פיתוח, מאוד קשה לבוא ולהגיד “חבר’ה, עוצרים הכול, בואו נשפר את האיכות.” חבר’ה, אני מקריב מפתח פעם בשבוע לעשות את התיקונים.” תמיד קל לברוח למקומות של “בוא נעשה עוד פיצ’ר, בוא נתקדם, בוא נייצר אימפקט.” ובעיניי האימפקט של זה הוא אדיר. העובדה שאיכפת לנו מה-quality של המוצר גם בימים מרוכזים וגם לאורך השנה היא לא רק טובה לאותה נקודה שבה אנחנו משפרים את הדברים ומתקנים אותם – היא טובה לכל השנה. זה שולח statement, זה מכניס את האנשים ל-state of mind מסוים. אני חושב שהאפקט המצטבר של זה על הלקוחות ועל החברה הוא עצום. שאפשר להבין אותו רק מתוך כל הפרטים, אבל התפיסה של הלקוחות, ברגע שהם רואים שמוצר הוא מהודק והוא איכותי ואיכפת לנו מדברים קטנים של UI ואיך האנימציות נראות ושהכול בול – הוא אפקט מצטבר, שיש לו ערך עצום. ואני חושב שהערך של זה הוא ענק וצריך אפילו לפעמים להכריח את עצמך לייצר את הסיטואציות האלה, וה-value של זה הוא יוצא דופן. ואני חושב שמעבר להכול, זה משהו שמייצר ownership מאוד מאוד חזק אצל המפתחים. אני חושב שהרבה פעמים בחברות יש כזאת תכונה של “יש את ה-QA, הם יבדקו את המוצר, הם ידווחו לי אם יש בעיות.” כאילו באיזשהו מקום אתה מסיר את האחריות מעצמך של האיכות של המוצר, איך שהוא נראה, היא לא עליך. מישהו ידווח לי ואני מתקן. הסיטואציה שאנחנו מייצרים פה בעצם היא סיטואציה שבה המפתחים לוקחים את האחריות, איכפת להם, הם יודעים שהדברים האלה בעצם יחזרו אליהם דרך ה-Customer Success, ואין מישהו מלבדם שייקח את ה-ownership ויתקן אותם. ואני חושב שההעצמה הזאת, שבעצם המפתח לא רק מרגיש שהוא צריך לעשות פיצ’ר או לעשות עוד איזה משהו שיקדם את המוצר אלא יש לו אחריות כוללת על האיכות ועל ה-delivery של המוצר – היא מאוד מאוד משמעותית.

ליאור:            גיא, תודה רבה שהצטרפת אלינו.

גיא:               תודה, היה כיף מאוד מאוד.

ליאור:            ומלמד מאוד מאוד. תודה ערך.

ערן זינמן:       תודה ליאור. אתה צריך לחזור להיות dev of the day?

גיא:               נכון. [צוחקים]. בשמחה.

ליאור:            תודה שהאזנתם.

ערן זינמן:       תודה רבה.

 

[wp_applaud]