תמלול: אייל פינקו | פרק תכלס: שיטת 5 Whys — להגיע לשורש הבעיה

מנחה: Eyal David · אורח: אייל פינקו · חזרה לעמוד הפרק

פרק תכל׳ס קצר וממוקד על שיטת Five Whys — פריימוורק פשוט ואיטרטיבי שמקורו בטויוטה, שבו שואלים "למה" שוב ושוב עד שמגיעים לשורש האמיתי של הבעיה (root cause) ולא רק לסימפטום. אייל פינקו מדגים את השיטה על שני מקרים — אתר שקרס ונטישת עגלת קניות — ומסביר מתי מתניעים את התהליך, מתי עוצרים, ואילו תנאים (הבנת הבעיה, קבוצה cross-functional, שאלות פתוחות, עובדות במקום ניחושים וסקרנות) הופכים אותו לאפקטיבי.

בפרק הזה

  • Five Whys היא שיטה איטרטיבית פשוטה: שואלים "למה" שוב ושוב כדי לחדור מהסימפטום אל שורש הבעיה (root cause).
  • לפני שמתחילים לשאול "למה" צריך קודם להבין ולהגדיר את הבעיה — להוציא דאטה סביבה ולזהות דפוסים.
  • התשובות חייבות להתבסס על עובדות ולא על ניחושים, אחרת נתקעים באותו מקום; לאתגר כל הנחה שמתקבלת.
  • עוצרים כשמזהים בעיה סיסטמטית שתחזור, כשמרגישים "אאוריקה" של סיפוק, כשפתרון הבעיה יפתור גם בעיות אחרות, או כשמגיעים ל-dead end.
  • כדאי לעשות את התהליך בקבוצה cross-functional עם שאלות פתוחות — להקשיב כמה שיותר, לדבר כמה שפחות, ולבוא עם הרבה סקרנות.

מהי שיטת Five Whys ומאיפה הגיעה

אייל פינקו: [00:00] סופר פשוט ואינטואיטיבי להתמודד עם זה, קוראים לפריימוורק הזה Five Whys, זה הומצא בטויוטה, אני חושב שאפילו על ידי המקים של טויוטה, משהו טויוטה, במאה הקודמת עוד, ובגדול זו שיטה איטרטיבית של חמש שאלות, שכל פעם אתה שואל Why, Why, Why, Why. הנה דוגמה מאוד פשוטה, נגיד האתר או איזשהו סרוויס קרס, אז למה הוא קרס? כנראה שדחפו איזו גרסה חדשה, כי אנחנו רואים לפי הלוגים וזה הקריס את זה, למה הגרסה החדשה הקריסה את המוצר? תראה, הוציאו פיצ'ר חדש וכנראה שהפיצ'ר הזה לא משתמש נכון ב-API, למה בעצם עשינו את זה? למה הוצאנו פיצ'ר חדש שלא משתמש ב-API? כי יש מהנדס חדש? והוא לא מכיר טוב את ה-API. אוקיי, למה יש לנו מהנדס שלא מכיר טוב את ה-API? למה חדש? כן, כאילו זה חוזר קצת לעניין של הסקרנות. כן. כי לא עשינו לו טריינינג מספיק טוב. רגע, למה יש לנו מהנדסים שאנחנו לא עושים להם טריינינג מספיק טוב? כי הגישה של ראש הצוות זה שאנחנו רוצים כמה שיותר מהר להכניס אנשים פנימה, אבל יש פה שני דברים, אחד צריך לתקן את הפיצ'ר הזה, אבל הבעיה העמוקה יותר, זה שאנחנו לא עושים טריינינג מספיק טוב למהנדסים. זאת אומרת, מה שיוצא מגבולות המוצר במקרה הזה. כן, וכנראה עד שלא נתקן את ה-root cause, שאנחנו לא מבצעים טריינינג מספיק טוב, הבעיה תחזור על עצמה, והיא תקרה עוד ועוד. אז כדי לעבוד עם השיטה הזאת, היא אומנם מאוד מאוד פשוטה, אבל יש כמה דברים שצריך לעשות. קודם כל, צריך הבנה של הבעיה. אי אפשר סתם להגיד, אוקיי, זו הבעיה, וישר לגשת ל-Why. זאת אומרת, צריך להוציא דאטה סביבה, לנסות למצוא דפוסים, להגדיר אותה כמו שצריך. אחרי זה, כדאי להקים איזושהי קבוצה שהיא cross-functional, שיהיה אפשר לעשות את התהליך הזה של ה-Why איתה. עדיף שהם יהיו באותו... כי אם נגיד היה מישהו מ-dev, אז אף אחד לא יכול להגיד. בדיוק, אתה לא יכול לענות על השאלות בצורה הנורמלית. במהלך השאלות, קודם כל צריך שאלות פתוחות, אוקיי? עכשיו אמרתי Why רק, אבל עדיף לכן לנסח את ה-Why קצת יותר מדויק. בדרך כלל להתבסס על אחד מהאלמנטים מהתשובות. צריך להקשיב כמה שיותר, לדבר כמה שפחות, לתת להם. צריך לנסות לאתגר כל הזמן את ההנחות. כל פעם שנותנים לך תשובה, אתה צריך לנסות לאתגר את זה. התשובות חייבות להיות מבוססות על עובדות, לא ניחושים. כי אם זה ניחושים, אז אתה תיתקע באותו מקום. זהו. תהליך איטרטיבי, צריך, צריך לעשות אותו כמה וכמה פעמים.

