בשבועות האחרונים בחנתי גרסה חדשה של מוצר. ניסינו למצוא דרך חדשה לגמרי להעביר את המשתמשים שלנו חוויה מאוד מסוימת והיה לנו רעיון קצת out of the box. אז איפיינו את הרעיון שלנו, בנינו prototype עשינו בחינות ומה אני אגיד לכם. זה לא עבד. עשינו שינויים ותיקונים וניסינו שוב. שיפור קל אבל לא מתקרב לתוצאות שרצינו.
אני מניח שאתם מצפים שאני אכתוב עכשיו על איך הסתכלתי על המדדים, מצאתי איפה הבעיה ומה אפשר לשנות ובום! הצלחה גדולה! הפוסט הזה לא יהיה כזה. מוצרים נכשלים. לפעמים זו טרגדיה אם ניתן היה למנוע את כישלון או אם מדובר במקרה שהסיבות לכישלון לא קשורות למאמצים שלנו (נניח מגיפה בינלאומית). אבל לפעמים הכישלון הוא רק צעד בתהליך כי ניסינו משהו חדש וגילינו שהוא לא עובד בנסיבות מבוקרות ובלי נזק. לשמחתי, המקרה הפעם היה מהסוג השני. אני רוצה לחלוק אתכם כמה תובנות בעקבות מה שקרה כשניסינו כיוון חדש ומעניין והוא לא השתלם, או מנקודת מבט אחרת: מה חשוב לעשות במקרה של כישלון.
נקודה חשובה, לפני שאנחנו עושים שינוי כיוון או מנסים רעיון חדש ונועז חשוב לקבל את האישור של ההנהלה והמחלקות הרלוונטיות. ככה ההנהלה לא מרגישה שנכשלנו בעבודה שלנו אלה שניסינו משהו חדשני והמחלקות הרלוונטיות לא מרגישות שביזבזנו את הזמן שלהן.
כמו כן, אני מצטער מראש אבל אני עדיין לא יכול לשחרר פרטים ספציפיים לגבי הפרויקט שהציף לי את הרעיון לפוסט הזה. אולי בעתיד אני אוכל לערוך ולהוסיף מידע קונקרטי.
הנה כמה תובנות שאפשר וצריך לעשות אחרי כישלון:
להאמין לנתונים שלנו
כשיש לנו רעיון חדש ומעניין אנחנו רוצים שהוא יצליח. לפעמים עד כדי כך שאנחנו מתעלמים מהנתונים של הבדיקות, או ממציאים לעצמם הסברים למה הרעיון כן בסדר למרות הנתונים. אחד מהלקחים הכי חשובים מכל הפעמים שראיתי מוצרים נכשלים הוא להאמין לנתונים שלנו ולפעול לפיהם.
זה לא אומר שהנתונים תמיד נכונים, לפעמים הנתונים יכולים להיות מטעים. אבל זה כמעט תמיד מסיבות שאפשר לדעת מראש ולפעול לנטרל. הסיבות הללו כוללות: הטיית בחירה (Selection Bias), מתודולוגיית בחינה מוטעה, גודל דגימה לא מייצג, ועוד. מהסיבות הללו חשוב כפליים להכין מראש מדדים ברורים לבחון אם אנחנו מתקרבים למטרות שלנו או מתרחקים מהן.
לקח: תמיד להגדיר מדדי הצלחה מראש, זה מונע מאיתנו ללכת לאיבוד בתוך הנתונים. כמו כן, תמיד שווה לוודא כי מתודולוגיות הבדיקות והבקרה שלנו נכונות.
לבדוק לפני שמשחררים גרסה
כמו שאמרתי, אני גיליתי שהגישה החדשה שלנו לא עובדת כבר בשלב הבדיקות. משתמשים לא נחשפו לממשק החדש מלבד כמה design partners שידעו שהם בוחנים משהו חדש. ככה לא היה תחושת אכזבה בקרב הלקוחות האמיתיים. זו הרי חלק מהסיבה שאנחנו עושים MVPs ו-POCs מלכתחילה. כדי למזער כישלונות פוטנציאלים.
לקח: תמיד לחשוב האם היתה דרך לגלות שהגישה החדשה לא עובדת בשלב מוקדם יותר? האם בדיעבד ניתן לראות סימנים מקדימים שרמזו על הכיוון הזה? האם היו בדיקות ששווה להוסיף לסדרת הבדיקות הקבועה שלנו? בדיקות זה אלמנט הכרחי אבל חשוב לזכור מה המטרה של הבדיקות וזה למצוא בעיות מוקדם ככל האפשר.
הפקת תובנות ולקחים
לעיתים מאוד נדירות יש כישלון שאי אפשר ללמוד ממנו. אם גילינו משהו שלא עובד וזה לא משנה אם מדובר בגישה, עיצוב, או תהליך. אז אנחנו יכולים לבדוק ולוודא שאין שימוש ברכיב דומה ובעייתי במקום אחר במוצר שלנו. אם מצאנו משהו קטן שכן עובד יותר טוב מהמצב הקיים אז אין סיבה שלא ליישם את התובנות המוצלחות הללו בעוד מקומות במוצר שלנו. דוגמאות קונקרטיות יכולות לכלול עדכון של תהליכי עבודה ופיתוח, מחזורי בדיקות, שיפור דרכים לקבלת פידבק מלקוחות.
לקח: גם מפרויקט כושל חשוב להפיק תובנות לגבי מה עבד ומה לא ולשפר רוחבית.
תוצרים שמישים
אם בסעיף הקודם דיברנו על תובנות, פה אני מדבר על תוצרים בפועל. יכול להיות שבמהלך הפרויקט הזה יצרנו דברים מוצלחים: קטעי קוד, ממשקים, אלמנטים עיצוביים, מיקרו-קופי מוצלח, אייקונים, איורים או כל תוצר אחר. אין טעם לזרוק איורים או טקסטים טובים כי הפרויקט שהם היו בו לא השיג את המטרה שלו. אם העבודה שהושקעה יכולה להקל על פרויקטים אחרים או להעשיר את היכולות שלנו אז אין סיבה לא לקחת אותם איתנו. אני רואה את זה הרבה עם עיצובים גרפיים וטקסטים שיווקיים, שלפעמים לוקח הרבה זמן לדייק ולשייף אותם ולרוב אפשר למחזר אותם ולחסוך הרבה זמן ומאמץ.
לקח: שווה ליצור מאגר מרכזי של נכסים שאפשר למחזר לשימוש בפרויקטים ומוצרים אחרים.
ביצוע פוסט מורטם מסודר ללא אשמים
בתוך צוותים טכנולוגיים יש מסורת מאוד מסודרת של קיום פוסט מורטם לאחר כל תקלה. אחד המונחים הכי חשובים בנשא הזה הוא “Blameless Post Mortem” או “פוסט מורטם ללא אשמים”. הכוונה היא לתיחקור הגורמים לבעיה מבלי להאשים אף אחד. למה? כי כולם עושים פאשלות לפעמים, זה פועל יוצא של היותנו בני אדם. המטרה של פוסט מורטם צריכה להיות לייצר כמה שיותר פתרונות שיעזרו לנו להימנע מלעשות שגיאות נוספות בעתיד. התוצר של פגישה כזו יכול להיות קוד בדיקות, צ’ק ליסט מסודר לביצוע פעולות כדי ליפול על אותה טעות, תוכנית עבודה מוסדרת שמבטיחה שעוד מישהו יעבור על דברים לפני אישור. המהדרין גם יבדקו אם יש קשר בין הגורמים לכישלון בפוסט מורטם לעומת הגורמים הפוטנציאליים שהעלנו בפרה-מורטם.
לקח: לנרמל ביצוע של תחקירי כישלון מתוך פוקוס על מניעת טעויות ולא חיפש אשמים.
לסיכום
יש הרבה מאוד דברים שאנחנו יכולים להשיג מכישלון על מנת לצמוח ולהשתפר. גם עבורנו אישית, גם עבור תהליכי העבודה בארגון שלנו, וגם עבור המוצר שלנו. הכישלון האמיתי היחיד הוא לא להשתפר בעקבות כל תקלה שאנחנו חווים. הייתי חלק מהרבה פרויקטים שהצליחו ומהרבה פרויקטים שנכשלו, ואני גאה להגיד שאף פעם לא הייתי בשני פרויקטים שנכשלו מאותה הסיבה.
