קנבן – שלושת הדברים החשובים

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

יצור רזה בעולם התוכנה

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

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

 מתודולוגיות "הכל או לא כלום"

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

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

אז הנה לטעמי, שלושה עקרונות חשובים מאוד של ייצור רזה וקנבן

1. ויזואליזציה – אם נכנס לפס יצור, נוכל כמעט מייד לדעת מה כל אחד עושה, ומהם השלבים השונים בתהליך. מהר מאוד נוכל להצביע על בעיות כמו תחנה שלא עומדת בעומס, התרחשות של כשלים רבים בנקודה מסוימת וכו'. לעומת זאת, אם נכנס ל'מפעל תוכנה' כל מה שנראה זה הרבה אנשים ליד מחשבים. לא נהיה מסוגלים אפילו להבדיל בין מפתח, מעצב, איש בדיקות וחשב שכר ובוודאי שלא נזהה בעיות באופן ויזואלי. חשוב מאוד לייצר ייצוג ויזואלי של 'פס היצור' שלנו שיראה באופן דינמי מה מתבצע בכל נקודה ויאפשר זיהוי של כשלים או נקודות תורפה במערכת.
2. קאיזן וטיפול באילוצים –  קאיזן הוא העיקרון לפיו צריך לבצע שינויים קטנים, בקצב איטי אך בהתמדה. העובדה שהשינויים הם קטנים מאפשרת להטמיע אותם ביעילות (בניגוד לשינויים גדולים שמעוררים התנגדות וקשים ליישום) והכוח המצטבר שלהם לאורך זמן הוא גדול יותר מכל שינוי גדול שמתבצע בהרבה רעש וצילצולים. עקרון נוסף הוא טיפול באילוצים כלומר את השינויים יש לבצע בנקודות התורפה הקשות ביותר שמשפיעות על כל המערכת. גם אם ניתן לשפר את המהירות של מחלקת הפיתוח פי 2, אין בזה טעם אם בכל מקרה מחלקת הבדיקות לא עומדת בעומס. כל שינוי צריך להימדד בהשפעתו ההוליסטית/גלובלית. מידת השיפור הלוקלית כמעט אינה חשובה. מערכת ויזואליזציה מאפשרת לזהות את צווארי הבקבוק האלה ביעילות.
3. להתחיל בהווה – ישום של קאנבן צריך להתחיל מייד מהמצב הקיים, ולא לחכות לאיזו מהפיכה שתשנה את כל צורת העבודה מהיסוד. מהפכה כזו היא לא רק עיכוב מיותר (ומי אמר בכלל שבצורה החדשה לא תהיינה בעיות?) אלא לעיתים בכלל לא מתאימה למציאות. (נסו בבקשה ליישם כמה מהשיטות האג'יליות במחלקת IT של חברת ביטוח…) . הדמייה ויזואלית של המצב ושיפור מתמיד של האילוצים הקשים ביותר יביאו אותנו מהנקודה הנוכחית למצב טוב בהרבה בלי לבצע מהפיכות ובלי לאבד את הידע שנצבר בשיטות העבודה הקיימות ואת ההתאמה שלהן למציאות שאיתה מתמודדים.