76: השמעה חוזרת - Dev of the Day - כשמפתחים ונציגי תמיכה עובדים יחד

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

"There is a lot of feedback coming in from users, all of the time. And what we had before that was very frustrating was that the CS employees, that we gave a goal of answering tickets as quickly as possible, have come running to the R&D asking for help with every new ticket. The R&D, on the other hand, is telling them 'wait, what do you want with me? I'm in the middle of a meeting' or 'I can't right now, we're working on a new feature'. Constant contact switching. No separation between the wheat and the chaff, and it created a lot of problems".

This quote was said by Eran Zinman, Co-Founder and Co-CEO at monday.com, in episode 17 in which we spoke about the conflict between CS and R&D. It's a problem that most companies have probably experienced, resulting from the fact that CS wants to find a quick and efficient solution for the clients tickets, yet the R&D can't stop everything to deliver the answer. This week we're going back to episode 17, in which Lior Krengel spoke with Eran and Guy Asinovsky, then a developer and today R&D Team Lead at monday. They spoke about the scope of this job in our company, how we concluded it is a good way to resolve this issue, and how to scale it

תמלול הפרק

התמלול נוצר אוטומטית ועשוי להכיל שגיאות.

יש המון המון פידבקים שמגיעים ללקוחות כל הזמן, במיוחד תוכנה שיש לה שימוש יומיומי, על בגים, אפילו לא בגים, אפילו אנשים שעשו איזושהי פעולה בטעות ורוצים לשנות משהו, לשחזר איזשהו משהו, איזשהו יוסקי ספציפי שהם לא מבינים למה זה קרה להם ככה ולא אחרת, וה-CS לא תמיד יכול לענות. לפעמים הוא צריך או מפתח שיבדוק את הבג, או מפתח שיעשה משהו בדאטאבייסט בשביל לעזור ללקוח, ומה שהיה לנו בעבר שהיה מאוד מתעסקל זה שאנשי ה-CS מצד אחד שמנו להם יעד של לענות מאוד מאוד מעל טיקטים, אז הם הגיעו בריצה ל-R&D, ו-R&D, רגע מה אתם רוצים, אני ב צע ישיבה, מה אתם רוצים, אנחנו ב צע פיצ'ר, קונטקסט סוויצ'ינג תמידי, שום פריורטיזציה וניכר לטפל, אולי יש עכשיו בג שאף אחד לא מצליח להיכנס למערכת, אולי זה רק בג שקורה ליוזר אחד מתוך אלף, זה יצר המון המון בעיות. גם עוד בעיה שקרתה לנו זה שכל פעם באו לאותו בן אדם, כי אולי זה שהוא go to person כאילו ב-R&D ופשוט לא הצליח לעבוד, וכל השאר פשוט ככה קרה שפחות באו אליהם, ו רנו בסדר, אי אפשר להמשיך ככה, זה לא סקיילביל. כן, שוב, זה גם ככה, אתה מציג את התסכול של המפתח שפונים אליו, אבל אני יכולה לדמיין איך נציג ב-CS לא יכול לתת את המענה האיכותי בלי ב ת לעבור דרך איזשהו מפתח. לגמרי, זה לגמרי, מצד אחד אנחנו… זה קצת inkful failure מהשתיארת כאן. כן, אנחנו דוחפים אותם לענות מהר לענות איכותי, הם לא רוצים סתם לתת תשובה ללקוח שהיא לא יתית, שאין לה ביסוס למציאות. לפעמים הם גם בעצמם מזדהים עם הלקוח אולי ואומרים, בואנה, יש פה בעיה שב ת כבר צריך לתת לה מענה יתי בתוך הפלטפורמה. לגמרי. ואולי אם הם נגיד אותם מלא פעמים, אז זה משהו ישתנה מהותית. כן, אבל לא היה את האינטרפייס הזה. זאת אומרת, לא הייתה את המתודולוגיה ואת התהליכים בשביל לתמוך בדבר הזה, זה היה מאוד מאוד רנדומלי. ואז נכנע לחשוף פונקציה של הדבב דדי.

