Defect Leakage המדד שכל מנהל חייב להכיר
ארגונים משקיעים זמן רב בבדיקות, בתהליכי אישור ובבקרת איכות לפני שחרור גרסה. למרות זאת, חלק מהתקלות מתגלות רק לאחר שהמוצר מגיע ללקוחות. מדד Defect Leakage ״זליגת תקלות״, בוחן בדיוק את הפער הזה.
זהו אחד המדדים החשובים ביותר להבנת יעילות תהליך הבדיקות, רמת הסיכון של הגרסה והשפעת האיכות על הלקוחות. עם זאת, כדי להפיק ממנו ערך אמיתי, צריך למדוד ולפרש אותו נכון.
מהו Defect Leakage ?
Defect Leakage הוא שיעור התקלות שלא התגלו במהלך הפיתוח והבדיקות, אלא רק לאחר שחרור המוצר לסביבת הייצור או ללקוחות.
במילים פשוטות, המדד מציג כמה תקלות ״ברחו״ מתהליך הבדיקות.
נוסחה נפוצה לחישוב המדד היא:
שיעור זליגת התקלות = מספר התקלות שהתגלו לאחר השחרור ÷ כלל התקלות שהתגלו לפני השחרור ואחריו × 100
לדוגמה, אם לפני שחרור הגרסה נמצאו 90 תקלות ולאחר השחרור נמצאו 10 תקלות נוספות, שיעור זליגת התקלות הוא 10%.
החישוב פשוט, אך המספר לבדו אינו מספר את כל הסיפור.
מדוע המדד חשוב למנהלים?
מנהלים מקבלים בדרך כלל דיווחים על מספר הבדיקות שבוצעו, מספר התקלות שנמצאו והתקדמות הצוות ביחס ללוח הזמנים. הנתונים האלה מתארים את הפעילות לפני השחרור, אך אינם בהכרח מלמדים עד כמה התהליך הגן על הלקוחות.
Defect Leakage מחבר בין עבודת הארגון לבין התוצאה בפועל. הוא מאפשר לבחון האם תהליך הפיתוח והבדיקות מצליח לזהות סיכונים לפני שהם משפיעים על משתמשים.
למדד יש כמה שימושים מרכזיים:
- הערכת יעילות הבדיקות לפני השחרור.
- זיהוי אזורים במוצר שבהם קיים סיכון גבוה.
- בחינת ההשפעה של קיצור זמני פיתוח ובדיקות.
- איתור פערים בדרישות, בתכנון או בסביבות הבדיקה.
- מעקב אחר מגמת האיכות לאורך זמן.
- קבלת החלטות לגבי השקעה בכלים, בכוח אדם ובתהליכים.
הערך המרכזי של המדד הוא בכך שהוא מעביר את הדיון ממספר הפעולות שבוצעו אל התוצאה שהלקוח חווה.
לא כל תקלה שווה באותה מידה
אחת הטעויות הנפוצות היא לחשב את המדד על סמך מספר התקלות בלבד. תקלה קלה בצבעו של כפתור אינה שוות ערך לתקלה שמונעת ביצוע תשלום, גורמת לאובדן מידע או משביתה שירות מרכזי.
לכן מומלץ להציג את זליגת התקלות גם לפי דרגת חומרה:
- תקלות קריטיות המשביתות תהליך מרכזי או יוצרות סיכון משמעותי.
- תקלות חמורות הפוגעות באופן מהותי בשימוש במוצר.
- תקלות בינוניות שמקשות על המשתמש אך מאפשרות להמשיך לעבוד.
- תקלות קלות בעלות השפעה מוגבלת.
ייתכן שבגרסה מסוימת שיעור הזליגה הכללי יהיה נמוך, אך תקלה קריטית אחת תגרום לנזק עסקי משמעותי. מנגד, שיעור גבוה יחסית של תקלות קלות אינו מעיד בהכרח על כשל חמור בתהליך.
מנהלים צריכים לבחון לא רק כמה תקלות זלגו, אלא גם מה הייתה השפעתן.
כיצד להגדיר את גבולות המדידה?
לפני שמתחילים למדוד, חשוב לקבוע הגדרות אחידות. ללא הגדרות ברורות, אי אפשר להשוות בין גרסאות, מוצרים או תקופות.
יש להחליט:
- מה נחשב תקלה?
- מהו מועד השחרור שממנו מתחילה המדידה?
- כמה זמן לאחר השחרור ממשיכים לספור תקלות?
- האם סופרים תקלות שדווחו על ידי לקוחות בלבד, או גם תקלות שהתגלו בניטור פנימי?
- כיצד מטפלים בכמה דיווחים המתייחסים לאותה תקלה?
- האם תקלות שנגרמו מתשתית או משימוש לא צפוי נכללות בחישוב?
- כיצד מסווגים את חומרת התקלה?
מומלץ לבחור חלון זמן קבוע, לדוגמה 30 יום לאחר כל שחרור. במוצרים שבהם השימוש ביכולת חדשה גדל בהדרגה, ייתכן שיידרש חלון זמן ארוך יותר.
העיקר הוא לשמור על עקביות.
מה גורם לזליגת תקלות?
זליגת תקלות אינה בהכרח תוצאה של עבודה לקויה של צוות הבדיקות. תקלה יכולה לעבור לסביבת הייצור מסיבות רבות:
דרישות לא ברורות
כאשר ההתנהגות הרצויה של המוצר אינה מוגדרת היטב, גם הפיתוח וגם הבדיקות עלולים להסתמך על הנחות שונות. במקרה כזה התקלה מתחילה עוד לפני כתיבת הקוד.
כיסוי בדיקות חלקי
ייתכן שלא נבדקו כל התרחישים החשובים, במיוחד שילובים מורכבים, הרשאות שונות, עומסים או מצבי קצה.
פער בין סביבת הבדיקות לסביבת הייצור
הבדלים בנתונים, בהגדרות, בתשתיות או בחיבורים למערכות אחרות עלולים לגרום לתקלות שיופיעו רק לאחר השחרור.
לחץ זמן
כאשר מועד השחרור אינו משתנה אך היקף העבודה גדל, זמן הבדיקות מתקצר. לעיתים הצוות נדרש לוותר על חלק מהבדיקות בלי שהסיכון מתועד ומאושר באופן ברור.
שינויים מאוחרים
תיקון או שינוי שבוצעו סמוך לשחרור עלולים להשפיע על אזורים שלא נבדקו מחדש.
מידע חסר מהייצור
כאשר לצוות אין גישה מספקת לנתוני שימוש, לדיווחי לקוחות ולפרטי התקלות, קשה להבין אילו תרחישים חשוב לבדוק בגרסאות הבאות.
איך מנתחים את המדד נכון?
אין ערך רב בהצגת אחוז בודד בלוח ניהולי. כדי להפוך את המדד לכלי עבודה, צריך לנתח אותו מכמה זוויות.
מגמה לאורך זמן
יש לבדוק האם שיעור הזליגה עולה, יורד או נשאר יציב לאורך כמה גרסאות. גרסה אחת עשויה להיות חריגה בגלל שינוי גדול במיוחד. מגמה מתמשכת מספקת תמונה אמינה יותר.
חלוקה לפי אזור במוצר
אם רוב התקלות מגיעות מאזור מסוים, ייתכן שהוא מורכב במיוחד, אינו מתועד מספיק או חסר בו כיסוי בדיקות מתאים.
חלוקה לפי מקור התקלה
כדאי לבדוק האם מקור התקלה הוא בדרישות, בתכנון, בפיתוח, בנתונים, בתשתית או בבדיקות. כך אפשר לטפל בגורם ולא רק בתוצאה.
חלוקה לפי סוג הבדיקה שהייתה יכולה לזהות אותה
ניתוח כזה מאפשר להבין אילו יכולות חסרות: בדיקות של תהליך עסקי מלא, בדיקות עומס, בדיקות אבטחה, בדיקות הרשאות או בדיקות של חיבורים בין מערכות.
השפעה עסקית
מומלץ לחבר את המדד למספר הלקוחות שנפגעו, למשך התקלה, להיקף הפניות לשירות, לאובדן הכנסה ולזמן העבודה שהושקע בתיקון.
כך ניתן להבחין בין תקלה בעלת השפעה שולית לבין אירוע איכות משמעותי.
טעויות נפוצות בשימוש במדד
הפיכת המדד לכלי להאשמת צוות הבדיקות
איכות המוצר היא אחריות משותפת של ההנהלה, אנשי המוצר, הפיתוח, הבדיקות והתפעול. כאשר המדד משמש להאשמת צוות מסוים, אנשים מתחילים להתווכח על סיווג תקלות במקום ללמוד מהן.
השוואה ישירה בין צוותים
שני צוותים עשויים לעבוד על מוצרים שונים לחלוטין מבחינת מורכבות, סיכון, מספר משתמשים ותדירות השחרור. לכן השוואה ישירה ביניהם עלולה להיות מטעה.
התמקדות באחוז בלבד
אחוז נמוך אינו מבטיח איכות גבוהה. ייתכן שבמהלך הבדיקות נמצאו מעט תקלות משום שהכיסוי היה מצומצם, וייתכן שחלק מהתקלות בייצור עדיין לא דווחו.
ניסיון להגיע לאפס בכל מחיר
שאיפה לאפס תקלות נשמעת נכונה, אך עלולה להוביל לעיכובים ממושכים, לעלויות גבוהות ולבדיקות שאינן תואמות את רמת הסיכון. המטרה צריכה להיות הפחתה של תקלות משמעותיות לרמה שהארגון הגדיר כסבירה.
שינוי הגדרות בין גרסאות
אם פעם סופרים תקלות במשך שבוע ופעם במשך חודש, או אם משנים את דרגות החומרה ללא תיעוד, הנתונים אינם ניתנים להשוואה.
כיצד מפחיתים את זליגת התקלות?
שיפור המדד אינו מתחיל בהוספת בדיקות בלבד. הוא דורש טיפול רחב בתהליך:
- להגדיר דרישות ותנאי קבלה ברורים לפני תחילת הפיתוח.
- לשלב את אנשי הבדיקות כבר בשלבי התכנון.
- למפות את האזורים בעלי הסיכון העסקי הגבוה ביותר.
- להתאים את עומק הבדיקות לרמת הסיכון.
- להשקיע בבדיקות חוזרות ואמינות לתהליכים מרכזיים.
- לצמצם פערים בין סביבת הבדיקות לסביבת הייצור.
- לשחרר שינויים בהדרגה לקבוצה מוגבלת של משתמשים.
- לשפר את הניטור ואת יכולת הזיהוי המוקדם לאחר השחרור.
- לבצע ניתוח סיבה לתקלות משמעותיות.
- להפוך תקלות מהייצור לתרחישי בדיקה קבועים כאשר הדבר מתאים.
חשוב להגדיר לכל פעולה בעלים ומועד ביצוע. ללא אחריות ברורה, הניתוח נשאר מסמך במקום להפוך לשיפור ממשי.
מדד ניהולי, לא ציון לצוות
Defect Leakage הוא מדד רב־ערך כאשר משתמשים בו כדי לשאול שאלות נכונות: היכן הסיכון שלנו? אילו תקלות משפיעות על הלקוחות? איזה שלב בתהליך דורש שיפור? ומה המחיר של האצת השחרור?
הוא הופך למסוכן כאשר מציגים אותו כציון אישי או כיעד שיש להוריד בכל מחיר.
מנהל שרואה עלייה בזליגת התקלות לא צריך להסתפק בדרישה ״לבדוק יותר״. עליו לבחון אם היקף הגרסה היה גדול מדי, אם הזמן שהוקצה היה סביר, אם בוצעו שינויים ברגע האחרון ואם הצוות קיבל את הכלים והמידע הנדרשים.
סיכום
Defect Leakage מחבר בין תהליך האיכות לבין המציאות של הלקוחות. הוא מאפשר לזהות לא רק כמה תקלות נמצאו, אלא כמה תקלות משמעותיות לא נמצאו בזמן.
כדי שהמדד יהיה מועיל, יש לחשב אותו באופן עקבי, להציג אותו לפי חומרה והשפעה, לנתח את הסיבות לזליגה ולעקוב אחר המגמה לאורך זמן. חשוב במיוחד להשתמש בו ללמידה ולשיפור, ולא לחיפוש אשמים.
הצעד הראשון פשוט: בחרו גרסה אחת שכבר שוחררה, אספו את התקלות שהתגלו לפניה ואחריה, וסווגו אותן לפי חומרה, אזור במוצר וסיבה. לאחר מכן קיימו דיון משותף של הנהלה, מוצר, פיתוח ובדיקות ובחרו שתי פעולות ממוקדות לגרסה הבאה.
אל תסתפקו בשאלה כמה תקלות מצאנו. שאלו אילו תקלות הגיעו ללקוחות, מדוע הן הגיעו אליהם ומה נשנה כדי שהן לא יחזרו.