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

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

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

בסוף התהליך ניסה עופר לשכנע אותי באוניברסליות של הניהול הרזה, והתאמתה לתחומים מחוץ לאולם הייצור, אפילו לפיתוח מוצרים.

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

האמת היא איפה שהוא באמצע. אם יורדים לעומקן של טכנולוגיות רבות בתחום התוכנה רואים שהן באות לייצר כלים שמאפשרים למה שקרוי היה “תכנתי ג’אווה” לייצר תוכנה באמצעות משימות פשוטות וחוזרות על עצמן (repetitive) נוסח הנרי פורד. לדוגמא, שיטת הMVC היא אחת האהובות עלי, אך אם תקראו הרבה מהספרים בנושא, תגלו הרבה עבודת copy-paste. ומאידך אחד הרעיונות של הייצור הרזה הוא בהכרה שהפועל הוא לא רובוט אלא הדבר הכי גמיש וחכם במפעל.

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

נהוג בניהול הרזה למיין כל פעולה לאחת משלוש אפשרויות:

• פעולה יוצרת ערך – כל דבר שהלקוח “מוכן לשלם עליו”. פעולה שמקדמת את התהליך.
• פעולה שאינה יוצרת ערך אך הכרחית – פעולות המונחתות מההנהלה או גורמי פיקוח אחרים.
• פעולה שאינה יוצרת ערך – כל דבר שאינו משנה את המוצר או האינפורמציה עליו אנו עובדים.

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

• ייצור עודף – יצירת פיצ’רים מעבר למה שהלקוח מבקש.  בדרך כלל אנו נוהגים לבלבל “הספק” עם “עבודה” ונוטים לשבח (ובמידה רבה בצדק) עובד עם הספק גבוהה. אך צריך לשים לב שהיכולת מופעלת רק ֿֿלמטרה יוצרת רווח. הדוגמה הקלאסית היא שייצור עודף מיצר מלאי, אותו צריך לאפסן ולנהל. לצורך כך צריך לשכור מחסן ועובדים. אלו זקוקים לדברים נוספים שיוצרים עומס נוסף ומתמשך ומעלים את העלויות. ומה לגבי מידע עודף ? מידע עודף בהחלט יכול לבלבל אותנו ולהסיט אותנו מקבלת ההחלטות הנכונות.
• המתנה ותורים – בעוד בעבר היה המכשול העיקרי פניות של מכונות הייצור, גם היום אנו נוטים לאבחן ולפתור “צווארי בקבוק”, אם כי בדר”כ מדובר במשאבים אנושיים, כגון מחלקת בדיקות או מומחים מסויימים.
• תעבורה ושינוע – מודבר  בהעברה של המוצר ממקום למקום. במקור הכוונה הייתה להימנע משברים ונזקים שיכולים להגרם למוצר תוך כדי המעבר שהוא בעיקרו “לא תורם ערך”. אך מה כבר יכול להגרם לקוד שלנו בעודו זורם ברשת הג’יגה-אולטרה-אורקולית שלנו ? האמת לא הרבה. אבל כן כדאי לשים לב שהמידע הנכון מגיע למקום הנכון בזמן הנכון (ארחיב בהמשך)
• עבודת יתר – כתוצאה מכלים לא טובים או תכנון לקוי. אפשר גם להוסיף דחיפה של טכנולוגיות “חמות” שמלהיבות את המהנדסים אך אינן תורמות ללקוח.
• מלאי – אומנם ניתן היום להתייחס בזלזול לעלות שמירת המידע (מנהלי IT שצריכים לבצע גיבוי יומי שבועי וחודשי בוודאי יתרגזו על אמירה זו). אבל מה לגבי איכסון תוכנה ? אני מקווה שיש לכם מערכת ניהול גרסאות ואתם משתמשים בה. הניהול שלה דורש משאבים, אך הם אינם גדלים משמעותית כשמאחסנים בה יותר. אך ככל שבסיס המידע גדל, כך כן גדל הסיכוי לבאגים ופרצות אבטחה.
• תנועות מיותרות – כל תזוזה של העובד שאינה תורמת במישרין למוצר הסופי. כמו פעולות הכנה שנדרשות בכדי שהמהנדס יוכל לבצע את עבודתו, הבאת ציוד ובירוקרטיה.
• תוצרת פגומה – כל דבר שבעתיד לא יתפקד בנדרש ממנו. במילה אחת – “באגים”

אחרי שזיהינו את הבעיות ננסה לפרוס את הפתרונות שמחולקים לשני עקרונות עיקריים: אוטומציה חכמה ו just in time.

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

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

• הקטנת גודל אצווה – כלומר לא לייצר הרבה, אלא אחד אחד ולהעביר לשלב הבא בשרשרת. בscrum קוראים לזה “ספרינטים” שמאפשרים עבודה בpipeline ויכולת התמודדות סבירה עם המנה. יתרון נוסף שנוצר הוא הגמישות לשינויים. פעמים רבות התכנתים היו מתלוננים שעושים להם הרבה task switching. אולם כאשר גודל כל משימה הוא קטן ניתן תמיד להמתין לסופה ותעדף מחדש את המשימות הבאות לפי הצורך.
• ייצור במשיכה – משמעותו שאין צורך ל”ייצר למלאי” אלא אך ורק כאשר הלקוח או השלב הבא בתהליך זקוק למוצר שלנו. וזה מה שקורה כאשר משתמשים בbehaviour driven development. קודם מגדירים מה הם הדרישות של הלקוח ורק אז מתחילים לקודד את (ורק את) מה שדרוש לו
• קאנבן – אולי אחד המושגים המפורסמים בתעשיה. משמעותו המילולית ביפאנית הוא “שלט” או “כרטיס” והכוונה היא לסימן ויזואלי פשוט שמסמן לנו שדרוש לבצע עבודה. שימוש במערכות bug tracking ו continuous integration מייצרת בדיוק את הרמזור הזה.
• 5S – קיצור ביפנית של “מיון, ארגון, נקיון, אחידות והמשכיות”. לא יחודי לשום תעשיה, אבל סביבת עבודה נקיה ומסודרת זה תמיד טוב.

מתחיל להשמע לכם מוכר ? אם נתקלתם אי פעם בפיתוח agile, אני מנחש שכן. הרבה מהרעיונות שלהם נלקחו מהמקורות ב lean. ולכן גם הפתרונות מזכירים אחד את השני. אבל מעניין להכיר את המקור כדי להבין מאיפה הגיעו הפתרונות.

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

• קאיזן – שיפור מתמיד. לא מספיק לבוא ללמד ב”זבנג וגמרנו” אלא צריך להמשיך ללוות, ללמוד ולהתקדם.

אז מה למדנו ?

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

כמו כן יש עוד בlean עוד כלים אחרים ורעיונות מעמיקים שרק גרדתי את הקצה. מעניין יהיה “להעמיק במקורות״ ולבחון אילו עוד הקבלות ומה עוד אפשר להשאיל לתחום התוכנה.

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