היית סתם לא רגעך זו היום. אז בעצם היום זה תורנות של 24 שעות שוברת בין כל המפתחים, היום זה כבר לא מפתח אחד, יש בערך 20 שעושים את התורנות הזאת, וזה תפקיד שיש לו כמה קובעים. קובע אחד זה ב ת הקטע הקלאסי הזה של מפתח תורן, זה להיות זמין עם הלפטופ, תקלות, אתה יכול מצלצל, כל מיני דברים כאלה. אנחנו פחות נתמקד בזה. ניתן לדבר על מה קורה במהלך היום, וגם איך כולם יודעים עם מי לדבר. אז נגיד עכשיו הוא נמצא על דשבורד, הדשבורד העיקרי שלנו, כל יום יש שם את השם, לקחנו סגנס שיודעים מי לדבר ולמי לפנות במידה ויש שם. כל החברה יודעת. כל החברה יודעת, ובעיקר כמובן ה-CSML שככה בממשק מול ה-Day of the Day. כן, אבל לקחת את זה אפילו לרמה היותר בסיסית שאם עכשיו מישהו לא יודע מי ה-Day of the Day, אז הוא יכול לשאול וכל אחד אחר ידע לענות על זה. לא צריך לחפש את האדם שיודע מי ה-Day of the Day. אבל ב ת ככל שגם ב ת החברה גדלה, הסקייל בתוך החברה גדל, אז ה-Day of the Day הפך להיות גם ה-Point of Contact לסלס ולפרטנרס, לעוד ל-CS ולשאלות מכלל המחלקות בעצם בחברה. וכולם בקלות יכולים לראות מי זה ולפנות אליו דרך הבורד של ה-Day of the Day, שזה גם איזשהו שינוי שעשינו. לא לבוא ולהציק בכתף עכשיו אתה יכול לעזור לי, אתה יכול לענות לי, אלא אם כמובן אם זה דחוף, אבל זה כבר גם נשים את זה לרגע בצד. דברים שוטפים, שאלות שוטפות שיכולות להיות מענה תוך במהלך היום, פותחים טיקט בעצם פולס בבורד של ה-Day of the Day. ה-Day of the Day יודע שהוא כל כמה שעות, כל שעה, לא משנה, דוגם את הבורד ומטפל בדברים שיש ונותן את התשובות. אוקיי, אז בעצם אותו ה-Day of the Day עכשיו אחראי לתת מענה ל-CS על כל הבעיות שעולות באופן פרטני? זה מה שאתה בעצם אומר? אז בגדול… נשמע לא מועיל. נכון, נכון. אז… גם לא כיף. זה גם נכון. אז בגדול זה המצב, אבל אנחנו כן לוקחים את זה לקצרים, וזה גם חלק מהסיבה שהדברים שבתפקיד שלי לעשות בהקשר הזה של ה-Day of the Day. מה זה לקצרים? זה להמלל ממש את ה-Day of the Day? לפעמים, אבל אנחנו משתדלים זה לא. זאת אומרת, זה קצרים מבחינת הפרודקטיביות ומבחינת איך לעשות לזה סקייל כמו שצריך, ולהרגיש שיופעים את הדברים עם אימפקט ולמקום שהוא מקדם אותנו, ולא רפיטטיביות כזאת מעצבנת שאף אחד לא אוהב. אז בשביל לעשות את זה צריך איזשהו לפעמים מבט על על הדברים האלה. התפקיד הזה עובר מבין אדם לבן אדם יום אחרי יום. הדברים שבדרך כלל צריך לפתור כקול דבר ספציפיים, לא גדולים. זה לעשות איזה תיקון פה, להיכנס רגע לדאטאבייס לעשות איזה תיקון שם, אבל כשהם מתחילים להצטבר הכמויות האלה ולחזור על עצמם, ואנשים לא תמיד מודעים שהם חוזרים על עצמם, בעיקר בגלל על זה סבב הגדול הזה, אז צריך איזושהי ראייה מלמעלה ולתכלל את זה. תיאום בין המפתחים אתה אומר. תיאום בין המפתחים ובעצם לזהות תבניות ודברים שחוזרים על עצמם, אם זה סוגי תקלות או לא משנה, צריך להפיין את זה בכל מיני דברים, ואז לנסות לראות אם אפשר לתקוף את הדברים האלה מהשורש ולתת להם איזשהו פתרון שהם פשוט לא יחזרו. וזה חלק מהדברים שאני עושה. ואני חושב שאחד הדברים הכי מגניבים בדבר הזה זה שאני לא עושה את זה לבד. יש את שחר מהCS שהוא כבר התארח בפרק אחר, שהוא אחראי על בדיוק אותה נקודה, אבל מהזווית של הCS. כי הבעיה הזאת שאנחנו מדברים עליה פה היא לא בעיה של הR&D והיא גם לא בעיה של הCustomer Success, היא בעיה של החברה. זה יכול להגיע למצב שבכדור שלג שבקלות מאוד משתתק את כל החברה מלעבוד כמו שצריך. או שתי מחלקות מאוד עיקריות לחברה. אז ברגע שיש אונר מוגדר גם מהצד של הR&D וגם מהצד של הCS לדבר הזה, ואני ושחר ב ת עובדים בסינרגיה ובתיאום ממש ממש טוב, זה ממש מקל על התהליך. זו דוגמה לדעתי מאוד מאוד טובה לאיך כן אפשר לקחת פרוסס שהוא טוב ותורם לחברה. תמיד אנחנו טיפה ציניקנים לגבי כל הנושא של תהליכים. זה נשמע כזה טיפה קורפורט ומה אנחנו לא עושים פרוססים, אנחנו חברה שטוחה ובלי כל מיני בירוקרטיות. אני ממש זוכר קלשים מטורפים מהעבר שהCS באים ואומרים תקשיב זה לא הגיוני שהR&D לא שמים עלינו. יש לנו פה בעיות והמפתחים אומרים לנו כאילו ללכו תתחפשו ואין לנו זמן כרגע. המפתחים מצד שני אומרים אנחנו לא יכולים עם הCS הזה, הם באים ומשגעים אותי כל הזמן. ואתה אומר רגע שניהם רוצים את טובת החברה. הרי ברור שהCS רוצים את טובת החברה, הR&D רוצים את טובת החברה, יש פה בעיה של פרוסס. בני אדם כאילו לא יפתרו את זה בעצמם. דוגמה מדהימה לדעתי לאיך אפשר לעשות פרוסס שהוא יחסית לייטווייט שב ת טוב בין שחר לבין גיא, שהוא סקיילבילי ועובד ושממש ממש תרם לשני הצדדים בתוך הדבר הזה. טיעום ציפיות, תהליכים, כולם יודעים איפה הדברים עומדים.

