בזבוזים בתחום התוכנה

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