יום שבת, 9 ביוני 2012

אילו תנאים בחברה יתרמו להצלחת הבדיקות

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

חשוב מאוד שניקח אחריות על מעשינו. לקיחת אחריות זה לא הודעה בכישלון כמו שהיא הודעה שאנחנו יודעים היום יותר מאתמול, ואנו טובים יותר כי נעשה את מירב המאמצים לא רק שהבעייה הקודמת לא תחזור, אלא שמעתה ייעשו צעדים שגם בעיות דומות יתגלו בזמן. ובסופו של דבר, אנחנו כאן בכדי לגלות טעויות של אחרים.
הבעייה היא, שלמפתח אפשר לסלוח, לשיטתם של מנהלים מסויימים, על פאשלה כזו או אחרת (ואכן אפשר אם הדבר נדיר - הרי כולנו בני אדם). לבדיקות - לא: הם הרי אחראים על טעויות של אחרים ולכאורה לא אמורים לטעות.
יש טעויות שהן אכן של הבודקים בלבד: אם למשל היה כתוב במפרטים שבלחיצה על כפתור ה-send המידע נצבר בבסיס הנתונים, וזה לא מה שקרה: צריך להבין מה קרה כאן ואיך מי שכתב את מפרטי הבדיקה, אלה שעשו להם סקירה, וגם אלה שהריצו אותם לא התייחסו לזאת.
גם אם הבעייה היא בהכנסה לשדות הטקסט תווים שונים ומשונים, סטרינגים ארוכים וכן הלאה: זה ברור שהיינו אמורים לעלות על זה ואנחנו חייבים לקחת אחריות ולוודא שזה לא יקרה שוב.
אבל לא תמיד זו הבעייה. יש מקרים אחרים שבהם היה חסרה פונקציונאליות מסויימת בדרישות המוצר (נניח כי הוא לא הבין כי הוא דורש כאן פיתוח נוסף), ולא היה אזכור לכך גם במסמכים של הפיתוח (כי הצורך המסויים הזה לא היה ברור להם) וגם לא בחדר הבדיקות. מנהל הפרוייקטים, שבסופו של דבר יש לו האחריות הכוללת, לא היה, ומנהל הפיתוח לא חשב על זה. ייתכן שהיה ברור שהמודול הכרחי, אבל לא היה ברור באיזה שלב וכד'.
לקפוץ על הבדיקות כאל אחראים בלעדיים למחדל שכזה זה לא נכון בכמה רמות:
1. זה מנציח את הבעייתיות בתהליך.
2. זה מוריד אחריות מכל הגורמים.
3. זה מעמיד את הבודקים, שאפשר להאמין שנותנים הרבה מהמשאבים שלהם למען החברה, במצב לא נח ויותר מרמור.
ברור שמי שכן עושה כך, מאשים רק את התחנה האחרונה, עושה זאת בכדי או להסיר אשמה מעצמו, או בשל חולשה להתמודדות עם הבעייה האמיתית. פשוט קל להאשים את מחלקת הבדיקות.

אם בפעם הקודמת דיברתי על התנאים להצלחה, הנה התנאים לכישלון (לנגד עיני מדובר בחברה בסה"כ רצינית, עם עובדים טובים ובעלי מוטיבציה):
1. דרישות מוצר שאינן ערות גם לפן הטכני, מסמכים שאינם ברמה גבוהה ומקצועית.
2. חוסר במסמכים מפורטים של הפיתוח.
3. חוסר בבקרה שוטפת של מנהל הפרוייקט שמעלה אף הוא את התנאים להצלחת הפרוייקט ומוודא שהם קוראים.
4. חוסר בתהליכים מסודרים של פיתוח הכוללים:
    א. ישיבות review של המסמכים של כולם.
    ב. מעבר מסודר בין הגורמים השונים (מהמוצר לפיתוח, מהפיתוח לבדיקות וכד').
5. ניהול פרוייקטים פסיבי שאינו כולל:
    א. בקרה על כל הנאמר למעלה.
    ב. וידוא שלכל צד במערכת יש את כל הנדרש בכדי להצליח (מכלים טכניים עד לזמנים).
    ג. ניהול גאנט ודוחות וכל מה שהמושג "מנהל פרוייקטים" מביא.
6. שינויים בתוכניות הן לפעמים הכרחיות ואנחנו חייבים להיות דינמיים. אבל שינויים יום-יומיים בהחלט לא מועילים לאף אחד ומצביעים על ניהול שגוי.
7. חוסר lesson learned ובכלל חוסר בגרות של אירגון ללמוד מטעויות.

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

אין תגובות:

פרסום תגובה

רשומות פופולריות