זו דוגמה ממש ממש טובה לפורסס שעובד טוב.אז בואו נבין מתוך דוגמה איך זה נר בפועל הלכה למעשה.אז דוגמה ממש ממש טובה עם משהו שפתרנו,זה היה בעיה שהייתה חוזרת על עצמה,אנשים היו מוחקים בטעות בורד, פולס, קולום או משהו כזה,ולא הייתה דרך במערכת לשחזר את זה.והדרך היחידה בעצם של ה-user זה לפנות לקסטומוס אקסס,ולהגיד, שחזרו לי את הבורד, יש לי עוד שנייה מסגת,ולהיעלם מכל המידע, ואני מזיע פה ונורא לחוץ.ולפי הסנסס שלהם יודעים שאין להם שום דרך לעזור בעצמם,הם יודעים שהם צריכים לפתוח טיקט בפולס ודאב דה די בורד לעשות את זה.המפתח יודע שהוא צריך להיות ידנית בדאטאבייס לעשות את הפעולה הזאת,כי אין שום דרך לעשות את זה.ושוב, כשלעצמו זאת פעולה שהיא לוקחת כמה דקות,אבל א' התהליך הזה end-to-end הוא ליוזר,הוא הרבה יותר ארוך מאשר אם הוא היה יכול לעשות את זה בעצמו,לדוגמה.ודבר שני, כשהדברים האלה מצטברים…זה סיפור על חוסר יעילות מכל ה…מה זה? מהחוסר יעילות?לגמרי.ומצד שני, כשבן אדם עושה את זה פעם אחת אחלה,אבל כשבן אדם צריך לעשות את זה שלוש פעמים כפול 15 מפתחים,זה כבר הופך להיות אישו.וכמובן, זה רק דוגמה אחת מתוך כל מיני דברים אופרטיביים כאלה שקורים.ובעצם מה שעשינו בנקודה הזאת,זה קודם כל ב ת לזהות את זה.וזה מתקשר לנושא של מה שדיברנו,של לעשות שוב רטרו כל כמה, כל חודשיים, כל שלושה חודשים,על הסיפור הזה.וננסות למצוא תבניות ודברים שחוזרים על עצמם.ראינו שהנושא הזה של שחזורים הוא בעייתי ביותר ומשמעותי,ושיש לו פתרון ברור בפרודקט,שאפשר לפתור את זה בדמות ריסייקל בין,שזה פונקציה שכולנו מכירים מכל מקום.ובעצם להתייחס לזה כפיצ'ר שצריך להיכנס לרודמפ, להתראציות הקרובות,עם פריורטי יחסית גבוה, כי איך שזה פוגע בדפוקה של המפתחים, זה מאוד ניכר לעין, ושל ה-CS, וכמובן בזמן תגובה וכל מה שדיברנו. ועל הכוח. ועל הכוח, בסופו של דבר. זה בעצם שלושה פרמטרים שאנחנו מתייחסים עליהם כל הזמן, עד כמה זה משפיע על הלקוח, עד כמה זה… נכון, בדרך כלל יש יחס מאוד ישר בין כל שלושת הגורמים האלה. וב ת גם זה נר לי מקרה, שוב, לא מתיימרת, אבל נשמע לי שזה מקרה שקל להכריע שחשוב להתייחס אליו בצורה שהיא יותר סקלבל, נכון? נכון. זה ב ת דוגמה ממש ממש קלאסית לסיפור הזה. ואז זה לא נפטר כאיזה בן חורג של טוב, צריך לעשות איזה משהו, זה DESIGNER, זה PRODUCT, זה פיתוח כמו שצריך, זה FEATURE שנכנס לפייפליין כמו כל הפיצ'ר שאנחנו מפתחים. לקח את זה כמה שבועות לפתח את זה, זה נכנס. כמובן, Knowledge Base, הכשרה של ה-CS, איך מפעילים את הפיצ'ר, זאת אומרת, איך מסבירים ללקוחות איך להפעיל את הפיצ'ר. וזהו, ומאז כבר שנה וחצי… שחררת פה עליו, קפוץ משמעותי. כן, הטיקטים האלה חלפו מן העולם, הוחלפו על ידי אחרים, כי כל הזמן המוצר מתקדם ומתפתח, ויש כל מיני חוסרים ודברים שצריך להשלים. אבל זה ב ת דוגמה לאיך משהו שהוא לכאורה לא מזיק, בפועל מאוד מאוד מזיק, ונסתר על ידי פשוט לשפר את המוצר. גם דוגמה למשהו שלולי התכלול הזה שאתה מתאר, המקום הזה שבו אנחנו בעצם אוגרים ומאגדים את כל המידע על מה שקרה דקה לפני זה או יום לפני כן, לא היינו יודעים שזה כזה חזרתי וכזה מורכב, כי על פניו כשכל מפתח מתמודד עם זה זה לא איזהו אתגר גדול, נכון? נכון. למניחה שהפעולה הזאת של לחזור לדאטאבייס ולשחזר היא אחת הפשוטות. נכון. אבל חייבים פה את המטה דאטה של החזרתיות כדי להבין שזה כזה גדול וכזה משפיע. נכון. וזה בדיוק האימפקט שאני חושב שזה מייצר. זאת אומרת, השינוי שגיא יתיאר הוא שינוי אדיר בפרודקט. אני בכלל תמיד בתפיסה שלי על כל בן אדם שפותח טיקט יש עשרה או חמש עשרה שלא פותחים טיקט, ופשוט מתייאשים, משנים את דעתם על המוצר, חושבים שהוא גרוע. איפה צריך שיבוא ויפתח טיקט? הווליומים של הדבר הזה הם דעתי עשירית ממה שזה משפיע ביום יום. וזו דוגמה לפרודקט לא טוב שהיה לנו. ואם הייתם שואלים אותי, ברודמפ שלנו אף פעם לא היה בוא נעשה ריסייקל בין. זה לא היה מעניין, זה לא פיצ'ר שחשבנו שיש לו אימפקט, זה לא פיצ'ר שחשבנו שקדם את המוצר. אבל אחרי שאתה מבין שאנשים מתלוננים על זה, שזה פוגע להם בחוויה, שזה פוגע להם בממשק משתמש בעצם בתוך התוכנה, אתה מבין כמה זה אימפקט. זה לא פיצ'ר שתמיד נולד מתוך המקום הזה של הנה אנחנו קדם את החברה צעד קדימה, אלא משהו שנולד מפיין. ואם לא היינו את הפונקציה הזאת ואת הראייה הרחבה הזאת של הנה זה מציק ליוזרים ברמה יומית, לא היינו מגלים את זה. ואני חושב שזה שהפיתוח עושה את זה זה תרם לזה. אני חושב שיש עוד רמה מעבר לזה, שזה נהיה יותר מסוכן, שעוד לפני שעובדים עליו, שלפעמים ל-CS, לקסטמר סקסס עצמו, יש כלים לפתור את הבעיות. ואם לקוחות במתלוננים, יש לקסטמר סקסס איזשהו אדמין פאנל או משהו כזה, והם נכנסים לאדמין פאנל ופותרים את הבעיה, הם בעצמם. וזה סיילנט קילר, זה משהו שמצאנו לו איזה וורקראונד, הפיתוח לא מרגיש אותו, אבל הוא הורג את המשתמשים. צריך לזכור, כל אחד שפותח טיקט, עשרה לא…