דוגמה ראשונה: האתר קרס — מתחילים לשאול למה

מהתיקון הנקודתי אל ה-root cause: טריינינג למהנדסים

תנאי ראשון: הבנה והגדרה של הבעיה

קבוצה cross-functional ושאלות פתוחות

להקשיב, לאתגר הנחות ולהתבסס על עובדות

מתי מתניעים את התהליך — בקשה מלקוח

אייל דוד: [02:40] מתי אתה עושה אותו? נגיד סתם, עכשיו אני, אני יוצא, אני מבין שיש, שיש בקשה מלקוח לצורך העניין. ועכשיו אני בעצם מתחיל להתניע את התהליך הזה כדי להגדיר יותר טוב את הבעיה של הלקוח, ואולי גם אני אמצא בעיות של לקוחות נוספים, זה, משהו שלא דיברנו עליו, מקבץ של בעיות, שזה כבר למתקדמים. לגמרי. אם אני לא מצליח להגיע לשאלה החמישית, אני נתקע בשאלה הרביעית או השלישית,

כשנתקעים לפני השאלה החמישית

אייל פינקו: [03:04] מה אתה מציע? אז תראה, תלוי, יכול להיות שהבעיה עצמה לא הוגדרה מספיק טוב, אבל אפשר לפעמים לעצור לפני זה. השאלה, אוקיי, יש שאלה של בכלל מתי אתה עוצר. כן. אז אתה, אתה עוצר במקרים הבאים. אתה יכול, קודם כל, אם הבעיה היא סיסטמטית, זאת אומרת, אתה מבין שיש פה איזה משהו שיחזור על עצמו, ולא, אוקיי, אה, אני צריך לתקן את הפיצ'ר הזה. אז כנראה לא הגעת עדיין ל-root cause. הרבה פעמים כשאתה מגיע ל-root cause, יש תחושה של סיפוק, אתה כאילו של אאוריקה כזה, של, אוקיי, הבנתי עכשיו. אם הבעיה הזאת תיפתר, זה קצת חוזר לסיסטמטי, אם הבעיה הזאת תיפתר גם בעיות אחרות, אז, אם פתרון הבעיה יפתור בעיות אחרות, אז זה גם סימן טוב. וגם, גם, תשמע, אם אתה מגיע ל-dead end, כאילו כל התשובות נהיות דומות, לא, אין מידע נוסף, אז הגעת, כנראה. או שהגעת ל-dead end, או ששוב, זה לא מוגדר מספיק טוב, או שאין מספיק אנשים בחדר. בדיוק, בדיוק. עכשיו, תראה, זה לא, זה לא נוסחה מושלמת, כן? צריך להתאמן על זה, לפעמים זה יכול גם לא לעבוד. אבל זה, זו שיטה יחסית קלה, לחדור קצת עמוק יותר, וצריך לבוא עם הרבה מאוד סקרנות, זה, זה המפתח. אפשר לקחת עוד דוגמא, אם אתה רוצה. בכיף. נגיד, יש לנו בעיה, שלקוחות נוטשים את עגלת הקניות, אוקיי? אז, אוקיי, למה הם נוטשים את עגלת הקניות? בגלל שהצ'ק-אאוט פרוסס צריך להיות קצר יותר. אוקיי, למה, למה צ'ק-אאוט פרוסס ארוך, בדיוק? בגלל שלקוחות צריכים למלא טופס מאוד מאוד ארוך. למה הוא ארוך? בדיוק, למה הוא ארוך? בגלל שהמערכת שלנו דורשת הרבה מאוד מידע על השיפינג, בשביל לעשות שיפינג כמו שצריך.

מתי עוצרים: בעיה סיסטמטית, אאוריקה ו-dead end

זו לא נוסחה מושלמת — צריך אימון וסקרנות

דוגמה שנייה: נטישת עגלת הקניות והצ'ק-אאוט

אייל דוד: [04:50] זה היה פרק תכלס, מתוך פרודקט בילדר. רוצים לשמוע את השיחה המלאה? חפשו אותה בפיד, ואל תשכחו לעקוב אחרינו.