להצלחה הרבה אבות, הכשלון הוא אמפירי

כמעט כל התהליכים האג׳ילים מבוססים על מנגנונים של שיפור מתמיד, תקראו לזה inspect and adapt, תקראו לזה PDCA, שיפור מתמיד.
בשביל להשתפר צריך ללמוד ובשביל ללמוד כמובן שצריך גם לטעות אבל לטעות זה לא חכמה גדולה,
פיתחנו פיצ׳ר מסוים, הלקוחות לא אהבו אותו, מה למדנו? אם כל מה שלמדנו זה שהפיצ׳ר לא טוב אז כנראה שנפלנו קורבנות לאחד מדפוסי ההתנהגות הבעייתיים ביותר שאני מזהה בארגונים שקוראים לעצמם ארגונים לומדים.
אני אומר את זה בצורה הברורה ביותר: למידה היא לא תירוץ טוב לכישלון, בטח ובטח אם כל מה שלמדנו הוא על עוד משהו שלא עובד.
אם נכשלתם אחרי חצי שנה שבה ישבו 5 מפתחים, שני בודקים, 1 מנהל מוצר ו-150 חבילות של עוגיות עבאדי. אז זה לא למידה, לפחות אני לא רואה את זה ככה.
החכמה בכישלון היא שהוא יהיה מהיר ומדויק, הוא צריך לתת תשובה בדיוק במה נכשלנו ותוך פרק זמן קצר ככל שניתן. מה מתוך אינספור האלמנטים שאנחנו מוציאים לפועל כל יום לא עובד טוב או נכשל? איזה שינוי צריך לנבוע מתוך הניסיון שלנו?

כשלון אמפירי

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

איך מודדים?

צריך להיזהר ממדדים (על זה כבר כתבתי), ואחרי שנזהרנו עדיין ישנם סוגים שונים של מדדים לדברים שונים שרוצים למדוד.
עבור נכונות של פיצ׳רים יש למדוד למשל את התנהגות המשתמשים, כמות קליקים, התנהגות, ביצועים, לערוך סקרים של שביעות רצון ולמדוד, אם זה רלוונטי, את ההשפעה על השורה התחתונה של הארגון – כסף.
עבור נכונות של תהליך ניתן למדוד דברים כגון Lead time, cycle time, שינויים ב-Velocity.
עבור איכות ניתן למדוד דברים כגון: מספר מקרי לקוח, כמות באגים, כמות בקשות לשינויים (CR) ביחס לגודל הפיצ׳ר וכו׳
כל הדברים שציינתי הם יחסית קלים למדידה, רובם כבר קיימים במערכת, הצעד שחסר ברוב המקומות הוא להצמיד את המדדים הללו להחלטות ולבצע השוואות, אני לא טוען שזה קל, זה דורש משמעת, התמדה ובד״כ גם לא עובד טוב בלי רצון אמיתי למצוינות, אבל זה בהחלט אפשרי.

להיכשל מהר

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

אבל יש בעיה…

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

מקור התמונה: http://www.fotopedia.com/items/flickr-3422530465

Comments are closed.