פותחים, זהו רגע שרה אחרים. אז ה-CS יודעים שגם דברים שהם רפטטיביים שמצליחים לפתור אותם, נכנסים בסוף לדוודדי, כי חשוב שה-R&D יהיה מודע לזה, שהמון לקוחות בעצם נתקלים בסיטואציה הזאת ובאתגר הזה, כדי שגיא והצוות יוכלו בעצם להסתכל על זה בצורה רוחבית הוליסטית ולראות איך אפשר לתרגם את זה מחר לאיזשהו פיצ'ר או שינוי בעצם במוצר. ואני רוצה גם להתייחס לנקודה של איראן ר שיש דברים שה-CS יכולים לפתור, שאני חושב שלפעמים זה סייניטיז ולפעמים דווקא לא, כי זה תלוי, יש דברים אופרטיביים שאין כרגע את הצורך להביא אותם לבשלות של ב ת להיות במוצר עצמו, כי זה דורש הרבה יותר מחשבה ורמת גימור הרבה יותר גבוהה, והם יכולים להישאר בצד האדמיניסטרטיבי שה-CS מטפלים, וזה בדיוק גם חלק מהקונפליקט של לאיזה רמה להביא את הפתרון שכרגע אנחנו צריכים. תן דוגמה למקרה שבו אתה ב ת חושב שעדיף… אז אני יכול להגיד שעשינו איזשהו פיצ'ר שהוא חלק מאיזשהו קומפליינס שהיינו צריכים, שלתת ללקוח את האפשרות שהוא סוגר את החשבון להוריד את כל המידע שלו, דאונלוד של כל הבורדים וכל האבדריטים לתוך אקסלים, שזה מין מחויבות רגולטורית שהייתה לנו לתת ללקוח, ולפי קצב הבקשות שכרגע ראינו את הדבר הזה קורה, החלטנו שזה כרגע מספיק טוב שזה יהיה אפילו ברמה של איזשהו סקריפט שנכתב ל-Day of the Day, אבל הוא השקיע בו מחשבה כדי לפתוח את זה, כי לפני זה לא ידענו איך לעשות את זה בכלל וזה לקח מלא מלא זמן, ו רנו לפי הקצב של הבקשות האלה אנחנו יכולים להעביר את זה שזה יהיה בצד של ה-CS, ואולי מתישהו נעשה את זה כפיצ'ר יתי שיהיה במערכת עצמה. כלומר היום כשמישהו רוצה להוריד את כל המידע, להעביר את כל המידע של כל האק נט שלו בעצם, אתה מתכוון ברמת האק נט? ברמת האק נט, כן. לאקסל, הוא כן נדרש לפתוח טיקקט ולהגיד, היי אני צריך לעשות כך וכך, אבל יש כבר כלים ה-CS לפתור את זה בעצמם, ובגלל הווליום של זה כרגע, אתה אומר, אין סיבה להשקיע בזה פרודקטית מחשבה. בדיוק, כן, כי זאת אומרת, ההבדל הוא שלפני זה הוא פתח את הטיקקט הזה, וזה לקח שבוע או שבוע וחצי, והיום הוא פתח את הטיקקט הזה וזה יקרה כנר באותו היום. וזה בדיוק ההבדל. ופה המורכבות של לעשות את זה במוצר עצמו, יש פה מורכבות הרבה יותר גדולה, והחלטנו שלא להיכנס עליה. וזה בדיוק העניין של המורכבות של לטפל בבעיה, מול כמה שזה, ה-value שזה נותן, ואני ושחר כל הזמן on it, ושחר, זה לא חייב להגיע ל-day of the day, כדי ששחר יתריע לי שיש דברים רפטטיביים שחוזרים ב-CS, והוא אומר, תשמע, בוא נמצא לזה איזשהו פתרון במוצר עצמו, כי צריך, ו… מי מקבל את ההחלטה הזאת? למשל בדוגמה שנתת על ה-export? במקרה הזה זה איזשהו feature שאני הובלתי, כי ב ת ראיתי את הצורך הזה, לא פיתחתי אותו בעצמי, אבל הייתי ככה מאוד מעורב בו, וזאת הייתה ההחלטה שלי שהדעתי ככה את האנשים הרלוונטיים, שהסכימו, וככה זה קרה. מתוך דאטה? שוב, מתוך זה שהגעת למסקנה? מתוך שאני יודע בדיוק כמה בקשות כאלה היו מאז שאנחנו תחת הרגולציה הזאת, ושזה לא דרש כרגע את ההשקעה הזאת לעשות את זה במוצר עצמו. הוא תמיד מסתכלים על שלושה פרמטרים, על ווליום, כמה בקשות כאלה יש, מה הפיין שזה גורם ליוזרים, ומה האפורט שיקח לנו בעצם לפתח את הפתרון. ולפעמים אנחנו מתפשרים על אחד הפרמטרים, זאת אומרת, אם אנחנו רואים שהאפורט הוא מאוד גבוה, אז אולי אנחנו נמצא איזשהו ווקרראונד שיפתור את האפורט. ואם אנחנו רואים שהווליום גבוה, אבל הפיין הוא נמוך, יכול להיות שאנחנו נפתור את זה כי כל כך הרבה אנשים נתקלים בזה, למרות שזה מפריע להם קצת, שהאפקט המצטבר של זה הוא מאוד מאוד משמעותי. אז מסתכלים על כל הפרמטרים האלה. הווין סטטט, יש לפעמים מקרי חירום, וזה גם מאוד מאוד מעניין. כי דיברנו פה המון המון על השגרה, אבל יש לפעמים מקרי חירום. שרת שנופל, אקאונט שאי אפשר לגשת אליו, דברים שהם מבחינתנו קוראים להם שורס טופר. שזה משהו שגם דאב אוף דה די מטפל בו? זה גם דאב אוף דה די מטפל פה, אבל פה ב ת יש יותר עניין של גם הרבה ככה הכשרה שאנחנו עושים לסייאס, של להבין מה זה שורס טופר, כי זה קל להגיד המערכת למטה זה שורס טופר ברור, אבל אולי אני לא יכול לעשות סיינאפ רק מאירופה. זה כן שורס טופר, אבל יש דברים שצריכים קצת יותר מחשבה של האם עכשיו צריך להטריע על כולם או לא, ובמידה וזה ב ת שורס טופר, או גם אם יש ספק, אין ספק, אם חושבים, לא בטוחים, אז מטרים. ואז הדאב אוף דה די ובדרך כלל כל הפיתוח עוצרים את כל מה שהם עושים, וכל מי שיכול להיות מעורב מעורב בזה, כדי לפתור את הקרייססים האלה כמה שיותר מהר. זה דווקא בהקשר הזה זה קל במרכאות, זאת אומרת, זה דברים שלא צריך פרוסס ולא צריך… יש וודאות לגבי מה צריך לעשות. כן, אין פרוסס, לא צריך פרוסס, לא צריך כלום, צריך שכולם יעשו את זה. כן, אבל מה שכן ייחודי כאן זה שיצרתם שפה משותפת עם הסייס כדי לוודא שכולם מבינים מתי מטרים ומתי לא. נכון. אחרת זה אב זאב, מה שנקרא. נכון, נכון, וזה רק חלק מהדברים, גם בערך אחת לריבון.

