הסלוגן נלקח כמובן מחברת Hyundai, אך מתאים מאד לנושא הנידון. כיצד ניתן לקחת את נושא האיכות ולהפוך אותו מאילוץ
למחולל שינוי בתהליך הפיתוח ?
אם נבחן את נושא הבדיקות (Quality Assurance) בארגונים, נמצא שבמרבית המקרים הוא ידורג בתחתית
סולם העדיפויות של אילוצי גרסה /
פרויקט. יקדמו לו אילוצי זמן, תכולה, ותקציב (משאבים). כאשר ארגון מתעדף בצורה זו
מתחילה תגובת שרשרת אשר לרוב מאופיינת באופן הבא –
בזמן תקופת הפיתוח - תקלות שמזוהות בזמן מוקדם נדחות לתקופת תיקוני
תקלות (Bug fix
period) ע"ח התקדמות בתכולה, כתוצאה מכך אזורי בדיקות מתעכבים,
ומחכים גם הם עד שלצוותי הפיתוח יהיה "מעט חמצן" אשר יגיע רק בסיום
תקופת הפיתוח. (Code
Freeze)
תקופת הבדיקות /
תיקונים – מתמקדת בתיקונים אך גם בהתקדמות הבדיקות וזיהוי תקלות חדשות במוצר.
במרבית המקרים הזמן אשר יוקצה לתיקונים ויציבות הגרסה לא יספיק, ויחרוג לתקופת
הפיתוח של הגרסה הבאה. כתוצאה, בשלבים הראשונים של הגרסה המפתחים יהיו עסוקים יותר
בתיקונים של הגרסה הקודמת ע"ח הגרסה החדשה, דבר אשר יתעדף שוב את התכולה
ע"ח האיכות בגרסה החדשה, וחוזר חלילה.
תופעת שרשרת זו תלך ותגדל
(מעין ספירלה). הארגון מצידו ינסה להתאים את עצמו למציאות החדשה ויחל בהגדלת תקופת
הבדיקות/תיקונים אשר תתפוס יותר ויותר נפח מזמני הגרסה. תהליך זה ימשך עד אשר
הארגון יאלץ להגדיר פתרונות נועזים יותר ע"מ להתמודד עם התופעה כגון - Stabilization version
או Stabilization
period וכו'.
כמובן שפתרון מסוג זה הוא הוא זמני בלבד. ללא חשיבה מחודשת בכיוונים
חדשים הארגון יאלץ להתמודד שוב עם אותן תופעות בדיוק בגרסאות הבאות. ישנן מספר אפשרויות להתמודדות עם תופעה זו, במאמר זה אני אתמקד בפתרון
ע"ב מתודולוגיית Lean
(הניהול הרזה).
Quality – Lean based thinking
אחד מהעקרונות המרכזיים של מתודולוגיית ה Lean מתייחס ישירות לנושא האיכות באופן הבא -
“Quality can be improved by reducing waste and cost, and
optimizing flow” (Taiichi Ohano)
רבים נוטים לחשוב שהמטרה העיקרית של המתודולוגיה הינה צמצום ה
"בזבוז" (muda ביפנית) אך למעשה אם ניקח זאת צעד אחד קדימה, הרי שהדבר היעיל
ביותר לצמצום הבזבוז יהיה- לא ליצור אותו כלל מלכתחילה ...
אז איך עושים את זה?
אגדיר שתי מפתחות עיקריים לשינויי זה -
1. שיפור איכות תוצרים פנימיים
מחקרים שנעשו בתהליכי פיתוח בשנים האחרונות הראו כי כאשר אנחנו מתקנים
תקלות, החלק הארי של הזמן (מעל 50%) מוקדש לפעולות 'סביבתיות' כגון – טעינת
הסביבה, שחזור הדרישות, שחזור הבעיה, וכו' ... חלק קטן של הזמן מוקדש לתיקון התקלה
עצמה.
במילים אחרות זהו "בזבוז" זמן משווע.
אם נעשה שינוי חשיבתי, נשקיע יותר בשלבי התכנון (design), הפיתוח (development) והבדיקות העצמאיות (unit testing), הרי שרמת איכות התוצרים הפנימיים שלנו תגדל. נכון, אין ספק שתהיה לכך עלות, אך בשורה התחתונה הרווח על השקעה זו
יהיה גדול במספר מונים על הזמן שנשקיע בתקון התקלות וייצוב הגרסה לאחר מכן.
במונחי Lean
– אנו נשקיע במניעת היווצרות ה'בזבוז', במקום לנסות אחר כך לצמצם
אותו.
2. קיצור זמן ה Validation
הכוונה היא - קיצור זמן הפידבק על התוצר
לכל אורך תהליך הפיתוח. (דהיינו עבודה באיטרציות /
ספרינטים במושגים אג'ילים). החל משלב כתיבת הדרישות, דרך שלב התכנון, הביצוע, הבדיקות, וכלה בתוצר הסופי. ככל שנקצר את זמן הוולידציה, כך נוכל לקבל פידבק מהיר על
התוצר האחרון שעשינו (בין אם מסמך, קוד, וכו'). דבר אשר יאפשר אישור או תיקון התוצר
הנדרש בצורה הסמוכה ביותר שניתן, לשלב הפיתוח עצמו.
גם כאן, וולידציה מוצלחת בתוך איטריציה /
ספרינט תגרום למניעת היווצרות ה'בזבוז', במקום ההשקעה בנסיון לצמצם אותו
מאוחר יותר.
שורת סיכום
אינני מתימר
לומר שישנה דרך 'קסם' אשר תאפשר יציאה מהירה ממודל הספירלה שהוזכר כאן, אך כאמור
כפי שכל שינוי גדול מתחיל בצעד קטן ראשון, גם כאן – עצם ההבנה שישנו צורך בחשיבה
מחדש על נושא איכות, וההפנמה שדרכו ניתן לצאת ממודל זה הרי שבכך כבר טמון רווח
גדול לארגון כולו. חשוב לציין שהטמעה של שינוי מסוג זה, תדרוש הגדרת תוכנית מוכוונת מדדי איכות, ניטור צמוד, וקבלת החלטות מבוססות איכות לכל אורך הגרסה.
בהצלחה !
יוגב טל
Senior Project Manager, PMP,
Agile Transformation Lead,
PMI Israel E-Magazine Editor
Picture source - http://image.pullbbang.com/image5/v2/video11036//20112019352315_fnt.png
בחזרה לעמוד הבית - מרעננים
את הפיתוח
אין תגובות:
הוסף רשומת תגובה