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

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

Guy Asinovsky, a developer at monday.com, joined us this week to talk about the role of Dev of the Day.

We talk about the challenges that led to its inception. What is the importance of establishing a framework for collaboration between the CS and R&D teams, Ther criteria we take into consideration when assessing the importance of a task in this context, and why cracking this has an impact on a company level.

Episode transcript

Automatically transcribed — it may contain errors.

היי ערן. היי ליאור. היי כולם. הגעתם לסטארט-אפ פור סטארט-אפ, הפודקאסט שבו אנחנו חולקים מהניסיון, מהידע והתובנות שיש לנו כאן במאנדי.קום, וגם מחברות אחרות, ומיועד לכל מי שסטארט-אפ מדבר עליו, לא משנה באיזה כיסא הוא יושב ברגעים אלו. סטארט-אפ פור סטארט-אפ. אז היום אנחנו נדבר על קונספט שאנחנו בחברה קוראים לו דב אוב דה די, ובצורה מסורתית ומבאסת קוראים לו המפתח התורן, והמטרה של הפרק הזה היא בעצם להסדיר מה מתחלל התפקיד הזה בתוך החברה אצלנו, איך הגענו לתובנה שזו דרך שאפשר לפתור בדברים, ואיך עושים לזה סקל. עכשיו, זה שאלות שכרגע נשמעות מאוד ומות, אבל תישארו איתי, מבטיחה שהולכות מעניין. ולטובה לעניין הצטרף אלינו היום גיא הסינובסקי, שהוא מפתח בחברה כבר שנה וחצי, ויש לו גם תפקיד ייחודי סביב הנושא הזה של דב אוב דה די, נכון גיא? כן. היי ליאור, היי ערן. היי גיא. היי גיא. אז ב ת בנוסף לתפקידי כמפתח באחד הצוותים בארנדי, יש לי אחריות שהיא כוללת בארנדי של הקווילטי והדב אוב דה די, שעוד שנייה ב ת נסביר מה זה. זה בכלל איזשהו מהלך שאנחנו אוהבים לעשות בארנדי, לתת רשימת תפקידים ייחודיים לאנשים שמשפיעים על כלל הארנדי, ולפעמים אפילו על כלל החברה. אתה לא יושב כאן כי אתה הדב אוב דה די התמידי? לא, ספציפית היום ב ת אני כן דב אוב דה די, אבל אני לא התמידי. איך זה יכול להיות שאתה יושב בחדר סגור עם פלאפון סגור ואתה דב אוב דה די? איך זה מתכנס? זה מתכנס דאגתי מבעוד מועד שהחליפו אותי לשעתיים הקרובות במקרה שיש בעיות. זה אחריות. אז ב ת שנייה כדי שנוכל להבין מה התפקיד של דב אוב דה די במאנדיי, בואו נבין רגע מה הייתה הבעיה שזה בא לפתור. זרן את הקונטקסט הזה תיתן לנו אתה אולי? בכיף. זה משהו שנתקלנו בו בתחילת החברה, אני חושב שכל חברה תוכנה עוברת דרך התהליך הזה, של איך מחברים בין הקסטמר סקסס לארנדי. יש המון המון פידבקים שמגיעים מלקוחות כל הזמן, במיוחד תוכנה שיש לה שימוש יומיומי, על באגים, אפילו לא באגים, אפילו אנשים שעשו איזושהי פעולה בטעות ורוצים לשנות משהו, לשחזר איזשהו משהו, איזשהו יוסקייס ספציפי שהם לא מבינים למה זה קרה להם ככה ולא אחרת, והסי-אס לא תמיד יכול לענות. לפעמים הוא צריך או מפתח שיבדוק את הבאג, או מפתח שיעשה משהו בדאטאבס בשביל לעזור ללקוח. ומה שהיה לנו בעבר שהיה מאוד מתעסקל זה שאנשי הסי-אס מצד אחד שמו להם יעד של לענות מאוד מאוד מהר לטיקטים, אז הם הגיעו בריצה לארנדי, וארנדי, רגע מה אתם רוצים? אני ב צע ישיבה, מה אתם רוצים? אנחנו ב צע פיצ'ר, קונטקסט סוויץ' אינק תמידי, שום פריוריטיזציה בין עיקר לטפל, אולי שעכשיו באג שאף אחד לא מצליח להיכנס למערכת, אולי זה רק באג שקורה ליוזר אחד מתוך אלף, זה עצר המון המון בעיות. גם עוד בעיה שקרתה לנו זה שכל פעם באו לאותו בן אדם, כאילו היה איזשהו go-to person בארנדי ופשוט לא הצליח לעבוד, וכל השאר פשוט ככה קרה שפחות באו אליהם, ו רנו צהוב, אי אפשר להמשיך ככה, זה לא סקלבל. כן, שוב זה גם ככה אתה מציג את התסכול של המפתח שפונים אליו, אבל אני יכולה לדמיין איך נציג ב-CS לא יכול לתת את המענה האיכותי בלי ב ת לעבור דרך איזשהו מפתח. לגמרי, אז זה לגמרי, כי מצד אחד אנחנו… זה חוסר פייליור מה שתיארת כאן. כן, אנחנו דוחפים אותם לענות מהר ולענות איכותי, הם לא רוצים סתם לתת תשובה ללקוח שהיא לא יתית, שאין לה ביסוס במציאות. לפעמים גם בעצמם מזדהים עם הלקוח אולי ואומרים, וואי יש פה בעיה שב ת כבר צריך לתת לה מענה יתי בתוך הפלטפורמה. לגמרי. ואולי אם גם נגיד אותה מלא פעמים אז משהו ישתנה מהותית. כן, אבל לא היה את האינטרפייס הזה, זאת אומרת לא היה את המתודולוגיה ואת התהליכים בשביל לתמוך בדבר הזה, זה היה מאוד מאוד ראנדומלי. ואז נכנס הפונקציה של ה-Dev of the Day. אז גיא תספר לנו רגע איך זה נר היום. אז בעצם היום זה תורנות של 24 שעות, שווירת בין כל המפתחים, היום זה כבר לא מפתח אחד, יש בערך 20 שעושים את התורנות הזאת. ובעצם זה תפקיד שיש לו כמה קובעים. קובע אחד זה ב ת הקטע הקלאסי הזה של מפתח תורן, זה להיות זמין עם הלפטופ, תקלות, הטלפון מצלצל, כל מיני דברים כאלה. אנחנו פחות נתמקד בזה. ניתן לדבר על מה קורה במהלך היום, וגם איך כולם יודעים עם מי לדבר. אז נגיד ה-Dev of the Day עכשיו הוא נמצא על דשבורד, הדשבורד העיקרי שלנו, כל יום יש שם את השם, הקפסות סקסס יודעים עם מי לדבר ולמי לפנות במידה ויש… כל החברה יודעת. כל החברה יודעת, ובעיקר כמובן ה-CSM אלה שככה בממשק מול ה-Dev of the Day. כן, אבל לקחת את זה אפילו לרמה יותר בסיסית שאם עכשיו מישהו לא יודע מי ה-Dev of the Day, אז הוא יכול לשאול וכל אחד אחר ידע לענות על זה. לא צריך לחפש את האדם שיודע מי ה-Dev of the Day. אבל ב ת ככל שגם ב ת החברה גדלה…

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