שמצגת שאני ושחר עושים לכל ה-CS, גם ה-CS גדלים, אולי המחלקה שגדלה עם האחוזים הכי גדולים פה בחברה, אז כל הזמן יש אנשים חדשים שצריכים לעבור את הטיינינג הזה של איזשהו אישור קו לגבי איך פותחים טיקטים בדייב דה דיי, מה הדברים שצריך לשאול את הלקוח לפני שהדברים האלה מועברים למפתח בגדול, כל הדברים שאיש ב-CS יכול לעשות בעצמו כדי לנסות לפתור את זה לפני שזה מועבר ללקוח, וחלק מזה גם זה כמובן מתי להטריע שזה תקלה חמורה, ואם זה גם צע הלילה, אז להעיר וכל מה שצריך לעשות כדי… כדי שזה יהיה אפשר לעשות כדי שאותו עובד יחידה לפתור את הבעיה. נכון, נכון. עשינו שיפור משמעותי בדבר הזה, זה עדיין אתגר מאוד מאוד גדול. בהתחלה, כמו שגיא תיאר את זה, אז זה נולד שוב מכאבים שבעצם אנשי CS נתקלו באיזושהי בעיה, לדוגמה ללקוח נעלמו בורדין. ממש דאטה נעלנו במערכת ואף אחד מה-R&D לא נתן איזה פתרון של שלושה ימים, ואז שגילינו את זה רנו, וואו, איך לא באתם, זה הדבר הכי חמור בעולם, לקוח איבד חלק מהדאטה שלו. ועשינו איזשהו אישור קו, אבל יש פתאום כל מיני אזורים כאלה שהם עדיין אפורים. יכול להיות שכל לקוח מאבד טיפה מידע, אבל יש פה איזושהי תופעה שרחבה, אוקיי? זה כאילו, לפעמים אנחנו צריכים להסתכל על מיני תופעות שקורות בתוך המערכת, שכל אחד בפני עצמה היא לא ביג דיל, אוקיי? זה משהו שאנחנו רואים, אוקיי, זה לא אירג'נט, אבל אם מישהו מסתכל על זה בצורה רוחבית, הוא אומר, רגע, יש לנו פה כנר איזשהו בג או משהו משפיע רוחבית על כל היוזרים. אז אחד מהדברים שאנחנו גם מנסים תמיד להגדיר ל-CS, והם גם עושים עבודה אצלם, שחר עושה את העבודה המקבילה של גיא בעצם ב-CS, לראות אם יש איזשהו מחנה משותף בין כל הטיקטים, כי לפעמים המכלול של הטיקטים בעצם מצייר איזושהי תמונה, שכל אחד בצורה אינדיבידואלית לא מצייר. אני רוצה לתת עוד איזושהי דוגמה קטנה לגבי מה שאירן ר. הנושא הזה שאני מתחלט את הסיפור הזה הוא ב ת נכון, כדי למצוא פרטנים כמו הריסייקל, ודיברנו על זה, אבל יש דברים בסקל הרבה יותר קטן שגם הם נפטרים על ידי הטורנים עצמם. זה איזשהו שינוי שעשינו שאני חושב שהוא מאוד מאוד עזר לנו, של להגדיר את הדייב דה דיי במהלך היום, שהוא לא מתעסק בשום דבר מהאיטרציה שלו בכל היום. זאת אומרת, הוא רק על טיקטים של דייב דה דיי, ואם אין כאלה, יצרנו איזשהו בקלוג מתוך בדרך כלל טיקטים של דייב דה דיי, של דברים קטנים במערכת שאפשר לעשות. ומה שזה גרם בעצם זה שכל המפתח מנסה לפתור בעיה כמה שיותר מהשורש. זה לא מעכשיו לפתח פיצ'ר שבועיים. וזהו ב ת, לראות פתאום יוזר שהוא בסטטוס מחוק, מופיע לו משהו מוזר בדאטה בייס. אז אפשר לתקן ליוזר הזה את הדבר הזה, להחזיר איזה חזרת פרמטר והכול יהיה סבבה. אפשר רגע לחשוב, ותגיד לי שלוב, זה ב ת מקרה שקרה לפני כמה ימים, שמצאנו איזושהי בעיה, ופתאום ראינו שיש חמש ת'לפים יוזרים שאנחנו בדאטה בייס, שיש להם איזשהו בעיה בנתונים, שמשהו שם לא מסתדר. מצאנו איזשהו בג, הוא לא היה חמור במיוחד, אבל מדובר על נתונים נכונים, זה מאוד מאוד חשוב. והקשב הזה זה מה שאפשר… בדיוק, והקשב של מי שהיה דייב דה דיי באותו יום, גרם לזה לקרות. ואני חד משמעית אומר לך שאותו סיפור שהיה קורה לפני חצי שנה, שנה, לא היה קורה ככה. היה מתנהל בקטע של, אוקיי, אני אפוך את זה באפס לאחד, ו שיך כאיתרציה לוחצת. וברגע שהגדרנו שזה יום שלם… ירד על הלחץ הזה. בדיוק, ושזה פוינט אוף קונטקט לכל המחלקות בחברה, המיינדסט פשוט התחלף. אז האחריות הזאת של דברים לא רפיטטיביים היא גם עליי, אבל היא גם על המפתחים עצמם שעושים את הטורנות הזאת. זאת אומרת, זה מחבר אותי לשאלה יותר גדולה, של איך בעצם מודדים את העבודה של הדייב דה דיי. כרגע אנחנו מודדים את כמות הטיקטים הממוצעת שנפתחת ביום, בחמישה הימים האחרונים. יש לנו מספר גדול על הדשבורד של הפיצוח. טיקטים ממי לרגע, של מי למה? בדייב דה דיי, בבורד של הדייב דה דיי, שהסי-אס פותחים לנו. קודם כל כדי להבין איפה אנחנו עומדים. זאת אומרת, ראינו איזשהו שיפור בתהליכים, ושהיחסים בין הסי-אס למפתחים הרבה יותר טובים, וזה אחלה. היה בא לנו משהו גם יותר מדיד שנוכל לעשות. והתחלנו למדוד את זה. כרגע מספר זה עומד על חמש. זאת אומרת, בממוצע ביום נפתחים חמישה טיקטים חדשים מהסי-אס לדייב דה דיי. מה אתה לומד מהמספר הזה? קודם כל אני לומד את המספר. זה הדבר הראשון שאני יודע, זה שיש את המספר, ועכשיו אני יכול לשאוף. השאיפה היא בגדול לאפס דייב דה דיי, כי כל דייב דה דיי הוא ב ת מעיד על איזשהו חוסר רובה מערכת, או בבק אופיס, או נולג' בייס, או הבנה, או משהו שהוא או בג, ואם הוא בג אז הוא צריך ללכת לבגים, שעליהם אולי נדבר קצת בסוף הפרק, אבל הם לא דברים אופרטיביים שנטפל מעכשיו לעכשיו. אז זה צריך לשאוף לאפס, אני לא יודע אם אנחנו ב ת נגיע לאפס, אבל זה צריך להיות לפחות, טכניק לי זה, אפס דברים שחוזרים על עצמם. רק דברים חדשים כל פעם צריכים להתווסף לשם, ולא דברים שאני כבר ראיתי וטיפלתי. ואת המדד הזה אתם מסמנים לכם?

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

