בקצרה: ככל שהמוצר שלנו גדל והתמיכה הטכנית של צוותי הפיתוח גדלה, נדרשנו לשפר את ניהול התמיכה הטכנית של צוותי הפיתוח. התחלנו ממקום שבו אנשים היו פונים ישירות לאנשים שנמצאים במשמרת הטכנית, עברנו לריכוז ערוצי התקשורת והתקדמנו לאחרונה לדרך אחודה של כל הפניות הטכניות שמאפשרות בקרה ריכוזית והזדמנויות לייעול.
בהרחבה:
כמו כל חברה אחרת, המוצר שלנו דורש די הרבה תחזוקה ופתרון בעיות המגיעות מהלקוחות שדורשות התערבות של צוותי הפיתוח. בהתחלה כל הבעיות מגיעות ישירות לפיתוח ולאורך הזמן מקימים את Tier 1 ולאחריו גם את Tier 2 אשר אמורים לפתור ולעצור בדרך אחוז ניכר מהבעיות ולהוריד את העומס מצוותי הפיתוח על מנת שיתרכזו בפיתוח המוצר. אבל איך משפרים את העבודה של המשמרות הטכניות? איך מקטינים את העומס? איך מוודאים שהם עובדים על הדברים הנכונים? מתחילים בשקיפות.
מאיפה יצאנו לדרך? כל אחד מספק תמיכה בהודעות אישיות
בעבר, כל צוות הנגיש את התמיכה הטכנית שלו לצוות התמיכה בעזרת בוטים של סלאק. יש לך בעיה? אין בעיה, יש בוט שבו אתה מברר מי האדם הרלוונטי במשמרת שאתה צריך, הודעת סלאק מהירה ובזאת פתרנו את הבעיה. אבל מה? לא היה תיעוד מתמשך לבעיות, כאשר איש המשמרת היה מתחלף, הוא היה צריך להעביר את כל ההודעות האישיות על התקלה למשמרת הבאה וכו’. השיטה התאימה כשהיינו חברה קטנה אבל ברור שככל שהחברה גדלה, אנחנו צריכים שיטה שתאפשר לנו לגדול.
איך מתחילים? העברת כל התקשורת לפרויקטי ג’ירה וריכוז ערוץ התקשורת לסלאק אחד
לפני כשנה, עשינו צעד ראשון בעניין: כל המשמרות עברו לעבוד בפרויקט ג’ירה, וכל הבוטים שהפנו לאיש המשמרת רוכזו בסלאק בוט אחד. לכך הוספנו עמודי מידע בקונפלואנס שעוזרים לפתור את הבעיות והיינו מאוד מרוצים. כל אחד שכתב אצלנו support/ בסלאק, קיבל תפריט מאיר עיניים שעזר לו לנתב למשמרת של הצוות הנכון ולבחור בין לקרוא עמוד רלוונטי בקונפלואנס ולמלא טופס בסלאק שהמיר את עצמו אוטומטית לטיקט בג’ירה. כמעט כל משמרת היה להם פרויקט ג’ירה משלהם עם שאלות ייחודיות להם. התיעוד השתפר מאוד, העברת משמרת ושימור הידע השתפר. כל משמרת לעצמה השתפרה מאוד. עכשיו החלו לצוץ שאלות רחבות יותר: כמה זמן נשארת כל פניה עד שמטופלת? וכמה פניות יש לנו כחברה? ובעיקר אנחנו רואים שכ-20% מכוח הפיתוח שלנו הולך למשמרות טכניות. האם אפשר לשפר? התחלנו לחקור וגילינו שהשדות הייחודיים לכל משמרת – הם בעצם לא ייחודיים כל כך ורובם משותפים. ראינו שיש משמרות שמטפלות רק במקרים הדחופים ויש כאלה שמטפלות בכל המקרים שמגיעים. ראינו שיש משמרות שיש בהן פניות שנשמרות לאורך זמן וכאלה שבהן משך ה- turnover של פניה הוא מאוד מהיר. כמו כן ראינו שעדכון של שדות בבוט דורשים את המשאב היקר ביותר של כל חברה – מפתחי BACKEND ופתיחה של כל משמרת דורשת עוד יומיים שלושה של עבודה. ולא פחות חשוב – מגיעים הרבה פניות וכל פותח פניה מחליט בעצמו על הדחיפות של הפניה. בקיצור, הגיע הזמן לעשות את הקפיצה הבאה.
עכשיו – איך משפרים? מתחילים בלייצר תשתית טכנולוגית אחידה שכבר מאפשר נראות עצומה שלא היתה קודם
החלטנו על פיתרון אחיד ורחב לכולם: כל המשמרות הטכניות יעברו לעבוד בפרויקט ג’ירה אחד שיהיו בו כל הפניות לתמיכה הטכנית, עם סוג טיקט אחד ועם שדות אחידים המבוססים על רשימות סגורות לעומת טקסט חופשי.
מעבר לכך, יצרנו כמה קוים בסיסיים ראשוניים מאוד: כל פניה טכנית ממשיכה כפניה טכנית עד סופה- היא לא מומרת לבאג או לכל סוג אחר. ולא סוגרים פניות עד שהן נפתרו לחלוטין או שהוחלט באופן ברור שלא מתקנים אותם. קוים אלו התאפשרו גם הודות לפיתרון בעיות טכניות של הרשאות והגדרות שמאפשרות לפניה טכנית “לחיות” בפרויקטי ג’ירה שונים (באופן טכני, הכנסנו את ה- issuetype של ה – support ticket לכל ה- issuetype scheme של הפרויקטים שלנו. מהלך שהתאפשר בקלות הודות להאחדת הסכימה בין כל הפרויקטים השונים כצעד מקדים לפני כמה חודשים). כבר בשלב זה אנחנו סימנו לעצמנו נקודות רבות להאחדה עתידית, אבל רצינו להתחיל פשוט.
בנוסף, כדי להקל על ההטמעה, התחלנו רק בהחלפת טכנולוגיה: כל מי שילחץ על הכפתור של “צור פנייה”, יקבל לינק של פניה חדשה ישירות בג’ירה במקום הטופס. וכל מי שעובד במשמרת, רק ישנה את הלוח שעליו הוא עובד ללוח המשותף לכולם. פשוט, לא?
הצעד הזה לבדו איפשר לנו ליצור נראות ברורה לכל בעלי העניין שהיו פותחים את הטיקטים ולא יודעים איך לעקוב אחריהם. ובעיקר אפשר לנו ליצור תמונה אחת גדולה ואחודה לכל הפניות הטכניות ואיפשר לנו לענות על שאלות בסיסיות כמו – כמה פניות פתוחות יש לנו? אילו משמרות טכניות עמוסות ואיזה פחות? איזה פניות נפתחות בכלל?
כל מיני דברים קטנים שעזרו: השדות – בחירה מרשימות סגורות ולא עוד שדות טקסט חופשי. יצירת פניה היא על בסיס לינק- URL שמביא לפתיחה של טיקט חדש, לעומת הפופ-אפ שנפתח בדרך כלל מתוך הג’ירה (בעזרת דף ההסבר הזה)
איך מטמיעים את השינוי ואיך מזהים את כל הפערים?
על אף שהשינוי עצמו היה יחסית קטן, הוא משליך על כמה מאות אנשים בארגון שלנו: כל פותחי הפניות הטכניות ומאות המפתחים המשתתפים במשמרות הטכניות. יצרנו תוכנית הטמעה מדורגת: התחלנו בפיילוט של 3 צוותים ל-3 ימים. לאחר מכן עצרנו ושיפרנו את התשתית – שדות מתאימים, אוטומציות וכו’. לאחר מכן יצרנו תוכנית הטמעה מדורגת בה העברנו הכשרה לכל ראשי הצוותים ולכל הגופים שפותחים פניות טכניות. לאחר מכן בכל יומיים העברנו הכשרה למספר צוותים, בלילה ביצענו את שינויי התשתית הדרושים ולמחרת הצוותים התחילו לפעול בתשתית החדשה.
בנוסף לכך, בכל יום עשינו DAILY במשך שבועיים לכל הצוותים החדשים. רוב המשמרות הטכניות מתחלפות מדי 24 שעות, ולכן בסגירת שבועיים של דיילי, פגשנו כל אחד לפחות פעם אחת. לא היתה פגישה אחת מיותרת! בחלק מהפגישות עלו שאלות ידע ובחלק מהפגישות עלו שאלות שלא חשבנו עליהם קודם וצפו פערים באופן ההתנהלות בין הצוותים והפגישה שחיברה בין צוותים שונים אפשרה למידע לפעפע בצורה טובה.
והצעד הבא – מתשתית טכנולוגית למהות: יצירת אחידות באופן הטיפול והצפת מקורות התייעלות
כאשר יצאנו לדרך, ידענו שחלק לא קטן מהפניות הטכניות מגיעות מצוותים פנימיים שאחראים על השקה של יכולות, עוד לפני השקתם. רק לאחר המעבר לתשתית אחידה, זיהינו שאחוז הפניות הטכניות המגיעות מלקוחות הם כ-30% בלבד. מה שאומר שיש להתמקד בהבנה של הפניות הטכניות הפנימיות שנפתחות ולהבין מה הערוץ המתאים להם והנכון ובחינת חלופות למתן כלים עצמאיים לחלק מהנושאים.
בחינה רחבה של הפניות המתקבלות איפשרה לנו לטייב את הגדרת עדיפות (Priority) אחיד ויצירת סטנדרט לגבי מה נפתר בתוך המשמרת ומה ייפתר בהתאם לתעדוף כולל של משימות הצוות. זה מוביל לשאלות כמו – מה מטרת המשמרת הטכנית ומה מבוצע בה. התמונה המלאה של כלל הפניות בעזרת דשבורדים מאפשרת למנהלי הפיתוח לקחת אחריות ולזהות פניות שנתקעות לאורך זמן ללא פיתרון, לזהות בעיות חוזרות ועוד.
מעבר לכל אלו, השקיפות הזו איפשרה לנו לנתח את הנתונים בצורה רחבה ולאפשר לא רק לייצר אחידות אלא מספר פרויקטי המשך שמאפשרים טיפול מדויק ומהיר יותר. כך שהפרויקט הזה הוא רק ההתחלה.
לסיכום, העברת כלל המשמרות הטכניות לתשתית אחידה, איפשרה לראות את התמונה המלאה ולפתוח את הפתח לשאילת שאלות מהותיות יותר, שיפור השירות ללקוחות ולצעדי התייעלות פוטנציאליים משמעותיים שעוד לא סיימנו להטמיע, אבל להערכתי יעמדו על חיסכון של כ- 10% מכוח האדם. התהליך עצמו משפיע באופן מיידי על מאות עובדים ולכן בוצע בצורה הדרגתית ועל ידי שינויים קטנים וקלים להכלה בכל פעם. ולסיכום יש פרויקטים שהם נגמרים אבל הם רק ההתחלה של משהו חדש – וכיף לראות את זה.
האם גם אתם אנשי אופרציה העוסקים בתהליכי עבודה, מתודולוגיות וכלים בעולמות הפיתוח? אם כן, נשמח שתצטרפו לקבוצת Engineering Operations בוואטסאפ ותעקבו אחרינו בעמוד ה- Linked In שלנו.