למה פרויקטי תוכנה נכשלים: 7 סיבות שאין להן קשר לקוד

בקצרה: כשפרויקט תוכנה נכשל, האינסטינקט הוא להאשים את הטכנולוגיה או את המפתחים. הנתונים מצביעים למקום אחר. במחקר CHAOS של Standish Group מ-1994, הסיבות המובילות לבעיות בפרויקטים היו מעט מדי מעורבות של משתמשים ודרישות חסרות או משתנות. מה שבאמת הורג פרויקטים הוא ארגוני: מקבלי החלטות שלא זמינים, היקף שגדל בלי סוף, לוחות זמנים אופטימיים וצוותים שמסתירים בשורות רעות. הפתרון הוא הרגלי עבודה טובים יותר.

אחוזי הכישלון שאף אחד לא אוהב לדבר עליהם

Standish Group עוקבת אחרי תוצאות של פרויקטים מאז דוח CHAOS הראשון ב-1994. המחקר הראשון מצא שרק 16.2% מפרויקטי התוכנה הסתיימו בזמן, בתקציב ועם כל הפיצ׳רים שתוכננו. עוד 52.7% איחרו, חרגו מהתקציב או נמסרו עם פחות ממה שתוכנן. ו-31.1% בוטלו לגמרי.

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

אלה שבעת הדפוסים שאנחנו פוגשים הכי הרבה ב-16 שנה של פיתוח תוכנה ב-Globalbit, ומה המחקר אומר עליהם.

1. אף אחד לא מחזיק בהחלטות המוצר

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

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

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

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

2. דרישות שמתארות פיצ׳רים במקום תוצאות

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

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

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

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

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

ככה הצוות מקבל בעיה לפתור, ולא רק רשימה לבנות.

3. אין תהליך לניהול שינויים

היקף שתופח בלי שליטה (Scope Creep) לא נופל מהשמיים. זו התוצאה הצפויה כשאין שום מנגנון לטיפול בשינויים.

מישהו בחברה רואה מתחרה משיק פיצ׳ר: "אפשר להוסיף גם את זה?" השיווק רוצה דף נחיתה שמחובר לאפליקציה. המנכ״ל ראה משהו בכנס. כל בקשה נראית קטנה. אף אחת מהן לא קטנה.

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

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

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

4. לוחות זמנים אופטימיים שאף אחד לא מתקן

"המפתחים אמרו שלושה חודשים, ההנהלה אמרה לדירקטוריון חודשיים, ועלינו לאוויר אחרי שבעה."

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

המחקר מאשר את זה. במחקר של Standish Group מ-1994, פרויקטים שנקלעו לבעיות לקחו בממוצע 222% מהזמן שהוערך ועלו 189% מהעלות שהוערכה. אלה לא טעויות של מפתחים. זו הערכת חסר שיטתית, שנובעת מלחץ ארגוני.

מה עובד: הערכה לפי פרויקטים דומים מהעבר, במקום רשימת משימות שנבנית מלמטה למעלה. אם שלושת הפרויקטים האחרונים שלכם, באותה מורכבות, לקחו חצי שנה, גם הבא כנראה ייקח חצי שנה, לא משנה מה אומר פירוק המשימות. הוסיפו מרווח ביטחון למה שעוד לא ידוע (15% עד 25% בעבודה מוכרת, 30% עד 50% בשטח חדש), ודברו על המרווח הזה בגלוי.

5. תקשורת שבורחת מבשורות רעות

הפרויקט באיחור. המפתח הראשי יודע. מנהל הפרויקט חושד. הלקוח לא יודע כלום.

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

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

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

6. בדיקות רק בסוף

"נבדוק בסוף." שתי מילים שהרסו יותר לוחות זמנים מכל בחירה טכנולוגית.

כשבודקים רק אחרי שהפיתוח "הסתיים", כל באג שנמצא פותח סבב של עבודה חוזרת. עבודה חוזרת בסוף הפרויקט עולה הרבה יותר מתיקון מוקדם של אותה בעיה. המחקר של NIST על בדיקות תוכנה מ-2002 נותן דוגמה: באג שעולה 1 לתקן בשלב הדרישות, עולה פי 5 בשלב כתיבת הקוד, פי 10 בבדיקות האינטגרציה ופי 30 אחרי השחרור.

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

החלופה היא לבדוק כל הזמן. Code Review על כל Pull Request. בדיקות אוטומטיות שרצות לפני כל מיזוג. QA מעורב מהספרינט הראשון. כשבנינו את מערכת העיצוב של ממשלת ישראל, תכננו את הנגישות בכל רכיב מההתחלה. אנשי QA ישבו בכל ספרינט מהיום הראשון ותפסו 80% מהבעיות לפני שהגיעו לסביבת ה-Staging. בזכות זה, כל אתר ממשלתי שנבנה עם המערכת עומד ב-WCAG 2.1 AA בלי עבודת נגישות נוספת.

7. אין תוכנית ליום שאחרי ההשקה

יום ההשקה הוא קו הזינוק, ולא קו הסיום.

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

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

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

המכנה המשותף לכל השבעה

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

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

שאלות נפוצות

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

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

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

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

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