אנחנו הופכים את הדבר הזה לחגיגה. באים בבוקר ומביאים מלא גבינות. מסריחות אבל גבינות. ומביאים קרקעים וכל מיני דברים טובים. ואני לא יודע אם מישהו שלא כתב קוד יכול להבין את זה, אבל אין דבר יותר מספק מלפתור את הדברים הקטנים האלה. זה חמש דקות, טק, ופתאום אתה רו את זה כל הזמן מולך, וזה משהו קטן שפתרת שאתה יודע ש… זה כמו הסדר את המגירה בבית שהפעם מגיעים אליה. בדיוק, בדיוק. ואז אתה מסתכל על הארון, אתה אומר, וואו, איזה כיף. אז המוצרים האלה, אז חטא הטלפון שפעם הוא עושה. והמוצר פתאום נר מיליון דולר. זה בדיוק הדברים האלה שפתאום המוצר נר מיליון דולר, וזה כאילו, איזה סיפוק. לכל מי שיש אום-CD זה הדבר הכי מספק שקיים בעולם. ו-To be honest, לא היינו מגיעים לזה בחיים. ואני חושב שבעיניי זה איזשהו סטייטמנט של החברה. כשאנחנו אומרים, חברה, זה חשוב. הדברים האלה, הפיקסל הזה, הוא חשוב, ואנחנו יכולים לקחת את הזמן ולהקדיש אותו, לעשות את הדברים האלה, כי הדיטיילס חשובים כמו המקו בעינינו. אני ממש מסכים, זה בעיקר פשוט מעלה את ה-awareness של הדבר הזה, שאחר כך אם אתה רו את הדבר הזה, אז אולי תפתור את זה בין משימה למשימה, בלי כזה להכניס את זה עכשיו לאיזה back-log או דברים ששוב, אף פעם לא נגיע אליהם. אז מדי פעם לעשות דבר כזה, כמו שאנה מרלצ'יז, אותו דבר לקואליטי. מין בגים קטנים כאלה שהם כאילו לא מספיק חשובים, אבל נורא מציקים ולוקח שנייה לפתור אותם. אז ליצור כאלה כשכל הפיתוח, 15 חבר'ה יום שלם זה כוח עבודה עצום, מתעסקים רק בדבר הזה, ובסוף מרים עשרות משימות שסיימנו באותו יום. זה ב ת ממש מספק, זה אחלה מוטיבציה, זה אחלה גיבוש, זה מעלה את ה-awareness, יש לזה כל כך הרבה דברים חיוביים. נוספים על זה, שזה ממש כיף. כל כמה זמן אנחנו עושים יום כזה? אז ה ת, זה לא איזשהו עניין מתודי, זה עניין של הרגשה ותחושה, וזה ב ת גם פה מגיע value שלי כמי שמתכלל את הדברים האלה בצד של הבאגים וה-day of the day ורו את זה, לצ'יזים ישנו אונרים אחרים גם, וזה שהיא החלטה שאנחנו מקבלים, שאנחנו אומרים, אוקיי, בואו שתי התארציות, נעשה יום כזה, מרגיש שמתחיל להצטבר, הטונוס קצת יורד, כל מיני דברים כאלה, אז אני אף כך מאוד מאוד אוהב את זה שזה בא מההרגשה ומאכפתיות ולא מכזה כל חודשיים, טוב, הגיע הזמן, רוצים, לא רוצים, זה נר הרבה פחות כאילו יתי וכואב מאשר כאילו לעשות את זה. ואז יש התלהבות גם אותנטית כשזה ככה קורה בצורה מחוברת לנציאות. בפועל הייתי אומרת שזה קורה אחת לרבעון, give or take, אבל ב ת לא בודקים מתי היה אחרון כדי לקבוע את הבא, זה עניין של, וזה הרבה פעמים גם ב ת בשינויים, אם עכשיו עשינו קפיצה מטורפת בפרודקט, כמו בחודשים האחרונים, אז מן הסתם שכמות ה-cheesing וה-bugging וה-day of the day עולה, כי זה כל מיני ריקושט עם מהדברים האלה, אז צריך יותר בדחיפות לעשות. אם זו תקופה שמתעסקים יותר בתשתיות, אז יש פחות כאלה, אז זה מאוד מאוד נזיל וחלק מהכיף. מה עדיין מאתגר? אז בנושא הזה של ה-day of the day, מה שעדיין מאתגר זה שעם כל הדברים המ ת טובים שעשינו, אנחנו עדיין לא מצליחים להוריד את זה לרמה כזאת שזה שקוף, זאת אומרת כמו שהיינו רוצים, ואני חושב שהרבה מה… שקוף למי? לא הבנתי. שזה יהיה, זאת אומרת שזה כמעט לא ידרוש זמן מפתח, זאת אומרת אם ה-KPI שלנו נגיע ל-0 day of the day, זה אומר שמפתח 0 זמן מההתארציה שלו, מתעסק בדברים של day of the day, ואנחנו עוד לא שם, ואנחנו ב ת די רחוקים משם, ולפעמים אפילו למפות את האתגרים זה נורא קשה, בגלל שב-day of the day זה כל הזמן דברים חדשים, הם נם אחר כך חוזרים על עצמם, אבל זה דברים חדשים שחוזרים על עצמם, אז למצוא את הפאטרנים האלה זו עבודה שכל הזמן צריך לעשות. אני חושב שיש לנו עוד כברה דרך לעשות בצד של ה-CS בהכשרות, בעיקר בגלל הגדילה המאוד מאוד משמעותית שם, וגם הכשרות בצד של הפיתוח שאנחנו צריכים לעשות, כדי למנוע כמה שיותר את הפינג פונג, אולי נגיד על זה מילה, יש פינג פונג, בעצם אם עכשיו בגאפון סקסס פתחו טיקט, ואני עכשיו די אוף דה די ואני קורא את זה, וחסר לי מידע, אז אני מעביר את הטיקט חזרה ל-CS ואני אומר, תשיגו לי בבקשה את א' ב' ג', ואז הם מחזירים את זה חזרה. כל פעם שקורה כזה פינג פונג, לא יודע, זה בערך ב-20% מוריד את הסיכוי שהדבר הזה ייפטר, כי עובר זמן וזה כבר לא משתחזר, ולאף אחד לא אכפת. ואז זה עובר עד די אוף דה די של היום, של היום, של הקחת קונטקסט מחדש. וזה בגדול רע מאוד. אגב, זה ממש בעייתי. זה ממש בעייתי, זה כנר הדבר הבא שאנחנו נתחיל למדוד גם, כמה פעמים בממוצע הטיקט עובר ידיים, נקרא לזה ככה. כי אם יש משהו שהוא יותר לא יעיל מזה שאדם אחד יפתור את זה במשך כל היום, זה ששני אנשים יצטרכו להתעסק בבעיה כזאת. בדיוק, ואז לקרוא פרד מלא הודעות זה, ולהיכנס לקונטקסט ודברים כאלה. גם הנושא הזה אנחנו עשינו איזשהו שינוי, ש רנו שאם מישהו מתחיל לטפל בטיקט, הוא יסיים לטפל בו גם אם הוא לא. אם הוא קיבל עליו אונגשיפ, גם אם הוא כבר לא די אוף דה די. כן, ואם צריך, תכניס להתארציה, נסה את הידיו, זאת אומרת, ולא עכשיו. ואז ב ת…

