מיפוי תקלות

[אוגיטוס]

מיפוי תקלות

לראשונה בקבוצה החלטתי למפות את דיווחי התקלות מלקוח.
אני מודעת לרגישות (סוגיה אידאולוגית) בעבודה על סטטיסטיקות אקסליות, ובכל זאת צריך להתמודד עם מציאות, והאמת, אני גם סקרנית לדעת מה הממצאים.
הכוונה לצאת בסופו של דבר עם דוח ובו תקלות שניפתחה במהלך הגירסה ממופים ל:
design issue
qa issue
not reproduced
not an issue
new request
וכיוצ"ב

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

תודה!

 

[halperin]

הכי חשוב להבין כי אף לקוח לא באמת נותן משוב...

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

- אבל שאלת "מה כדאי וחשוב לקחת בחשבון...")

 

[אוגיטוס]

לא מובן

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

 

[halperin]

יש לך לקוחות? את חושבת שהם מדווחים כל מה שהם רואים?

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

 

[אוגיטוס]

אנחנו עושים מה שאפשר לעשות

וכן, זה לא הרמטי

 

[halperin]

ואז נשאלת השאלה - האם נכון לבדוק עצמנו מול 1-5% הבעיות שכן

ואז נשאלת השאלה - האם נכון לבדוק עצמנו מול 1-5% הבעיות שכן מדווחות לנו מהלקוחות (כאשר מעל 90% ממה שהלקוחות חווים הם כלל לא מדווחים)?
ומה זה בעצם אומר?
&nbsp
אז כן - ניתן להפיק גם מאלו מידע - אך לא להתייחס כאילו זה כל מה שזלג לשטח מתהליכי הפיתוח.

 

[Issi Hazan]

בתוך הקטגוריות שהצעת יכולות להיות מספר קטגוריות

כדי להפיק לקחים ולא רק לסווג מי "אשם" כדאי לפרק את הקטגוריות. למשל בתוך "QA issue":
Gap ידוע - כאשר קיבלנו החלטה מושכלת לא לכסות איזור מסויים (או setup מסויים וכו)
execution gap תכננו לבדוק אבל לא בדקנו מסיבות מסויימות
נבדק אבל... (לדוגמא באג שנכנס מאוחר, באג באוטומציה, test נפל אבל לא נפתח באג מתאים ....)

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

 

[אוגיטוס]

תודה. מובן ורלוונטי.

 

[halperin]

 

[עמית ו]

בשביל מה זה טוב?

או, ליתר דיוק - מה את מנסה להפיק מזה?
ברשימה שלך יש כמה קטגוריות שונות של סטטוסים:
1) "מי אשם" (עיצוב, בדיקות, לא בעייה)
2) "מה המצב" (בקשה חדשה, לא בעייה, אי אפשר לשחזר)
אני מניח שככל שהרשימה תצמח, יכנסו עוד כמה קטגוריות כאלה.
&nbsp
לפני שאת מתחילה עם הכל - מה את מעוניינת למדוד? למה מעניין אותך לדעת כמה באגים לא הצלחתם לשחזר? או למה מעניין אותך לדעת אם באג נובע כתוצאה מפספוס בבדיקות או פספוס בעיצוב (והאם זה שלא בדקו את העיצוב זה נחשב פספוס של בדיקות?)?

 

[אוגיטוס]

זו המטרה

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

 

[halperin]

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

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

 

[אוגיטוס]

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

 

[עמית ו]

אם כך, המצב פשוט יותר

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