עדה על IT איטי

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

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

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

1.    מורכבות מיותרת – מניסיוננו כמנהלים וכיועצים, וממחקרים שעורכים גופים שונים לאורך השנים, עולה כי במערכות תוכנה ייעודיות, לא יותר מ-2/3 מה-Feature-ים אכן דרושים, ומביאים ערך בתהליך העסקי בו הם תומכים. לעיתים קרובות, Feature-ים שפותחו לא רק שלא מביאים ערך, אלא גם לא נמצאים בשימוש. המורכבות המיותרת מונעת שימוש יעיל במערכות, ומגדילה את הצורך בהדרכה והטמעה. זאת, בנוסף למאמץ המיותר בתכנון, בפיתוח ובתחזוקה – מאמצים שניתן היה להשקיע בפעילות אחרת המביאה ערך. במונחי Lean, זהו בזבוז המזוהה כ-Over Processing, קרי לעשות יותר מאשר נדרש להבאת ערך ללקוח. יש סיבות מדוע זה קורה ונדון בהן במסגרת אחרת.

2.    איכות – שגיאות תכנון ותכנות מהוות בזבוז. מחקר שנערך על ידי אוניברסיטת קרנגי מלון בקרב 13 אלף מפתחי תוכנה העלה, כי מפתח מנוסה ומקצועי מייצר מעל 100 שגיאות תכנות בכל אלף שורות קוד. כתוצאה מכך, חלק ניכר מתקציבי הפרויקטים ומהזמן המושקע בהם, מוקצים לטיפול בתקלות שהם עצמם ייצרו. בנוסף לכמות האדירה של Rework, הולך לאיבוד זמן רב, נוצרים תסכולים ושחיקה, הפרעה ללקוחות ולביזנס וכמובן מאמץ משמעותי מאוד לספק תמיכה טכנית כשמתגלה תקלה. לכן, לא רק שחשוב מאוד לגלות ולתקן שגיאות קרוב ככל האפשר למקום היווצרותן, אלא שעלינו למנוע את היווצרותן של שגיאות ואת כניסתן לקוד, כמו גם למנוע את כניסת Feature-ים מיותרים לקוד מלכתחילה.

התופעות האלה ניתנות לטיפול ולצמצום תוך שימוש באחד העקרונות של Lean – ה-Quality at the Source. הבזבוז האדיר הזה של מורכבות מיותרת, שגיאות, עיכובים וגלישה בעלויות, קשורים באופן עקבי דווקא בשיטות פיתוח תוכנה קלאסיות, ואם תרצו – אפילו ב-Best Practices. מדוע?

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

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

מעבר לכך, גישה זו מחייבת השקעה גדולה בניהול פרויקט: תכנון לו"ז מפורט לפרויקט, דו"חות סטטוס ואתגרים מורכבים של ניהול משאבים נדונים בישיבות ארוכות, בהן הצוותים מנסים להתמודד עם המורכבות ועם עדיפויות מתחרות ומשאבים במחסור, בעודם מנסים לשמור על מספר פרויקטים במסלולם המתוכנן. זה מצב דומה מאוד לאולמות היצור מלפני 50 שנה, ולאתגרים שהניעו את הטרנספורמציה מייצור ב-Push לייצור ב-Pull ב-Lean Manufacturing.

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

לא ניתן לסמוך ב-100% על דרישות שהוגדרו על ידי המשתמשים, בין היתר מפני שהם מגנים על עצמם מפני זמני אספקה ארוכים. כשבקשה לפיתוח יוצאת לדרך, המשתמשים מכניסים לתוכה כל מה שעולה על דעתם, מפני שהם חוששים שההזדמנות הבאה שלהם תגיע בעוד חודשים רבים ואף שנים – אם בכלל. פרויקטים עם ספק חיצוני במחיר קבוע אף מעודדים נטייה זו. היות והתכולה כל כך רחבה, מי שמתכנן את הפרויקט לוקח לעצמו מקדמי ביטחון. כיון שמספר אנשים מעריכים את המאמץ הנדרש לפיתוח, הדרישה מתנפחת והזמן והעלות המוערכים נעשים גדולים מהנדרש בצורה משמעותית. מחזור החיים המורחב הזה בא על חשבון מהירות וגמישות: היכולת להגיב במהירות לתנאים משתנים ולשינויים בדרישות, נפגעת בצורה אנושה. בשל העובדה שתהליך הפיתוח הוא טורי, הוא הופך להיות מורכב וקשיח, ואינו יכול להתאים את עצמו לשינויים.

במונחי Lean Software Development, מערכת כזאת צברה "חוב טכני": זהו סוג של משא או עול של חומר מורכב ולא עדכני (אפיונים מפורטים שאינם עדכניים עוד, תוכנה שפותחה ולא נעשה בה שימוש) שיום אחד, כאשר יהיה צורך לבצע שינויים, יהיה צורך לשלם בגינו. בקונטקסט רחב יותר של Lean Enterprise Transformation, פיתוח תוכנה בפרקטיקה כזאת עוצר מאמצים לשיפור בתהליך העסקי, שלעיתים קרובות תלוי דווקא בשינויים קטנים ותכופים. Lean IT, ובכלל זה Lean Software Development, מציעים כלים מעשיים להתמודד עם המצב הזה ולשנותו.

עדה מרקמן, מנכ"לית משותפת ב-BDA – שותפה עסקית של HP בישראל, מספקת פתרונות ניהול פרויקטים לרבות יישום פתרון HP-PPM