בחברה מסויימת בה עבדתי הייתה בעיה: אחוז הפתיחה מחדש , ה-reopens, של באגים היה ממש גבוה.
אנשי הפיתוח נאלצו להתמודד עם מערכת מורכבת ביותר שכל דבר בה נוגע בדבר אחר (אין הכוונה לקוד "ספאגטי", כלומר שהקוד היה גרוע, אלא שפשוט זו הייתה טיבה של המערכת), וכל תיקון באג היה דורש לעצור ולחשוב במה זה יכול לפגוע.
במקביל, בדיקת באג מתוקן דרשה את אותה מיומנות של הבנה במה שעלול להיפגע. הבדיקה של התיקון עצמו היה הדבר הקל בד"כ. למעשה, הרבה פעמים הייתי ממש יודע, אינטואיטיבית, מה יפגע בכל תיקון ותיקון.
מסיבה זו היו משהו כמו 40% (אני לא טועה!) reopens לבילד.
מה עושים? לא, לא מנסים לחנך, להסביר וכד'. אולי זה טוב כשיש זמן, ואין אף פעם זמן. הפתרון הרבה יותר פשוט: סמנכ"ל הפיתוח הודיע למפתחים שהם נמדדים מהיום לפי אחוז ה-reopens. אני מניח שזה גם היה קשור לבונוסים ותגמולים כאלה או אחרים.
מאותו הרגע חל מהפך. כשהמפתחים לא הבינו חלק כלשהו מהדיווח של הבאג הם באו ושאלו. כשלא היו בטוחים בפתרון - הם התייעצו איתנו. היו מקרים שהם התווכחו פה ושם על פתיחה מחדש עם טיעוני בית דין מפולפלים, לפעמים הביאו תירוצים שונים ומשונים, אבל בסוף - שהגיע לא אחרי הרבה זמן - אחוז ה-reopens ירד דרמתית.
אנשי הפיתוח נאלצו להתמודד עם מערכת מורכבת ביותר שכל דבר בה נוגע בדבר אחר (אין הכוונה לקוד "ספאגטי", כלומר שהקוד היה גרוע, אלא שפשוט זו הייתה טיבה של המערכת), וכל תיקון באג היה דורש לעצור ולחשוב במה זה יכול לפגוע.
במקביל, בדיקת באג מתוקן דרשה את אותה מיומנות של הבנה במה שעלול להיפגע. הבדיקה של התיקון עצמו היה הדבר הקל בד"כ. למעשה, הרבה פעמים הייתי ממש יודע, אינטואיטיבית, מה יפגע בכל תיקון ותיקון.
מסיבה זו היו משהו כמו 40% (אני לא טועה!) reopens לבילד.
מה עושים? לא, לא מנסים לחנך, להסביר וכד'. אולי זה טוב כשיש זמן, ואין אף פעם זמן. הפתרון הרבה יותר פשוט: סמנכ"ל הפיתוח הודיע למפתחים שהם נמדדים מהיום לפי אחוז ה-reopens. אני מניח שזה גם היה קשור לבונוסים ותגמולים כאלה או אחרים.
מאותו הרגע חל מהפך. כשהמפתחים לא הבינו חלק כלשהו מהדיווח של הבאג הם באו ושאלו. כשלא היו בטוחים בפתרון - הם התייעצו איתנו. היו מקרים שהם התווכחו פה ושם על פתיחה מחדש עם טיעוני בית דין מפולפלים, לפעמים הביאו תירוצים שונים ומשונים, אבל בסוף - שהגיע לא אחרי הרבה זמן - אחוז ה-reopens ירד דרמתית.