בהרבה שיחות שיש לי עם מנהלי פרוייקטים, עולים קונפליקטים רבים עם שותפי תפקיד (בעיקר בניהול מטריציוני). אחת הטכניקות להתמודדות מול ה"בעיה" שנוצרת היא באמצעות "חשיבה תוצאתית". אני רוצה להדגים את צורת החשיבה באמצעות דוגמא המתבססת על מקרה אמיתי.
תיאור המקרה:
תוך כדי פרוייקט פיתוח תוכנה, מנהל ה-QA הודיע למנהל הפרוייקט שלא יוכל לעמוד בהתחייבויותיו עקב הסטת משאבים לטובת פרוייקט אחר שתועדף גבוה יותר. לכולם היה ברור שאחת האפשרויות היא לעדכן את תוכנית הפרוייקט ולדחות את מועד סיומו באופן שישקף את מצב זמינות המשאבים החדש.
אך על מנת לא לדחות את הפרוייקט, התכנסו המנהלים הרלוונטיים על מנת לדון במענה לבעיה: "איך משלימים את פער המשאבים ב QA?"
הפגישה התמקדה בבחינת האלטרנטיבות לפתרון:
1. הסטת משאבים ב QA מפרוייקטים אחרים, באופן שימזער את הנזק הכולל לפרוייקטים אלו.
2. הגדלה זמנית של שעות העבודה של אנשי ה QA: בערבים ובימי שישי (קיימים פתרונות ארגוניים למימוש תוכנית כזו באופן שתתקבל בהבנה ע"י העובדים, למשל ע"י תשלום שעות נוספות).
3. עבודה זמנית עם קבלן חיצוני שישלים את פער הבדיקות.
מה יש לחשיבה תוצאתית להציע במקרה הזה?
ע"פ החשיבה התוצאתית: לכל בעיה יש תוצאה שאם נשיגה, או שהיא פתרה את הבעיה באופן ישיר או שהפכה אותה ללא רלוונטית.
(ציטוט מתוך "חשיבה תוצאתית",מאת ראובן כ"ץ, הוצאת ידיעות אחרונות, 2006).
במקרה שלנו, בדיקות QA הן רק אמצעי על מנת להגיע לתוצאה שהיא רמת וודאות מספקת על איכות המוצר לפני שמשחררים אותו לשוק או ללקוח ספציפי. נניח שהגענו לתוצאה הרצויה – אזי בעיית המשאבים ב QA אינה רלוונטית עוד.
מה התרחש בפועל?
כבר עם הגדרת התוצאה הרצויה והצגתה, התפתחו שני דיוניים מעניינים מאוד:
1. כיצד מוגדרת איכות המוצר, וכיצד מודדים אותה?
2. מהי רמת וודאות מספקת?
זהו לא נושא הפוסט שלנו, אך מסתבר שהארגון היה רגיל לתהליך מובנה של פיתוח ובדיקות וההתעסקות עם שאלות אלו הולידה תובנות חדשות. למשל: איכות המוצר צריכה להימדד גם לפי חוויית המשתמש ולא רק לפי כמות הבאגים שנמצאים בתהליך הבדיקות המסורתי.
ברגע שהוגדרה התוצאה הרצויה, המנהלים נפתחו למגוון רחב יותר של פתרונות שיובילו לתוצאה הרצויה, מעבר לפתירת הסוגיה של משאבים ב QA. דוגמאות לפתרונות שהועלו:
1. בדיקת המוצר ע"י המפתחים אך באמצעות תוכנית הבדיקות שה QA הגדיר (כדי למנוע "חיפוש מתחת לפנס" שעלול להיגרם כשהמפתח בודק את עצמו).
2. ניצול כלל עובדי החברה לבדיקת חוויית משתמש ויציבות המוצר (במוצר הזה זה היה אפשרי. פתרון זה לא בהכרח רלוונטי תמיד).
3. הרחבת בדיקות הביתא ע"י לקוחות חיצוניים נוספים, תוך תיאום ציפיות עם הלקוחות.
4. השקעת זמן נוסף בניתוח והגדרה מדוייקת של האיזורים היותר בעייתיים (בהם צריך להתמקד בבדיקות), אך יותר חשוב מכך – איזורים פחות בעייתיים בהם ניתן להפחית בבדיקות.
5. מימוש תוכנית בדיקות איטרטיבית שמטרתה לבחון מידת וודאות באיזורים שונים במוצר וקביעת המשך פעולה בהתאם לקריטריונים שונים. למשל, להתחיל ב 10% מהבדיקות לרוחב המוצר ולהתקדם באיזורים שמתגלים כבעייתיים (בעייתי = מעל %X כשלון בבדיקות). וכך הלאה. בפועל, לתוכנית כזו יש פוטנציאל להפחית את כמות הבדיקות הכוללת שה QA מבצע.
לפעמים חשוב לעצור ולהגדיר מהי התוצאה הרצויה. ברגע שמגדירים אותה נכון, מרחב האפשרויות הניהוליות גדל. וכמו בדוגמא שלנו, יכולות להתפתח תובנות ארגוניות חדשות. (ראה עוד: בחירת הסגנון בניהול קונפליקטים)
אני מאוד ממליץ לנסות את הגישה הזאת בבעיות ניהוליות נוספות. אשמח לשמוע את דעתכם.
רוצה לדעת עוד? להתחיל לנהל ברגל ימין.
ולעוד קפיצת מדרגה ניהולית: סודות הניהול האפקטיבי.