אני יכולה להגיד שעשינו איזשהו פיצ'ר שהוא חלק מאיזשהו…

האנשי CS נתקלו באיזושהי בעיה, לדוגמה ללקוח נעלמו בורדים. ממש דאטה נעלנו מערכת, ו…

ועכשיו אנחנו בדיוק הולכים את זה לשלב הבא. כי אחד הדברים שהבנו הוא שיש את הדברים שה-CS יודעים לקטלג אותם.

בעיות או שהם לא יכולים לפתור אבל וממש ניהלתי את השיחה עם תום לפני שבועיים ש רנו אוקיי אבל עדיין נפתחים המון המון טיקטים ליוזרים ביום הראשון שלהם במערכת אוקיי יש עדיין פערים שהם לאו דווקא באגים או דברים שצריך לשלוח לרנדי אבל הם בעיות ומה שאנחנו עכשיו עושים אנחנו ממפים בעצם את כל הטיקטים שקורים ביום הראשון או ביום השני ליוזרים כי גם אם זה לא באגים פרסי או דברים שלא ברורים יש שם כל מיני דברים שלא ברורים לגבי המוצר יש שם כל מיני דברים שלא ברורים לגבי הפרייסינג יש שם כל מיני דברים שלא ברורים לגבי איך להזמין יוזרים והתחלנו למפות את זה ו רנו רגע אלה בעצם באגים או בעיות בפרודקט שהם לאו דווקא בא היוזר ואומר יש לכם בעיה בפרודקט אוקיי הוא שואל איזו שאלה משהו לא ברור לו בתהליכים ביוזר אקספיריינס באיך הוא עושה משהו וזה פריקשן ובעינינו פריקשן זה משהו שהפרודקט ור לפתור אותו אז זה עוד אינפוט שהוא לאו דווקא עכשיו איזושהי שריפה שצריך לחבות אבל הוא אינפוט מה-CX שמשפיע גם על ה-R&D ושוב אלה דברים שאנחנו בחיים לא היינו מכניסים לרודמפ אם היינו צריכים לחזות אותם או להגיד שהם יעשו אימפקט אבל האימפקט שם הוא אדיר אם אנחנו נצליח להוריד את אותם חמשת הדברים שמייצרים פריקשן ביום הראשון או השני אין לי ספק בכלל שתהיה עלייה בקונברז'ן שאנשים ידעו איך שמשל תוכנה יותר טוב ושהצ'אר נר אחרת לגמרי אז זו דוגמה לאיך לקחת אינפוט שהוא רך שהוא שאלות של אנשים דברים שנר להם לגיטימי לשאול ולהפוך אותו לאקשן אייטם בעצם בתוך הפרודקט עצמו איזה עוד מתודת יש לנו חוץ מה-Dev of the Day כדי ב ת לתת מענה לדברים שעולים מתוך ה-CX אז אחד הדברים שאפשר לעשות ב ת בצורה קצת יותר יזומה זה ימים מרוכזים יכול להיות ימים מרוכזים של קוואליטי של כאלה בגים או ב ת דברים שבאים מה-Dev of the Day שהם בדיוק על הטפר הזה שדיברנו על איך פותרים את הקונפליקט הם לא מספיק חשובים כדי להיכנס לאיטרציה עכשיו והם כן כואבים קצת והם לא ברמת ה-Dev of the Day למה? הם יכולים להיות ברמת ה-Dev of the Day אבל לפעמים פשוט יש יותר מדי מהם ואז לא רוצים להשביט מישהו שלם ולימים כאלה מרוכזים זה יש גם תופעות לוואי מדהימות אחרות כל הפיתוח עובד על משהו אחד על מלא משימות קטנות שאתה עושה תופעות לוואי זה דבר רע אתה מתכוון להגיד שיש לזה עוד אימפקט עוד אימפקט סליחה יש לזה מלא אימפקט של כל הפיתוח עובדים ביחד עובדים על דברים ככה קטנים שיש פתאום איזה עשר משימות ביום שאני עושה עליהם דן ותסביר לנו רגע מה זה הימים המרוכזים האלה זה בעצם ימים מרוכזים שאנחנו מחליטים שביום הזה אנחנו עושים הפסקה מאיטרציה וכולם מטפלים באיזה נושא אחד זה יכול להיות קוואליטי כלומר בגים זה יכול להיות צ'יז דייז צ'יז דייז זה מין בין בגים לפיצ'רים קטנים שכל הזמן מבחרים לנו ואין לו מתי לפתור שאנחנו לא שמים באיטרציות מצ'יז זה גבינה פעם אחרונה שבדקתי נכון אז אנחנו קוראים משתמשים במילה גבינה אני אסביר ה ת שהקרדיט פה מגיע לרועי הוא יום אחד בא אליי ו ר לי תקשיב יש איזשהו בלוק פוסט שקראתי מבליזארד מי שלא מכיר את זה היצרנית המשחקים הכי גדולה בעולם שדיברו שם על צ'יז והוא ר לי צ'יז זה בעצם הלכלוך הזה שיש בין האצבעות והרגליים רתי איך זה מגעיל אבל הוא ר לי תקשיב זה גאוני והבנתי את זה בדיוק הדברים האלה שהם לא בגים אתה מסתכל על זה ונר לך כמו ככה המורה יואי להיראות אבל זה הפיקסל הזה שלא יושב בדיוק וזה הכפתור שהוא לא בדיוק בגודל וזה משהו שעולה על משהו אחר וזה משהו שאף פעם לא תתפנה אליו אבל הוא כל מה מציח הבין זה כזה דופק לאנשים כי תמיד אני חשבתי שהבורד הזה שנקרא צ'יזס זה כאילו גבינה אבל זה הקטע אז מה שאנחנו בפרשנות אחרת שקשה לי לפתר ממנה אנחנו בצ'יז די אוקיי זה בשביל לזה זה מה שאנחנו עושים אנחנו באים בבוקר ואנחנו הופכים את הדבר הזה לחגיגה באים בבוקר ומביאים מלא גבינות מסריחות אבל גבינות ומביאים קרקרים וכאילו מלא דברים טובים ואני לא יודע אם מישהו שלא כתב קוד יכול להבין את זה אבל אין דבר יותר מספק מלפתור את הדברים הקטנים האלה זה חמש דקות ופתאום אתה רו את זה כל הזמן מולך וזה משהו קטן שפתרת שאתה יודע שאתה כמו הסדרתם גירס בבית שאף פעם לא מגיעים אליה בדיוק ואז אתה מסתכל על הארון ואתה אומר וואו איזה כיף זה היה סוף סוף עשיתי זה והתהליך הזה זה כאילו המוצר פתאום נר מיליון דולר זה כאילו בדיוק הדברים האלה שפתאום המוצר נר מיליון דולר וזה כאילו איזה סיפוק לכל מי שיש אוו סידי זה כאילו הדבר הכי מספק שקיים בעולם וטו בי אונסט לא היינו מגיעים לזה בחיים ואני חושב שבעיניי זה איזה שהוא סטייטמנט של החברה שאנחנו אומרים חבר'ה זה חשוב הדברים האלה הפיקסל הזה הוא חשוב ואנחנו יכולים לקחת את הזמן ולהקדיש אותו לעשות את הדברים האלה כי

