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

אם ניזונים מהעיתונות אז גם כל הפרויקטים מצליחים...

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

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

1. שינויי דרישות מהותיים במהלך הפרויקט

מנתחי מערכות ומפתחים רואים את עצמם כגמישים לשינויים, לכן רובם מאמצים את גישת ה Agile.

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

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

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

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

2. בחירת טכנולוגיה לא מתאימה לביצוע הפרויקט

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

קחו את גרסת סביבת הפיתוח כמשל (net, Eclips., גרסת Angular וכד'). למפתחים יש נטייה עקבית להאמין שגרסת התוכנה החדשה תעלים את כל ערימת הבעיות הידועות, תוסיף המון פיצ'רים חדשים, תשפר את ביצועי המערכת, תשפר את אבטחת המידע, התקשורת ומעתה גם השינה בלילה תהיה ערבה יותר...

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

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

3. מחסור במפתחים

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

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

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

4. עודף מפתחים

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

חוק התפוקה השולית הפוחתת – במיטבו.

5. תעדוף שגוי

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

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

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

6. היעדר ארכיטקטורה נכונה (מראש ובכל שינוי)

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

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

7. חריגה מתקציב

כל פרויקט ניתן לעשות 1)מהר 2)איכותי 3)בזול. לא?

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

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

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

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

8. חריגה בעייתית מהלו"ז

כל פרויקט ניתן לעשות 1)מהר 2)איכותי 3)בזול. אמרנו כבר?

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

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

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

9. הקהל לא אוהד

פרויקט שבא לעולם על רקע פוליטי, יש לו סוף והוא בד"כ לא טוב.

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

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

10. זמן התגובה, לצורך חדש, איטי במיוחד

ואם כבר הגענו לקו הסיום, מבחינת המשתמש/הלקוח המערכת היא בתקופת ניסיון. כאשר סוף סוף הוא עובד עם המערכת הוא בד"כ מקבל תובנות חדשות (הגיוני שיקרה) ודורש מיד מספר שינויים, אולם אם אלה יבוששו גם – חבל.

אפשר לשפר? - אופטימיות זהירה

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

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

אז זהו, שיש: אחד הטרנדים החמים ביותר כיום הוא ה Low Code.

תחילת מעבר הארגונים לכלי Low Code, למשל Mendix - פלטפורמה המהווה מעין lowCode full-stack, או FlutterFlow המהווה ליזוק אדיר לממשק המשתמש עם קישוריות להמון סביבות עזר. פלטפורמות כאלה בהחלט בעלות בשורה. יש שיפור משמעותי המפחית את הסכנות לכישלון פרויקטים בכל אחד מהגורמים הנ"ל. החל מצמצום בכוח האדם הנדרש לביצוע פרויקט, קיצור משכו, הגמשתו לשינויים, הפחתת בעיות התחזוקה, הקטנת החשש מחריגה מהלו"ז או מהתקציב, שיפור דרמטי ביכולות השיתוף עם המשתמש/לקוח (בסיוע אב טיפוס במהירות שיא) ובעיית הטכנולוגיה (הגם שמדובר בטכנולוגיות המתקדמות ביותר), בעידן ב SaaS, היא כבר פחות במוקד תשומת הלב.

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

העדנה לה זוכים כלי ה Low Code שהם כבר כלי SaaS בשלים, המספקים ביצועים מצוינים, המאפשרים פיתוח ל Web ול Mobile באותה סביבה, וכוללים את כל ה (ALM (Application Life Cycle בכפיפה פשוטה אחת, באה מצד אחד על רקע הגורמים הרבים לכישלון פרויקטי תוכנה יחד עם הצורך הגובר בכלים להגברת הקצב של הטרנספורמציה הדיגיטלית.

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