מה צריך להיות בדיווח באג?

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

איך מצרפים ריפליי הפעלה לדיווח באג?

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

האם צירוף ריפליי הפעלות לפניות תמיכה מסכן את הפרטיות?

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

למה לקבץ פניות באג לפי שגיאה?

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

דיווחי באגים עם ריפליי הפעלה מצורף

המשפט היקר ביותר בתמיכה

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

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

מה באמת יש בדיווח באג שימושי

מפתחים צריכים חמישה דברים כדי לשחזר באג:

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

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

צרפו את ההפעלה במקום לבקש אותה

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

זה משנה את התשובה הראשונה. במקום “תוכלו לשלוח צילום מסך?”, הנציג פותח את הריפליי, רואה את ה-TypeError בקונסול שתי שניות לפני שהלקוח לחץ שוב על “תשלום”, ויכול לכתוב באותה שעה “אנחנו רואים מה השתבש, והנה דרך לעקוף את זה”.

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

מיינו לפי באג, לא לפי פנייה

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

הקיבוץ משנה גם את הדרך לסגור את המעגל. הסלימו את הבאג פעם אחת, לבעיה ב-Linear, ב-GitHub או ב-Jira, וקשרו אליה כל פנייה תואמת. כשהתיקון יוצא, כל הלקוחות האלה יכולים לשמוע עליו, ולא רק החמישה שבמקרה כתבו שוב.

כדי שזה יעבוד, הקיבוץ צריך להתאים למה שצוות הפיתוח כבר רואה. אם התמיכה סופרת “בעיות תשלום” והפיתוח סופר Cannot read properties of undefined (reading 'total'), שתי הרשימות לעולם לא יתיישרו. קבצו את הפניות לפי אותה הודעת שגיאה מנורמלת שמשמשת את מעקב השגיאות שלכם.

טפלו בפרטיות לפני שהיא תטפל בכם

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

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

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

תהליך שאפשר להתחיל השבוע

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

מה למדוד

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

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

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