חלק א: IT איטי
במאמר זה נסקור את המצב בארגונים רבים, בהם למרות העבודה המשותפת עם ה-Business , ה-IT נתפס כאיטי, לא אפקטיבי ואינו משרת את ה-Business במידה מספקת. נראה כיצד שיטות ניהול פרויקטים ופיתוח תוכנה קלאסיות גרמו לכך וכיצד ניתן לשנות את המצב בצורה יסודית לאור עקרונות Lean .
במשך השנים האחרונות שומעים הרבה מאוד את הטענה : ה-IT צריך להיות מחובר ל-Business . למעשה במרבית הארגונים יש חיבור טוב ל-Businessלפחות בהיבט של תעדוף משימות, בניית תכנית עבודה וקבלת אישורים לאפיונים ולפתרונות המתוכננים על ידי אנשי IT.
במרבית החברות אנשי ה-Business מכתיבים את תכולת תכנית העבודה ובמידה רבה גם את הדרישות הפונקציונליות , אבל מסתבר שזה עדיין רחוק מלהיות משביע רצון.
באין סוף סקרים ומחקרים אנשי ה-Businessמביעים דעה נחרצת שה-IT אינו מביא את הערך המצופה, שזמני התגובה שלו לא מתאימם לציפיות של ה-Business , שהוא יקר וכבד ובשורה התחתונה שה-IT אינו מצליח להיות גורם בעל ערך עסקי ותחרותי.
התחושה הזאת נובעת בין היתר מהזמן הארוך העובר מרגע הבקשה של הגורם העסקי ועד לקבלת התוצר (בד"כ חודשים) , לעיתים ללא כל פרופורציה למשאבים הנדרשים לביצוע (שעות – ימים ספורים ). כמו כן קיים תסכול רב מהעלויות הגבוהות של פרויקטים ושל התפעול והתחזוקה השוטפת של מרכזי מחשוב.
והסיבות כרוכות בין היתר בבזבוז עצום הכרוך בשיטות העבודה שאימצנו במשך השנים :
1. מורכבות מיותרת : מנסיוננו כמנהלים וכיועצים , וממחקרים שעורכים גופים שונים לאורך השנים עולה כי במערכות תוכנה ייעודיות, לא יותר מ- 2/3 מה-Features אכן דרושים , ומביאים ערך בתהליך העסקי בו הם תומכים. לעיתים קרובות Feature –ים שפותחו לא רק שלא מביאים ערך אלא גם לא נמצאים בשימוש. המורכבות המיותרת מונעת שימוש יעיל במערכות, ומגדילה את הצורך בהדרכה והטמעה. זאת בנוסף למאמץ המיותר בתכנון, פיתוח ותחזוקה, מאמצים שניתן היה להשקיע בפעילות אחרת המביאה ערך. במונחי לין זהו בזבוז המזוהה כ-Overprocessing – לעשות יותר מאשר נדרש להבאת ערך ללקוח. יש סיבות מדוע זה קורה ולא נדון בהן כאן.
2. איכות : שגיאות תכנון ותכנות מהוות בזבוז. לפי מחקר שנערך ע"י אוניברסיטת קרנגי מלון בקרב 13,000 מפתחי תוכנה, מפתח מנוסה ומקצועי מייצר מעל 100 שגיאות תכנות בכל אלף שורות קוד. כתוצאה מכך חלק ניכר מתקציבי הפרויקטים ומהזמן המושקע בהם – מוקצים לטיפול בתקלות שהם עצמם ייצרו . בנוסף לכמות האדירה של Rework , הולך לאיבוד זמן רב, נוצרים תסכולים ושחיקה, הפרעה ללקוחות ול- Businessוכמובן מאמץ משמעותי מאוד לספק תמיכה טכנית כשמתגלה תקלה. לא רק שחשוב מאוד לגלות ולתקן שגיאות קרוב ככל האפשר למקום היווצרותן, אלא שעלינו למנוע את היווצרותן של שגיאות ואת כניסתן לקוד, כמו גם למנוע את כניסתFeaturesמיותרים לקוד לכתחילה. התופעות האלה ניתנות לטיפול ולצמצום תוך שימוש באחד העקרונות של Lean- Quality at the Source.
מדוע הבזבוז האדיר הזה של מורכבות מיותרת , שגיאות , עיכובים וגלישה בעלויות קשורים באופן עקבי דווקא בשיטות פיתוח תוכנה קלאסיות ?
בזבוז מהווה לעיתים קרובות חלק בלתי נפרד ממנטליות של ייצור המוני, המוכרת לנו כגישת מפל המים. בשיטה זו הזמן בין הבקשה הראשונית של הלקוח ואספקת תוצר עובד הוא כל כך ארוך (חודשים ואף שנים) , מפני שאצוות גדולות של שינויים בתוכנה מאורגנות בצורה קפדנית לגרסאות. זה אנלוגי לייצור המוני ולגישה של אצוות ותורים, גישה המטופלת מזה שנים רבות על ידי Lean Manufacturing.
כאשר מצטברת כמות גדולה של קוד, שאינו בדוק ואינו מושלם (מלאי בתהליך), שגיאות סמויות חודרות למערכות. מכיוון שהפרויקטים הינם ארוכים למדי, מפתחים ובמיוחד אלה בעלי התמחויות נדרשות , חולקים את זמנם בין פרויקטים שונים ותמיכה במערכות בסביבת הייצור, עובדים ב- Modeשל Interruptions , עוברים ממשימה למשימה, מהווים צוואר בקבוק ומייצרים עוד שגיאות.
מעבר לכך, גישה זו מחייבת השקעה גדולה בניהול פרויקט : תכנון לו"ז מפורט לפרויקט, דוחות סטטוס ואתגרים מורכבים של ניהול משאבים נדונים בישיבות סטטוס אינסופיות, בהן הצוותים מנסים להתמודד עם המורכבות ועם עדיפויות מתחרות ומשאבים במחסור, בעודם מנסים לשמור על מספר פרויקטים במסלולם המתוכנן. זה מצב דומה מאוד לאולמות היצור של לפני 50 שנה, ולאתגרים שהניעו את הטרנספורמציה מייצור ב-Push לייצור ב-Pull ב-Lean Manufacturing.
כאשר הלקוחות בודקים מערכת לפני שהיא עוברת לסביבת הייצור, הם בסופו של דבר אמורים לוודא שקבלו את מה שהם צריכים. אלא מה, לעיתים קרובות מה שהלקוח ביקש הוא לא מה שהוא באמת צריך. בשל הזמן הארוך שעבר, סביר שהדרישות השתנו ואנו מגיעים שוב לצורך ב-Rework, לעלויות נוספות, לדחיות ובעיקר ללקוחות לא מרוצים.
לא ניתן לסמוך ב-100% על דרישות שהוגדרו על ידי המשתמשים בין היתר מפני שהם מגנים על עצמם מזמני אספקה ארוכים. כשבקשה לפיתוח יוצאת לדרך, המשתמשים מכניסים לתוכה כל מה שעולה על דעתם, מפני שהם חוששים שההזדמנות הבאה שלהם תגיע בעוד חודשים רבים ואף שנים אם בכלל. פרויקטים עם ספק חיצוני במחיר קבוע אף מעודדים נטייה זו. היות והתכולה כל כך רחבה, מי שמתכנן את הפרויקט לוקח לעצמו מקדמי ביטחון. כיון שמספר אנשים מעריכים את המאמץ הנדרש לפיתוח, הדרישה מתנפחת והזמן והעלות המוערכים נעשים גדולים מהנדרש בצורה משמעותית.
מחזור החיים המורחב הזה הוא על חשבון מהירות וגמישות: היכולת להגיב במהירות לתנאים משתנים ולשינויים בדרישות נפגעת בצורה אנושה. בשל העובדה שתהליך הפיתוח הוא טורי, הוא הופך להיות מורכב וקשיח , ואינו יכול להתאים את עצמו לשינויים.
במונחי Lean Software Developmentמערכת כזאת צברה "חוב טכני" : זהו סוג של משא או עול של חומר מורכב ולא עדכני (אפיונים מפורטים שאינם עדכניים עוד, תוכנה שפותחה ולא נעשה בה שימוש) שיום אחד, כאשר יהיה צורך לבצע שינויים, יהיה צורך לשלם בגינו . בקונטקסט רחב יותר של Lean Enterprise Transformation, פיתוח תוכנה בפרקטיקה כזאת עוצר מאמצים לשיפור בתהליך העסקי, שלעיתים קרובות תלוי בשינויים קטנים ותכופים.
Lean-IT ובכלל זה Lean Software Development מציעים כלים מעשיים להתמודד עם המצב הזה ולשנותו.
חלק ב: עקרונות Lean Software Development
במאמר זה נסקור את עקרונות Lean Software Development , כיצד הם קשורים לעקרונות Lean Manufacturing בפרט ול- Lean Management בכלל, וחשיבות הניסוי והלמידה שהם בבסיס המתודולוגיה, בשונה ממתודולוגית קלאסיות המדגישות תכנון פרטני Top Down ובקרה קפדנית וקשיחה.
Lean Software Development מתחיל בעקרון פשוט : זהה את 20% של הקוד שיספקו 80% מהערך, וספק אותם מהר ככל האפשר. Lean Software Developmentמדגיש תזמון Pullבמקום Push , כאשר מערבים את הלקוח בהגדרת דרישות ובבדיקות בכל איטרציה.
הרעיון הוא שפיתוח תוכנה איננו תהליך ייצור סטנדרטי – חו"ג --> תהליך --> תוצרים, אלא פעילות של פתרון בעיות ולמידה החוזרת על עצמה.
מתודולוגיה אפקטיבית לפיתוח תוכנה צריכה לטפח סביבה בה פתרונות ורעיונות מתגלים בצורה טבעית ומהירה, וה-Designהמחייב , שלאורו מבצעים את הפיתוח, נדחה עד לרגע האחרון האפשרי כדי לאפשר למידה ושינויים.
Lean Software Development אינו עובד על פי רשימות תיוג , ולו"ז של פיקוד ושליטה, אלא בגישה בה חברי הצוות לומדים לפתור בעיות בעצמם ובמהירות, תוך שיתוף, ניסוי וקבלת משוב. זו שיטה עדיפה על פני ניסיון להגיע לפתרון האולטימטיבי בפעם הראשונה.
באופן פרדוקסלי מדיניות של 0 תקלות ושגיאות מוקדם מדי במחזור החיים עוצרת יצירתיות , למידה והתנסות.
כאשר ארגונים מתמודדים עם אתגרים מורכבים של פיתוח תוכנה , הם נוטים לכפות על הארגון תהליכים יותר ויותר סדורים, עם עבודה טורית יותר ויותר קשיחה. זה בד"כ רק מחמיר את הבעיה.
במקום מפל מים נמשך לאורך זמן עם ניהול פרויקטים קשיח, Lean Software Development מסתמך על איטרציות מהירות (טקטים, ספרינטים) כאשר כל ספרינט מהווה הזדמנות לצוות וללקוח לקבל החלטות בהתבסס על תוצאות הסבב הקודם. כל איטרציה היא מעגל שלם של PDCA – Plan Do Check Actבו פותרים בעיות .
מאיטרציה לאיטרציה מכווננים את תהליך הפיתוח כך שמשפרים פרמטרים חשובים כגון מהירות, איכות, עלות וגמישות לאורך שרשרת הערך . זהו תהליך דומה לזה שמתרחש כאשר מפעל ייצור עובר מייצור המוני לייצור באצוות קטנות ומתקדם לעבר ייצור ב- One Piece Flow.
בסבבים שונים מנתחים את שרשרת הערך ובודקים כיצד ניתן בכל שלב להגדיל ערך ללקוח הסופי, ולהקטין את ההשקעה הנדרשת תוך צמצום ואף ביטול של פעילות שאינה מביאה ערך.
תהליך כזה מחייב שיפור ושכלול של קו הייצור , בכל איטרציה מנסים לקצר את זמן ה-Setup בצורה משמעותית ואיתו את זמני ההתקנות והאינטגרציה וכך מתאפשר לבצע שינויים קטנים ביעילות מבלי להפריע ל- Business .
יתכן ש- Lean Software Developmentהינו תהליך ה-One Piece Flowהמנוסה והמוכח ביותר: חברות כמו Google, שלקוחותיהן בעולם התרגלו ליהנות מחידושים תכופים ומפתיעים המוטמעים בתוכנה באופן חלק , משחררות גרסאות לעיתים ברמה יומית. מעובדי Google מצופה להקדיש כ-20% מזמנם לחפש רעיונות חדשים בדומה למהנדסי חברת 3M החדשנית. השקעת זמן זו הינה מניע אסטרטגי חשוב המסייע לשיפור המוצר ולגידול בכמות הלקוחות.
מהנדסי Googleעוקבים ברמה יומית אחר דפוסי השימוש של לקוחות במוצר, ומנחים את הפיתוח העתידי על בסיס מידע מוצק אודות Feature –ים ופונקציונליות פופולריים ונחוצים – Voice of the customer – עיקרון נוסף של Lean.
השינויים הקטנים והתכופים המונעים על ידי התנהגות הלקוחות ממומשים בשטח לעיתים תוך ימים או שבועות , בד"כ מבלי להכריז עליהם בתרועת חצוצרות ובמינימום הפרעה לשירות.
ניתן לשאוב השראה מאופן הפעולה של Google ואף ברור שהלקוחות מפתחים ציפיות לסטנדרטים דומים מהתוכנה העסקית והארגונית בה הם משתמשים. אם תוכנה כמו Googleבה משתמשים מיליונים רבים של אנשים בכל העולם יכולה להתפתח במהירות ולהגיע לשולחנו של הלקוח הלא מיומן באופן שהוא יכול להפעיל אותה ללא הדרכה, והכנסת השינויים אינה מחייבת השבתה או זמני פיתוח ארוכים – גם מתוכנה ארגונית מצפים להתקרב לסטנדרטים האלה, וזה ניתן ואפשרי.