הדיטס חשובים כמו המקו בעינינו. אני ממש ממש מסכים וזה בקאפ שמעלה את ה-awareness של הדבר הזה, שאחר כך אם אתה רו את הדבר הזה, אז אולי תיצור את זה בין משימה למשימה, בלי כזה להכניס את זה עכשיו לאיזה בקלוג או דברים ששוב, אף פעם לא נגיע אליהם. אז מדי פעם דבר כזה, כמו שאנה רת, זה אותו דבר לקואליטי. מין בגים קטנים כאלה שהם כאילו לא מספיק חשובים, אבל נורא מציקים ולוקח שנייה לפתור אותם. אז לצפור כאלה כשכל הפיתוח, 15 חבר'ה, יום שלם, זה כוח עבודה עצום, מתעסקים רק בדבר הזה, ובסוף מראים עשרות משימות שסיימנו באותו יום, זה ב ת ממש מספק, זה אחלה מוטיבציה, זה אחלה גיבוש, זה מלא את ה-awareness של זה כל כך הרבה דברים חיוביים. נוספים על זה שזה ממש כיף. כל כמה זמן אנחנו עושים יום כזה? אז ה ת זה לא עניין מתודי, זה עניין של הרגשה ותחושה, וזה ב ת גם פה מגיע ה-value שלי כמישהו שמתחלט את הדברים האלה בצד של הבגים וה-day of the day ורו את זה, לצ'יזים יש לנו אונרים אחרים גם, וזו שהיא החלטה שאנחנו מקבלים, שאנחנו אומרים אוקיי, בואו שתי התארציות, נעשה יום כזה, מרגיש שמתחיל להצטבר, הטונוס קצת יורד, כל מיני דברים כאלה, אז אני אף פעם מאוד מאוד אוהב את זה שזה בא מהרגשה ומאכפתיות, ולא מכזה כל חודשיים, טוב הגיע הזמן, רוצים, לא רוצים, זה נר הרבה פחות יתי וכואב מאשר לעשות את זה. ואז יש את להבות גם אותנטית כשזה ככה קורה בצורה מחוברת למציאות. בפועל הייתי אומר שזה קורה אחת לרבעון, אבל ב ת לא בודקים מתי היה אחרון כדי לקבוע את הבא, זה עניין של, וזה הרבה פעמים גם ב ת בשינויים, אם עכשיו עשינו קפיצה מטורפת בפרודקט, כמו בחודשים האחרונים, אז מן הסתם שכמות הצ'יזים והבגים וה-day of the day עולה, כי זה כל מיני ריקושטים מהדברים האלה, אז צריך יותר בתחיפות לעשות. אם זו תקופה שמתעסקים יותר בתשתיות, אז יש פחות כאלה. אז זה מאוד מאוד נזיל וחלק מהכיף. מה עדיין מאתגר? אז בנושא הזה של ה-day of the day, מה שעדיין מאתגר זה שעם כל הדברים הב ת טובים שעשינו, אנחנו עדיין לא מצליחים להוריד את זה לרמה כזאת שזה שקוף, זאת אומרת, כמו שהיינו רוצים. ואני חושב שהרבה מה… שקוף למי? לא הבנתי. שזה יהיה, זאת אומרת, שזה כמעט לא ידרוש זמן מפתח. זאת אומרת, אם ה-KPI שלנו נגיע ל-0 day of the day, זה אומר שמפתח, 0 זמן מהאיטרציה שלו מתעסק בדברים של day of the day. ואנחנו עוד לא שם, ואנחנו ב ת דרך רוחוקים משם. ולפעמים אפילו למפות את האתגרים זה נורא קשה, בגלל שב-day of the day זה כל הזמן דברים חדשים. הם אומנם אחר כך חוזרים על עצמם, אבל זה דברים חדשים שחוזרים על עצמם. אז למצוא את הפאטרנים האלה זה עבודה שכל הזמן צריך לעשות. אני חושב שיש לנו עוד קברת דרך לעשות בצד של ה-CES בהכשרות, בעיקר בגלל הגדילה המאוד מאוד משמעותית שם, וגם הכשרות בצד של הפיתוח שאנחנו צריכים לעשות, כדי למנוע כמה שיותר את הפינג פונג, אולי נגיד על זה מילה, יש פינג פונג בעצם, אם עכשיו בקו פנסה קצת מפתחו טיקט, ואני עכשיו day of the day ואני קורא את זה, וחסר לי מידע. אז אני מעביר את הטיקט חזרה ל-CES ואני אומר, תשיגו לי בבקשה את א' ב' ג', ואז הם מחזירים את זה חזרה. כל פעם שקורה כזה פינג פונג, לא יודע, זה בערך ב-20% מוריד את הסיכוי שהדבר הזה ייפטר, כי עובר זמן וזה כבר לא משתחזר, ולאף אחד לא אכפת. ואז זה עובר ה-day of the day של היום, שעבר, ואז זה לעשות את זה מחדש. ולוקחת קונטקסט. כן, וזה בגדול רע מאוד. אגב… וואו, זה ממש בעייתי. זה ממש בעייתי, זה כנר הדבר הבא שאנחנו נתחיל למדוד גם, כמה פעמים בממוצע טיקט עובר ידיים, נקרא לזה ככה. כי אם יש משהו שיותר לא יעיל מזה שאדם אחד יפתור את זה במשך כל היום, זה שלשני אנשים יצטרכו להתעסק עם בעיה כזאת. בדיוק, ואז לקרוא ת'רד מלא הודעות, זה, ולהיכנס לקונטקסט ודברים כאלה. גם הנושא הזה, אנחנו עשינו איזשהו שינוי, ש רנו שאם מישהו מתחיל לטפל בטיקט, הוא יסיים לטפל בו גם אם הוא לא… זאת אומרת, עברו ownership גם אם כבר לא היום of the day. כן, ואם צריך, תכניסי לאיטרציה, נעשה את הדיעדוף, זאת אומרת, כמה ש… ולא עכשיו ב ת לזרוק את זה, ככה גם ב ת אתה יודע שזה שלך, לא משנה, גם אם היום יעבור, אתה תצטרך להתמודד עם זה. אז ב ת זה שינוי אחד שעשינו, שינוי שני זה ב ת זה שאנחנו צריכים למדוד את זה, ולהבין כמה פעמים פינג פונג בממוצע כזה קורה לטיקט, וכדי למנוע את הפינג פונג הזה, שאני חושב שזה אחד מהדברים הכי כואבים שעודד נשארו לנו, זה ב ת בהכשרות של הקסטומוסקסס מצד אחד, ובשינוי קצת מיינדסט של המפתחים מצד שני, שגם מהצד של הפיתוח לעשות כל מה שאפשר, כדי לנסות לפתור את זה. זאת אומרת, אולי חסר לי איזשהו פרט מידע, אבל אם יש מצב שאני יכול להשיג את הפרט מידע הזה בעצמי מהדאטאבייס, או להגדיל ראש שם ולקחת את ה… ולהגדיל ראש ולעשות את המקסימום, מקסימום, מקסימום שאני יכול, כדי שאם אני כבר מחזיר וזה יחזור אליי חזרה, אני כבר בטוח אז ידע לפתור את הדבר הזה. אז הקטע הזה של הפינג פונג ולנסות למזהר אותו משני הכיוונים, הוא אתגר מאוד מאוד רציני, שאני חושב שברגע שאנחנו נוריד אותו, יהיה לו יחס ישיר לכמות הטיקטים שנפתחים גם.

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

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