המנהל הטכנולוגי (CTOׂׂ) של CA Technologies: מתודולוגיית DevOps יכולה לצמצם "חובות טכניים" שמדכאים את החדשנות

פורסם: 10.3.15   צילום: יח"צ

מהו חוב טכני?

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

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

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

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

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

כיצד מתודולוגיית DevOps עוזרת לצמצם חוב טכני?

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

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

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

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

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

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

4. לא להעניק תמריצים שמעודדים הוצאה – אנשים נוטים להיכנס לחובות מפני שהם נכנעים לפיתויים, דוגמת 'הזמן היום וקבל כפליים נקודות נוסע מתמיד' או '0% ריבית בחצי השנה הראשונה' [ואחר כך ריבית נשך]. למרבה הצער, גם בפיתוח תוכנה נוטים לעתים קרובות לחלק 'גזרים' כאלה – תמריצים מפתים הקשורים למספר התפקודים, סיפורי המשתמשים או אפילו שורות הקוד שכותב המתכנת.

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

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

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

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

Tags:  חדשנות טכנולוגיה כלכלה פיננסים צרכנות