אז ב ת הזה שאנחנו מנסים למדוד את זה ולהבין כמה פעמים פינג פונג בממוצע כזה קורה לטיקט, וכדי למנוע את הפינג פונג הזה, שאני חושב שזה אחד מהדברים הכי כואבים שעדיין נשארו לנו, זה ב ת בהכשרות של הקסטומוסקסס מצד אחד, ובשינוי קצת מיינדסט של המפתחים מצד שני, שגם מהצד של הפיתוח, לעשות כל מה שאפשר כדי לנסות לפתור את זה. זאת אומרת, אולי חסר לי איזשהו פרט מידע, אבל אם יש מצב שאני יכול להשיג את הפרט מידע הזה בעצמי מהדאטאבייס, או להסתדר בי לדעת רק להגדיל ראש, או לעשות את המקסימום, מקסימום, מקסימום שאני יכול, כדי שאם אני כבר מחזיר וזה יחזור אליי חזרה, אני כבר בטוח אז אדע לפתור את הדבר הזה. אז ב ת זה שנתנים פינג פונג ונסות למזהר אותו משני הכיוונים, הוא אתגר מאוד מאוד רציני, שאני חושב שברגע שאנחנו נוריד אותו, יהיה לו יחס ישיר לכמות הטיקטים שנפתחים גם, ולאיכות שבה אנחנו פותרים אותה. בעיניי אתגר מאוד גדול הוא איך עושים את זה סקייל, ואני לא מדבר על איך מספיק מפתחים עונים על דיו-אוף-די-די, אלא איך עושים דווקא סקייל בבני אדם. כי ככל שאנחנו גדלים בקסטומוסקסס מגיעים עוד אנשים, ופתאום ההגדרות מתשתשות של מה זה באג, מה זה צ'יז, אולי לאנשים שונים יש סטנדרטים שונים, אנחנו, אני מאוד בגישה של להתקדק מאוד בפרטים והכל מאוד מאוד חשוב, אבל יכול להיות שמישהו שהיום מגיע בסי, זאת אומרת, טוב יש לו פה כמה לקוחות בעיה, אבל אני לא אטריד עכשיו את דיו-אוף-די-די, כי אני יכול לפתור את זה בעצמי. אז איך מייצרים את האדז'וקיישן הזה? אגב גם אצל המפתחים, זאת אומרת יכול להיות שמפתח מקבל דיו-אוף-די-די, ואז הוא יכול להחזיר לסי-אס, תקשיבו זה לא בעיה, זה ככה מאז ומתמיד ובוא לא נפתור את זה. אז איך עושים סקייל, ה-state of mind? איך עושים סקייל? לרגישות. לרגישות, להבנה של מה כן צריך לפתור, מה לא צריך לפתור, מה צריך לעקור מהשורש, את התפיסה שלנו? אני מרגיש ששם אנחנו עדיין צריכים לפתור את זה עד הסוף, בלתת דוגמאות ולהבין איך אפשר לפתור דברים, איך להסתכל על הדברים בפרספקטיבות שונות, זה מה שאני מבין, אני לא יודע אם היום כולם וכולל אנשים שעכשיו הצטרפו לארגון מסתכלים עליו באותו אופן. אני ממש ממש מסכים עם זה, וזה ב ת עניין של מישהו התלונן שמשהו קורה, זה עובר לדב-די-די, הדב-די-די אומר, זה לא משתכזר לי, אז ברור שאני לא מחזיר את זה עכשיו ל-CS, לי זה ברור, אני רוצה שזה יהיה ברור גם לכולם, כי אם הלקוח התלונן, קרה לו, וכמו שאירן ר לפני, על אחד שמתלונן יש 15 שלא התלוננו, אז זה משהו שקרה, אם הוא כבר דיווח לנו, זה משהו שקרה. אז אולי יש תנאים מסוימים, אולי אפשר להוסיף כל מיני דברים, זה שהם יותר מידע במערכת כדי שאנחנו נדע פעם הב שזה קורה, זה גם פתרון לגיטימי לבוא ולהגיד, אוקיי, הוספנו יותר מידע עכשיו במערכת, פעם הב שזה יקרה, אנחנו נדע למה. זה גם פתרון, אבל העניין לתת איזושהי התקדמות ולפתור משהו במקסימום שאנחנו יכולים באותו רגע. אפילו אם זה לא באג, הוא כנר לא הבין משהו. זה עדיין האחריות היא עלינו. זאת אומרת, זה לא עניין של באג או לא באג, זה עניין של מה הוביל אותו למקום הזה שהוא טרח כל כך לפתוח טיקטים בשבילו. כן, וכמו שגם רנו קודם, זה ירה טובה ב ת ככה לסיים את הפרק, שבסוף זה לא בעיה של ה-CS וזה לא בעיה של המפתחים, זה בעיה של החברה כולה. זה ב ת ככה לסיום, אם יש כמה טיפים שאתה יכול לתת למישהו שמתחיל לתכלל את הדבר הזה בדיוק כמוך בפעם הראשונה בארגון. אז נתחיל בסיסמה שאין קיצורי דרך, אבל בואו רגע נדבר קצת יותר. אז למדוד, הדבר הראשון זה למדוד ולמדוד מההתחלה, כי ברגע שיש מספר מול העיניים, יודעים אם מה צריך להתמודד. אולי המצב הרבה יותר טוב ממה שאנחנו יודעים, אולי המצב הרבה יותר רע ממה שאנחנו חושבים. אז מציאות מול הפנים זה הצעד הראשון בלהבין מה האתגר שאנחנו עובדים איתו. זה הדבר הראשון. הדבר השני, דיברנו על זה קצת שהתפקיד הזה של המפתח תורן, הקלאסי הוא תפקיד די מבאס, בואו נדע על ה ת. ואני חושב שזה אתגר מאוד מאוד רציני להפוך אותו לתפקיד עם אימפקט כמו כל הדברים שאנחנו מנסים לעשות. אני חושב שכל הדברים שדיברנו עליהם, תחיית הפרק עם המדד וה-KPI ולהוריד את זה ולחקור דברים מהשורש ולפתור אותם בפרודקט וכל הדברים האלה, בעצם הופכים לזה שבן אדם מסיים את ה-day of the day. אני לא אגיד שזה היה יותר כיף מלעבוד על הפיצ'ר באיטרציה, בואו לא נגזים, אבל הוא מסיים מזה שהוא ר, אני השארתי את ה-day of the day יותר טוב ממה שקיבלתי אותו היום בבוקר ולא רק עשיתי את אותו מאותו דבר. ואני חושב שזה ההבדל מאוד מאוד מהותי באיך שכולנו ניגשים לזה. ושוב, יש עוד הרבה מה לשפר, גם עם כל הדברים שאנחנו עושים, אבל אני חושב שזה הנקודות המרכזיות שהייתי נותן למי שמתחיל עם זה, זה למדוד ולעשות את התפקיד הזה אפקטיבי. אני חושב שיזם או כמישהו שמנהל פיתוח, מאוד קשה לבוא ולהגיד, חבר'ה עוצרים הכל, בואו נשפר את האיכות, חבר'ה אני מקריב מפתח פעם בשבוע, לעשות את התיקונים. תמיד קל לברוח למקומות של בואו נעשה עוד פיצ'ר, בואו נתקדם, בואו נייצר אימפקט. ובעיניי האימפקט של זה הוא אדיר. העובדה שאיכפת לנו מה…

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