ארגונים אף פעם לא "סובלים" ממחסור בצרכים חדשים, שירותים חדשים, מבצעים, חידושים ועדכונים. אבל ארגונים סובלים גם סובלים ממחסור ביכולת הפיתוח הנדרשת למילוי הצרכים והרעיונות החדשים שלפעמים הם קיומיים לעסק.
אחת הסיבות לכך היא הדרך האיטית והיקרה של הארגונים לפתח ולתחזק את הכלים/תוכנות העומדים מאחורי הצורך והקיום הארגוני.
יש המאמינים שהמעבר לפיתוח במתודולוגיית מודרניות כגון Scrum, Agile, CristalClear, מודל ספירלי ואחרות פותרת את הבעיה. אבל המציאות מראה אחרת, לגמרי אחרת, היחידות הטכנולוגיות ברוב הארגונים פשוט קורסות תחת כמות הדרישות, ועולם הטרנספורמציה הדיגיטלית רק מגביר את קצב הדרישה.
משום כך, אט אט מחלחלת ההכרה שהפיתוח חייב להיות מהיר. ובעצם רק ארגון שיש לו יכולת להתאים את עצמו במהירות לצרכים (=יכולת פיתוח תואמת לצרכיו המיידיים) יש לו כרטיס כניסה לעידן הדיגיטלי.
כשמדברים על פיתוח מהיר, האם נכון לפתח מהר בכל מחיר? האם זה נכון להרחיב את החוב הטכני?
מהו חוב טכני?
רבים מביננו שעוסקים בהקמה ותחזוקה של מערכות מכירים את הדילמה הבאה: חייבים לתקן או להכניס שינוי דחוף למערכת. הדרך הרצויה היא לנתח את השינוי לעומקו, את כל ההשלכות ולשנות בכל המקומות
הנדרשים, לבדוק ולהטמיע. דרך אחרת היא לעשות שינוי בסגנון Quick&Dirty שעונה על ההכרח בשינוי מהיר ולמקד את השינוי בקוד אך ורק במינימום ההכרחי בכדי שהארגון יוכל להתקדם. במה הארגון בד"כ בוחר? כמובן בדרך הקצרה. ואז, בדומה לחוב כספי הצובר ריבית, נוצר חוב טכני שגדל בריבית דריבית. זאת מאחר וחלקים גדלים והולכים במערכות שלנו, אינם פועלים בלוגיקה אחודה, או הרצויה ובוודאי שלא בלוגיקה המעודכנת. יתר על כן, קוד ישן, שאינו מתוחזק, מגדיל את החוב מאחר והמפתחים כבר לא מכירים אותו וחזקה עלינו שהקוד הישן מקומפל עם גרסה ישנה של הקומפיילר אשר לא תומכת בגרסה החדשה של בסיסי הנתונים ולכן אסור לשדרג את מערכת ההפעלה או להריץ עדכוני תוכנה ו...כך בעצם אנו מגיעים עם הגב לקיר ולפעמים תקלה קטנה, או שינוי קטן, יהוו את הקש ששובר את גב הגמל ונהייה חייבים לצאת לפרויקט החלפה גדול (והכל בגלל שיני קטן...).
חוב טכני: הפער בין המצב בו המערכות מתוחזקות ומעודכנות באופן אופטימלי (בכדי למקסם את אורך החיים שלהן בארגון), לבין המצב הקיים בפועל.
כיום קצב השינוי גובר, כמות הכלים בכל ארגון עולה וכוח האדם הטכנולוגי מתייקר ומעדיף לעבוד בחברות מוצר (מאחר ובחברות המוצר השכר לאנשי הפיתוח גבוה). החוב הטכני של ארגוני ה IT - גדל.
והחוב גדל ככל שהשינויים הארגוניים גדלים (משול לקרן בהלוואה פיננסית) וצמוד לקצב ההתקדמות הטכנולוגית (משול לריבית).
יש הטוענים שגידול בחוב הטכני בסך הכל הוא חיובי, מאחר והוא גורם להחלפה תכופה יותר של מערכות, אלה שוכחים שייעודן של המערכות והאגפים הטכנולוגיים הוא לשרת את הארגון ולא להיפך.
המצבים בהם אנחנו נאלצים לוותר על עקרונות העבודה הנכונה:
ארגון אינו מיקשה אחת. הוא מורכב מאנשים שונים, בעלי דעות שונות, מערכות שונות, בד"כ מספר מוצרים וקהלי לקוחות מגוונים.מכאן, שבחיי היום יום יש כמה לחצים הפועלים בכיוון ההפוך למערך מחשוב אחיד ומסודר:
התחרות והמאמץ להשיג את הלקוח הבא מביאים חדשות לבקרים שינויים.
תחלופת כח אדם מקצועי וניהול (המשנים את הגישה המקצועית, את הספקים, את הידע הקיים בארגון, את היכולות, את סדר היום המקצועי).
שינויים טכנולוגיים (שדרוגים של חומרה, מערכות הפעלה, VM, קומפיילר, מערכת שכנה, כלי ממשק, בסיס נתונים ועוד).
רגולציה ואבטחת מידע.
לחצים אלה אינם פוסחים על אף ארגון. השאלה: האם הארגון המודע לכך, יש דרכים להתארגן נכון יותר?
איך Low Code (תשתית לפיתוח מהיר או תפ"מ) תקל על הבעיה?
אם נניח שכל שינוי נדרש, יקרה כהרף עין, הרי שבעיית החוב הטכני נעלמה.
אבל לדאבונינו, הפיזיקה היא אותה פיזיקה ושינוי הנדרש לביצוע בכלים הארגוניים הקיימים, לוקח זמן.
אבל אם נעשה אותו מהר יותר, הוא יכאב פחות! מאחר והחוב הטכני יקטן.
אם יהיה קל יותר לשנות את המערכות - החוב הטכני יקטן.
אם תהיינה פחות תקלות קוד (כי מראש כותבים פחות קוד) - החוב הטכני יקטן.
אם זמן ההכשרה של כוח האדם הנדרש לביצוע פיתוח, תחזוקה או שינוי - החוב הטכני יקטן.
אם פיתוח מחדש פתאום קצר יותר מתחזוקה של מערכת ישנה - החוב הטכני יקטן.
כאן באים כלי התשתית לפיתוח מהיר או כלי ה low Code, לעזרתינו. בדור החדש של כלים אלה, זמן הפיתוח קצר משמעותית. הכשרת כ"א קצרה, תנאי הסף למפתח נמוכים יותר, כמות הכ"א קטנה יותר, זמן התגובה לשינוי רוחבי קצר.
היבט מערכתי/תשתיתי:
בגל החדש של כלי הפיתוח המהיר, רוב הכלים הם שוכני ענן. מה שמבטיח שכלים אלה אמורים by design, לטפל בבעיות ריבוי משתמשים, עומסים וביצועים. כמו כן מחשוב בענן מוריד חלק מהנטל הרגולטורי הרובץ על הארגון להסכם השירות עם הספק. יתר על כן, תחזוקת החומרה והתוכנות, שדרוג רכיבי התוכנה הרבים הן משימות העוברות מהארגון אל ספק השירות המומחה.
כך שללא פגיעה בתפקוד המערכת - כל אלה מטופלים בעזרת ספק השירות. והארגון... יכול להתמקד רק בצורך שלו.
אין הכוונה לצייר את שירותי הענן בצבעים ורודים בלבד, אבל חייבים להדגיש את היתרונות הבאים עם מחשוב הענן והרלוונטיות שלהם לחוב הטכני.
היבט ליבתי:
לב העניין הוא המעבר בין "זו התוכנה שיש לנו - ננסה להתאים אותה עבורך" לבין "מ
ה אתה צריך? נתפור לך במהירות"
כך למשל מצוטט פיליפ אוגור, הCOO של חברת Arch Re המציעה ביטוחי משנה אשר על ידי פורטל הכתוב בתשתית לפיתוח מהיר, המציאה את עצמה מחדש ונתנה ללקוח כלי המאפשר ללקוח לעצב לעצמו את הביטוח כנגד הסיכון שלו, באמצעות הפורטל. "מחזור החיים של הפיתוח (באמצעות Low Code ) היה הקצר ביותר שראיתי בכל הקריירה שלי"
כאשר ה Time To Market של כל פתרון מהיר בערך פי עשרה (בהנחה שמשווים בין אותם מפתחים בעלי אותם יכולות) הפיתוח על גבי Low Code, לא מעלים את החוב הטכני, אבל בהחלט מצמצם אותו משמעותית.
זאת מאחר ועבודה בכלים גרפיים היא לא רק מהירה לפיתוח, אלא ובעיקר, קלה מאד לתחזוקה. והמחיר של פיתוח מבראשית, הוא לא כל כך מפחיד.
כך שצמצום זמן הפיתוח, הוא בהחלט האופציה המתבקשת לצמצום החוב הטכני.
התנגדות המפתחים או "מאיפה זורחת השמש?"
יש פיל בחדר... בכל ארגון יש את המפתחים ש"בלעדיהם הארגון לא ישרוד". ואותם מפתחים שרואים זהות מלאה בינם לבין הארגון, לרוב חוששים משינוי שייתכן ויקח את השליטה מידיהם.
הרי אם המסה הגדולה של הפיתוח היא מהירה ופוחתת התלות בהם, למה שיתנו יד לשינוי?
כך, הם הם הופכים לבעיה במקום לפתרון.
בשום ארגון לא אוהבים לדבר על זה, אבל כולם מכירים את הבעיה הזו.
איך פותרים את זה? ראשית, שמים באומץ את הבעיה על השולחן. מכאן הדרך לפתרון קצרה.
שנית, כל מפתח אמיתי שיבין את הכוח האדיר שיש לו עם כלים כאלה, לאחר פרויקט אחד - לא יסתכל אחורה.
צמצום החוב הטכני אשר מבוסס על Low Code יבוסס בכלים המאפשרים:
פיתוח גרפי, מהיר ואינטואיטיבי. פרוייקטים הגדולים פי 10 עם אותו כח אדם. הכשרה מהירה.
מחזורי חיים (מהצורך עד להשקה) קצרים בסדר גודל. אפשרות להתנער מהתחזוקה האין סופית של כל המרכיבים. עמידה ברגולציה. פיתוח ל Web ולמוביל בסביבה אחת.
פיתוח ללא פשרה בביצועים.
בדיקה מהירה ואוטומטית של התוכנה.
לפיכך,
המהלך המתבקש הוא לעבור בהדרגה לתשתיות פיתוח מהיר, Low Code, ובכך לא רק להפחית את החוב הטכני אלא ובעיקר נסייע לארגון לעמוד ביעדיו.
Comments