למה Kanban עובד, ואיך לדעת אם הצוות שלך מוכן לכך
רוב הצוותים מאמצים Kanban כי מישהו קרא פוסט בבלוג. השאלה החכמה יותר היא אם הבעיות ש-Kanban פותר הן באמת הבעיות שיש לצוות שלך.
יש רגע שרוב הצוותים מכירים, בדרך כלל כשיש בהם יותר משמונה או תשעה אנשים. העבודה נעשית, אימיילים נשלחים, פיצ'רים עולים לאוויר, לקוחות מטופלים, אבל לאף אחד אין תחושה ברורה של מה כל השאר עושים. פרויקטים נערמים. מבטיחים דברים ואז שוכחים אותם בשקט. אתה מבזבז עשרים דקות לפני כל פגישה כדי להבין איפה בעצם נמצאת משימה כלשהי. התשובה, בדרך כלל, היא "איפשהו".
זו הבעיה ש-Kanban נועד לפתור. לא הבעיה של קביעת אסטרטגיה, גיוס האנשים הנכונים או בניית תרבות, אלא הבעיה התפעולית הספציפית והמתישה של לדעת על מה הצוות שלך עובד ומה מעכב אותו.
זה כלי צנוע באופן מפתיע לדבר שמשך כל כך הרבה תשומת לב. Kanban לא טוען שהוא יתקן את הארגון שלך. הוא רק הופך את העבודה לגלויה. ומתברר שגלוי, כשמיישמים אותו בעקביות, משנה מספר מדהים של דברים בהמשך הדרך.
מאיפה Kanban באמת הגיע
המילה יפנית, ופירושה "שלט" או "לוח מודעות", והמערכת פותחה על ידי Toyota בסוף שנות ה-40 כדרך לנהל מלאי במפעלי הייצור שלה. הרעיון היה פשוט: במקום לייצר חלקים לפי לוח זמנים קבוע, המפעל ייצר אותם רק כשתחנה בהמשך התהליך סימנה שהיא זקוקה להם. כרטיס פיזי, ה-kanban, היה נע בחזרה במעלה הקו כבקשה. שום דבר לא יוצר על סמך ניחוש. שום דבר לא נערם שלא לצורך.
התובנה של Toyota, שצוותי תוכנה אימצו מאוחר יותר, היא שרוב חוסר היעילות במערכת נובע לא מכך שאנשים עובדים לאט מדי, אלא מכך שהעבודה הלא נכונה נעשית בזמן הלא נכון. יותר מדי דברים מתחילים בבת אחת. צווארי בקבוק שאף אחד לא מבחין בהם עד שמאוחר מדי. עבודה שמסתיימת ויושבת במקום אחד בזמן שהשלב הבא מוצף במקום אחר.
מפתחי תוכנה, בעיקר בחברות כמו Microsoft בתחילת שנות ה-2000, התחילו להתאים את הרעיונות האלה לעבודת ידע. הכרטיסים הפכו למשימות. תחנות המפעל הפכו לשלבים בתהליך עבודה. והשלט הפך ללוח, פיזי בהתחלה ואחר כך דיגיטלי, שבו כל אחד בצוות יכול לראות במבט אחד מה בתהליך, מה ממתין ומה הושלם.
הלוח אינו המערכת. הלוח הוא מה שהופך את המערכת לגלויה. המערכת היא האופן שבו הצוות שלך באמת עובד, והאם זה עובד לטובתך.
מה לוח Kanban באמת מראה לך
בלוח Kanban בסיסי יש שלוש עמודות: לביצוע, בתהליך ובוצע. זה מספיק לצוותים קטנים רבים ומקום התחלה טוב. אבל הערך האמיתי נוצר כשמתחילים להתאים את השלבים האלה לאופן שבו העבודה שלך באמת זורמת, ולא לאופן שבו היית רוצה שתזרום.
צוות תוכן עשוי להשתמש ב: רעיון, בריף, בכתיבה, בבדיקה, מתוזמן, פורסם. צוות תוכנה עשוי לפצל את "בתהליך" לעמודות נפרדות לפיתוח, לסקירת קוד ול-QA. צוות ייעוץ עשוי לעקוב אחרי אפיון, הצעה, פעיל, ממתין ללקוח וסגור. השלבים צריכים לשקף העברות עבודה אמיתיות וזמני המתנה אמיתיים, כלומר מקומות שבהם העבודה עוברת מיד ליד או נתקעת עד שמשהו אחר קורה.
שים לב לכרטיס בעמודה האמצעית: דוח ביקורת המחסן, שנמצא בתהליך כבר שמונה ימים, מסומן כחסום. במערכת בלי לוח, המשימה הזו עלולה לשבת עוד שבועיים לפני שמישהו יבין שהיא לא זזה. מישהו ממתין לצד שלישי. או שנדרשת החלטה ממנהל שלא יודע שהוא הגורם החוסם. הלוח הופך את החסימה לגלויה. זה רוב העבודה.
הכלל שגורם לזה לעבוד: מגבלות WIP
אם יש מושג אחד שמבדיל בין צוותים שמשתמשים ב-Kanban נכון לבין צוותים שסתם יש להם רשימת משימות יפה יותר, הוא מגבלות על עבודה בתהליך (work in progress), או בקיצור מגבלות WIP. הרעיון הוא שלכל עמודה יש מספר מרבי של פריטים שמותר להיות בה בו-זמנית. כשעמודה מלאה, אי אפשר להוסיף עוד עבודה עד שמשהו יוצא ממנה.
זה נראה מנוגד לאינטואיציה. הרי אם אפשר להכניס עוד משימות לתהליך, סימן שיותר דברים נעשים, לא? לא. מה שקורה בפועל כשאנשים עובדים על יותר מדי דברים בו-זמנית הוא שהכול לוקח יותר זמן. מעבר בין הקשרים יקר. עבודה שהושלמה למחצה יוצרת תקורת תיאום. וכשעשרה דברים נמצאים "בתהליך", קשה מאוד לדעת אילו מהם באמת מתקדמים ואילו פשוט תקועים אך לא מסומנים.
מגבלת WIP של שלוש בעמודה "בתהליך" פירושה שכשהדבר הרביעי מגיע לשולחנו של מישהו, מישהו בצוות צריך להחליט: איזו משימה קיימת מסיימים קודם? זה כופה תעדוף. זה כופה שיחה. וזה נוטה להביא להשלמה מהירה יותר של פריטים בודדים, גם אם קצב התחלת הפריטים החדשים מאט.
מחקרים על ריבוי משימות מראים בעקביות שמעבר בין משימות עולה בכ-20–40% מהזמן הפרודוקטיבי. מפתח שעובר בין שלושה פיצ'רים אינו יעיל בשליש בכל אחד מהם. סביר שהוא קרוב יותר לחמישית, כשמביאים בחשבון את התקורה המנטלית של שחזור ההקשר. מגבלות ה-WIP של Kanban הן, בין השאר, תרופה מבנית לכך.
Kanban לעומת Scrum: השאלה שצוותים תמיד שואלים
אם בילית זמן כלשהו בסביבת צוותי תוכנה או בחשיבה תפעולית מודרנית, כנראה נתקלת ב-Scrum, המסגרת שמארגנת את העבודה בספרינטים קבועים של שבועיים, עם פגישות תכנון, רטרוספקטיבות ותפקידים מוגדרים כמו Scrum Master ו-Product Owner. צוותים רבים רואים ב-Scrum וב-Kanban שיטות מתחרות וחושבים שעליהם לבחור. ההבחנה בפועל פשוטה מזה.
Kanban מתאים לך אם
- העבודה מגיעה באופן בלתי צפוי או רציף
- למשימות שונות יש גדלים שונים מאוד
- הצוות שלך משתרע על כמה תחומים
- אתה רוצה להתחיל בקלילות ולפתח את התהליך בהדרגה
- מהירות של פריטים בודדים חשובה ביותר
Scrum מתאים לך אם
- אפשר לתכנן את העבודה במנות קבועות
- הצוות שלך ממוקד בעיקר בהנדסה
- קצב אספקה צפוי הוא בעדיפות עליונה
- יש לך יכולת ייעודית להנחיית תהליכים
- בעלי העניין צריכים עדכונים מובנים ומסודרים
צוותים רבים, במיוחד אלה שאינם צוותי הנדסת תוכנה טהורים, מוצאים שהטקסיות של Scrum כבדה ושמבנה הספרינטים הקבועים שלו מסורבל ליישום על עבודה תפעולית שוטפת. צוותי שיווק, צוותי הצלחת לקוחות, צוותי תפעול ומייסדים שמנהלים הכול בבת אחת רק לעיתים נדירות עובדים בעבודה שמתאימה בצורה מסודרת למחזורים של שבועיים. מודל הזרימה הרציפה של Kanban נוטה להתאים להם יותר.
עם זאת, צוותים רבים משלבים את שניהם. הם משתמשים במחזורי תכנון בסגנון ספרינט לפיתוח המוצר, ובו בזמן מפעילים לוח Kanban לעבודה התפעולית ולעבודת התמיכה שזורמת פנימה בלי קשר לספרינט שבו אתם נמצאים. זה היברידי סביר לגמרי.
שלוש השאלות שהלוח שלך צריך לענות עליהן תוך שלושים שניות
לוח Kanban מועיל ביותר כשאפשר להסתכל עליו ובלי לדבר עם אף אחד לענות במהירות על שלוש השאלות האלה: על מה הצוות עובד עכשיו? איפה העבודה נתקעת? האם יש משהו שצריך להיעשות ועדיין לא התחיל?
אם אינך מצליח לענות על שלושתן תוך שלושים שניות מהסתכלות בלוח, סביר שהוא לא מתוחזק כראוי. דפוס הכישלון הנפוץ ביותר הוא לוח שבו נוצרות משימות אבל אף פעם לא מזיזים אותן. הוא הופך לבית קברות של כוונות טובות במקום למפה חיה של העבודה בפועל. לוח שאינו מעודכן גרוע מחוסר לוח, כי הוא יוצר תחושת שווא של שקיפות.
המשמעת הנדרשת לתחזוקת לוח היא אמיתית. משימות צריכות לזוז כשהעבודה זזה. פריטים חסומים צריכים להיות מסומנים ברגע שהם נתקעים, לא שבועיים אחר כך. לכרטיסים צריכים להיות בעלים ברורים, ובעלים צריכים לעדכן את הכרטיסים שלהם. שום דבר מזה לא דורש הרבה זמן, תרגול Kanban מנוהל היטב עשוי לקחת חמש עד עשר דקות ביום לכל אדם, אבל הוא דורש עקביות. הצוותים שמרוויחים הכי הרבה מ-Kanban הם אלה שמתייחסים ללוח כאל מקור האמת, ולא כאל תרגיל תיעוד משני.
תצוגת הלוח של FabricLoop בנויה בדיוק סביב זה: סביבת עבודה חיה שבה משימות, הודעות והערות נמצאות יחד, כך שעדכון כרטיס לא מחייב מעבר לכלי נפרד. כשמישהו מסמן משימה כחסומה או מעביר אותה ל"בוצע", ההקשר נשאר מחובר אליה: השיחה שמסבירה למה משהו נתקע, הקובץ שהיה התוצר הסופי, ההערה שמתעדת מה הוחלט. הלוח נשאר מעודכן כי עדכון שלו דורש אותו מאמץ כמו כתיבת תגובה.
מה Kanban לא עושה
Kanban אינו כלי אסטרטגיה. הוא לא יעזור לך להבין על מה לעבוד, רק לנהל את מה שכבר החלטת לעבוד עליו. אם בארגון שלך יש בעיית תעדוף, או בעיה של מנדט לא ברור, או בעיה של "אנחנו מתחילים יותר מדי פרויקטים לפני שמסיימים ישנים" שמקורה בהתנהגות ההנהגה ולא בתהליך, לוח Kanban יחשוף את הבעיות האלה אבל לא יפתור אותן.
הוא גם לא תחליף לניהול טוב. לוח לא מחליף שיחות אחד על אחד, האצלה מושכלת או תקשורת ברורה על הסיבה שעבודה מסוימת חשובה. צוותים לפעמים מאמצים כלי תהליך בתקווה שהתהליך יעשה את העבודה הבין-אישית והארגונית שהיא בעצם תפקידו של המנהל. הוא לא יעשה זאת.
מה שהוא כן יעשה הוא להפחית את אי-הוודאות המעורפלת שמאטה את רוב הצוותים. השאלות "מי עובד על מה", "האם זה הושלם" ו"במה כדאי לי להתחיל עכשיו" מייצרות כמויות עצומות של תקשורת דלת ערך בארגונים שאין בהם מערכת משותפת וגלויה. Kanban מבטל את רוב הרעש הזה. ובצוותים שהרעש הזה הוא הבעיה העיקרית שלהם, ההבדל משמעותי.
איך מתחילים, בלי סדנה של שלושה ימים
יישומי ה-Kanban הטובים ביותר שראיתי התחילו בקטן והתפתחו. הגרועים ביותר כללו יועץ, כנס של יומיים מחוץ למשרד ולוח מעוצב להפליא שאף אחד לא השתמש בו עד השבוע השלישי.
התחל עם הצוות שלך כפי שהוא באמת, ועם העבודה שיש לך בפועל. צור שלוש עמודות: Backlog, בתהליך, בוצע. הקדש שלושים דקות עם הצוות כדי להעלות כל פריט עבודה נוכחי על כרטיס. הסכימו על כלל אחד: כשמתחילים משהו, הוא עולה ללוח. כשהוא זז, מזיזים את הכרטיס. אל תעשו שום דבר אחר במשך שבועיים.
אחרי שבועיים, הסתכלו בלוח יחד. איפה דברים נערמו? מה נשאר ב-Backlog ממה שכולם אמרו שהוא בעדיפות? מה זז מהר מהצפוי? מה נתקע ולמה? השתמשו במה שראיתם כדי לדייק את העמודות ולהוסיף פירוט. אולי צריך לפצל את "בתהליך" ל"בתהליך" ו"ממתין לגורם חיצוני". אולי צריך עמודה "בסקירה" כי השלב הזה כל הזמן הולך לאיבוד. תנו ללוח להתפתח בהתאם למה שהעבודה האמיתית שלכם חושפת, ולא בהתאם לאיך שספר על מתודולוגיות אומר שהוא צריך להיראות.
אל תוסיף עוד עמודות כדי שהלוח ייראה מתוחכם. כל עמודה היא העברת עבודה, וכל העברת עבודה היא מקום שבו העבודה יכולה להיתקע. התחל בפשטות. הוסף מורכבות רק כשהגרסה הפשוטה מראה לך איפה היא נחוצה.
המשחק הארוך: מדדי זרימה
ברגע ש-Kanban פועל, הוא מייצר נתונים שרוב הצוותים לא משתמשים בהם לעולם. זמן מסירה (lead time), כלומר הזמן הכולל מרגע יצירת המשימה ועד השלמתה, הוא החשוב ביותר. אם זמן המסירה הממוצע של משימה טיפוסית הוא שנים עשר ימים, ואתה רוצה שיהיה חמישה, יש לך עכשיו מספר לעבוד מולו ולוח שיראה לך לאן הולכים שבעת הימים הנוספים.
זמן מחזור (cycle time) מודד רק את תקופת העבודה הפעילה, ללא הזמן שמשימה יושבת ב-Backlog. תפוקה (throughput) מודדת כמה פריטים הצוות משלים בשבוע. אף אחד מהמדדים האלה לא דורש תוכנה מיוחדת אם אתה ממושמע ברישום מתי כרטיסים נוצרו ומתי נסגרו. ויחד הם נותנים לך תמונה כנה בהרבה של יכולת הצוות שלך מכל תהליך תכנון מבוסס הערכות.
רוב הצוותים הקטנים והבינוניים אף פעם לא מגיעים לכאן. הם משתמשים ב-Kanban ככלי שקיפות, וזה בעל ערך כשלעצמו, ולא הולכים רחוק יותר. זה בסדר. אבל אם אתה מוצא את עצמך רוצה להתחייב בפני בעלי עניין מתי משהו יסתיים, או רוצה להבין למה עבודה מסוימת לוקחת פי שלושה מהצפוי, המדדים שם כשאתה צריך אותם.
ב-FabricLoop כל כרטיס נושא את ההיסטוריה שלו: מתי נוצר, מתי עבר בין שלבים, מתי הושלם. הנתונים האלה קיימים בין אם אתה משתמש בהם עכשיו ובין אם לא. צוותים שהתחילו בפשטות חוזרים אליהם לעיתים קרובות אחרי חצי שנה, כשהם רוצים להבין למה רבעון מסוים הרגיש כל כך כאוטי, ומגלים שהלוח תיעד כל מה שהיו צריכים לדעת.