בחלק א' התמקדנו בהימנעות מטעויות בהחזרת חוב טכני. היום נעסוק בצד החיובי – איך (כן) מחזירים חוב טכני?
איך (כן) מחזירים חוב טכני?
בגדול, יש שלושה אלמנטים חשובים בטיפול בחוב טכני:
• זיהוי החוב הטכני, וסיווגו ע"פ השפעה על המערכת / הארגון.
• שיקוף ושיתוף החוב הטכני, לחלקים שונים בארגון.
• מציאת המנגנון הארגוני לצמצום חוב טכני.
חוב טכני תמיד יגדל (עוד קוד נוסף, הביזנס משתנה, המערכת גדלה ונעשית מורכבת, הקוד מתיישן ו"נרקב") - וחשוב להוריד אותו בקצב שקול לגדילה - על מנת, לפחות, להישאר במקום.
כארכיטקטים, או מובילים טכניים בארגון, עליכם להתכונן כ"שבט של ציידים": להתכונן לשעת כושר, וכשהיא מגיעה - לנצל ממנה את המיטב.
הציד הוא דליל רוב ימות השנה, וחשוב להתמודד עם המחסור.
אבל מידי פעם, יעבור באזור עדר גדול של בפאלו נודד. שבט שמתחיל לפעול רק כאשר העדר כבר הגיע - לא ישרוד לאורך זמן. עליו להיות מוכן ליום הזה, ולנצל את ההזדמנות ברגע שהגיעה - עד תום.
באופן דומה, הזדמנויות לצמצום החוב הטכני, לא נופלות מהשמיים, ולא כל ימות השנה. עליכם להיות מוכנים עם תוכנית אופרטיבית - שכאשר יש הזדמנות ("אוי - יש לנו מפתח פנוי בחודש הקרוב"), אנחנו יודעים בדיוק מה לעשות, יש לנו מגוון אפשרויות - ואנו יכולים להפיק מההזדמנות את המירב.
ניהול "רשימת בעיות":
• כל פעם שאני מבין שיש פה חוב טכני בעייתי שארגון סובל בגללו (או שעומד להיות) - אני מוסיף אותו לרשימה.
• מדי פעם בצורה פרואקטיבית - אני יושב עם המפתחים הוותיקים, מעדכן ומתקנן את הרשימה.
• את הרשימה חשוב לתעדף. אם יש לרשות הארגון מפתח זמין לחודש, עדיף מאוד שיפתור בעיה חמורה שהנזק ממנה ברור - מאשר "לסדר קצת את הקוד". יצירת Impact חיובי הוא גם מפתח על מנת שהארגון ימשיך וירצה להשקיע בצמצום חובות טכניים בעתיד.
• אם יש בעיה ללא פתרון - זה לא עוזר. לפחות למספיק מהבעיות - חשוב שיהיה פתרון ידוע. אם צריך להשקיע ב Design - השקיעו מדגמית בכמה עניינים חשובים באזורים שונים. אי אפשר לדעת באיזה אזור של המערכת "יעבור עדר הבאפלו".
השיקוף של הבעיות - הוא חשוב מאוד גם כן. גם לצד ההנהלה, וגם לצד המפתחים:
• אם ההנהלה לא יודעת שיש בעיות חמורות, זה לא הוגן ולא אחראי. היא לא תדע להקצות את המשאבים (שתמיד נמצאים במחסור) בכדי להתמודד עם הבעיה.
• אם המפתחים לא מבינים שדברים מסוימים מהווים בעיה חמורה - הם לא ידעו לצמצם ולהגביל את הבעיה. מכירים את ה-Anti-Pattern של "שכפול Anti-Patterns במערכת"?
• אם אתם לא מבינים את הבעיה, איך המפתחים לא יתקנו אתכם ויסבירו לכם - אם לא תדברו איתם על זה. תנו להם הזדמנות לתקן אתכם, ולחסוך לכם חוסר-נעימות.
מציאת המנגנון הארגוני לטיפול בבעיה:
זה לפעמים החלק הכי קשה, ואני מקווה עבורכם שזו לא "הבעיה שעל כתפכם בלבד".
בחלק הבא (והאחרון) נעסוק בה קצת יותר בהרחבה.
רשימה לדוגמה של חובות טכניים שיש לפתור במערכת.
הרשימה רק תלך ותתארך, אז חשוב כל הזמן לפתור בעיות, לבדוק אלו עדיין רלוונטיות, ולתעדף.
הרשימה רק תלך ותתארך, אז חשוב כל הזמן לפתור בעיות, לבדוק אלו עדיין רלוונטיות, ולתעדף.
מציאת המנגנון הארגוני לצמצום חובות טכניים
תפיסה נפוצה (נתקלתי בה כבר מספר פעמים) היא שיש להקצות זמן נתון (הכלל המקובל: כ-20% בזמן העבודה) לצמצום חובות טכניים.
גישת הצוות:
ברוח ה-Empowerment (עניין מבורך) מורים לכל צוות להקצות את הזמן שלו - מבלי שישתף את שאר הארגון כיצד הוא מנצל אותו.
• כאשר המשאבים הם מקומיים (ברמת הצוות) - קשה עד בלתי אפשרי לפתור את הבעיות הגדולות.
• כבר נתקלתי לא-פעם בצוותים שניצלו את רוב הזמן שניתן להם בכדי לנסות טכנולוגיות "חדשות ומגניבות" שלא עשו שום השפעה חיובית משמעותית על המערכת או הארגון. זה בטח טוב לריצוי עובדים - ברמה כלשהי.
הגישה הגלובאלית:
גם כאשר הזמן המוקצה לצמצום חובות טכניים הוא "גלובאלי" (משותף לכל ארגון הפיתוח) - חשוב מאוד כיצד הוא מתוקשר ומנוהל.
לא פעם ראיתי שהוא תוקשר בצורה כזו שאנשי המוצר הרגישו ש"גוזלים מהם מזמן הפיתוח, בלי הצדקה" (מילים שלי).
למשל: בכל תוכניות העבודה מציגים 20% זמן טכני - ואנשי המוצר מתחלקים הזמן הנותר. זה נשמע כמו רעיון טוב על מנת להסביר מדוע לא כל המפתחים עובדים כל הזמן על משימות מוצר, אבל עלול בקלות לגרום לתחושה של אובדן משאבים מצד אנשי המוצר.
תגובה טיפוסית לתחושה כזו, היא לנסות ולהעמיס על "זמן החזרת החוב הטכני" כל מאמץ אפשרי: תיקוני באגים, כתיבת בדיקות-יחידה, או קבלת חובות טכניים במופגן - בידיעה שהם יכוסו מתקציב אחר. זה אף פעם לא מתחיל כך, אך זה בקלות עלול להתדרדר לשם לאורך הזמן. משאבי-פיתוח הם משאב יקר ערך בארגונים, ורק טבעי שברגע שיש "תקציב חדש" - רבים ינסו לנגוס בנתח ממנו להשגת היעדים הארגוניים שהם אמונים עליהם.
יתירות בפיתוח:
רעיון אחד שנתקלתי בו הוא הרעיון שיתירות בפיתוח (כלומר: יש יותר מפתחים ממה שצריך) - יאפשר לטפל בחוב טכני בצורה טבעית. זה רעיון הגיוני לוגית - אך לא ראיתי אותו אף פעם קורה בפועל:
• כל עוד איש מוצר יכול, בעזרת מצגת שהכין בשעתיים, ליצר עבודה לצוות פיתוח לחודשיים - לא יהיה לעולם זמן פיתוח "יתיר".
• עוד נקודת מפתח והיא יוקרה של צמצום חובות טכניים בארגון: כל עוד מירב מקבלי-ההחלטות בארגון מעריכים יותר פיצ'ר חדש מתיקון של חובות טכניים - הזמן שהוקצה להתמודדות עם חובות טכניים "יזלוג" לכיוון פיתוח פיצ'רים. כאן הפתרון הוא שיקוף יעיל של הבעיות הטכניות (עניין שהזכרנו קודם):
• חשוב שלמקבלי ההחלטות יהיה מושג על בעיות קיימות - ומה ההשפעה השלילית שלהן. הם לא יוכלו להבין את רוב הבעיות הטכניות - אבל כמה דוגמאות משמעותיות עשויות לעשות את ההבדל בתפיסה.
• חשוב שמקבלי ההחלטות יראו גם שבעיות נפתרות, או לפחות יחושו בצורה כלשהי שיש תרומה לחברה מתוך עיסוק בצמצום חובות טכניים (למשל: לשתף מכתב תודה של יחידה אחרת בארגון שסבלה מבעיה כלשהי).
• שיקוף אפשרי בעיקר לבעיות שנוגעות גם לביזנס בצורה ישירה (downtime, אטיות, פגעי-אבטחה), וחשוב לנצל תיקון של בעיות על מנת להדגים את החשיבות במערכת שלא רק כתובה - אלא גם כתובה נכון.
הבחנה חשובה היא בין חוב טכני "טוב" ו"רע":
חוב טכני קצר טווח - הוא פעמים רבות שימושי ומועיל. למשל: מיקוד בשחרור מוקדם ולמידה.
חוב טכני משמעותי ושנמשך לאורך זמן - הוא לרוב "רע"
חוב טכני קצר טווח - הוא פעמים רבות שימושי ומועיל. למשל: מיקוד בשחרור מוקדם ולמידה.
חוב טכני משמעותי ושנמשך לאורך זמן - הוא לרוב "רע"
לפעול במהירות ובנחישות:
גישה שעשויה לעבוד עבור מגוון מקרים היא ניהול פנימי של החוב הטכני בתוך הפיתוח: מיד בסוף הפיצ'ר מקדישים כמה ימים על מנת "לנקות חובות" ולשפר את הקוד היכן שצריך.
• לפעמים זה חצי יום - ולפעמים שבועיים.
• לא מדווחים על סיום המשימה עד שלא מסיימים את החובות הטכניים המיידיים. מסבירים שיש עוד כמה צעדים טכניים נדרשים לסיום המשימה.
• נקודת מפתח להצלחה היא מחויבות עמוקה של מנהלי הפיתוח, והיכולת שלהם לעמוד בלחצים מצד אנשי המוצר. אף אחד לא שמח לשמוח על פיצ'ר שמתעכב בשבועיים (גם אם שוחרר כרגע, ויש רק עוד סדרת תיקונים נדרשת).
• בארגונים מסוימים - עדיף לא לשקף לאנשי המוצר לאן הזמן בדיוק הולך. אולי רק בצורה ראקטיבית לשאלות.
• בארגונים שבהם יש יותר אמון הדדי - שווה לשקף, אבל להיזהר ולהסביר את ההשקעה בצורה שתבנה אמון עם היחידות העסקיות.
צוות לצמצום חובות טכניים:
בגלל שהבעיות לעתים דורשות השקעה ארוכה, ומומחיות - אחד המודלים הוא לייצר "צוות תשתיות" או צוות שיתקן בעיות במערכת.
למי שיש לו ניסיון בתוכנה, הרעיון הזה עשוי להישמע מופרך כמו הרעיון שעובדי outsource יבואו וינקו את הקוד (יבצעו refactoring) עבור המתכנתים של הארגון. אבל היי - גם דבר כזה קיים.
• בעיה עיקרית במודל הזה היא השחיקה של האנשים שבצוות.
• בעיה שניה היא שחובות טכניים רבים הם בליבת המודל הלוגי של המערכת. בלי היכרות אינטימית - לנסות לכתוב קוד טוב יותר זו משימה כמעט בלתי-אפשרית.
• יתרה מכך, גם מי שמכיר את המערכת מצוין ועסוק במשימות טכניות לאורך זמן ארוך - יאבד את הקשר עם פרטי המערכת, שמשתנה כל הזמן.
• אחת הווריאציות היותר הגיוניות לטעמי, היא שצוותים "משאילים" אנשים לצוות לצורך משימות של צמצום חוב טכני - ובסיום המשימה האדם חוזר לצוות.
• דרך ההתנהלות של הצוות שלא כפופים למחזור מוצרי (אם עובדים ב SCRUM) ותמיכה של אנשים טכניים חזקים - יכולה דווקא לעזור, ולייצר גיוון למי שמצטרף זמנית לכזה צוות.
• גם הקצאת המשאבים - היא קלה יותר לניהול, כאשר מדובר בצוות.
צמצום חוב טכני - כאירוע:
מודל אחר שיכול לעבוד הוא לרכז מאמץ של יחידה גדולה, או כל הפיתוח - על מנת לצמצם במרוכז חובות טכניים.
• וריאציה אחת ששמעתי עליה, היא חברה שמקדישה 3 ימים כל תקופה מסוימת - על מנת לשפר ולהעשיר את המערכת בבדיקות אוטומטיות (בדיקות יחידה, בדיקות אינטגרציה, וכו' - בדיקות שמפתחים כותבים). ע"פ הסיפור - זה עבד דיי טוב.
• וריאציה שניסינו לאחרונה בחברה הנוכחית שאני עובד בה (Next-Insurance) היא להפעיל את כל הפיתוח למשך שבועיים - על מנת להתמודד עם רשימת בעיות שהוכנה ותועדפה מראש.
• הזמן הארוך יחסית - מאפשר לפתור בעיות שהן לא רק פצפונות / נקודתיות.
• האמירה שיש השקעה משמעותית באיכות הטכנית של המערכת - משדרת מסר חשוב גם למתכנתים, וגם לשאר הארגון
אני אישית, מאוד נהנה מתקופות כאלו.
בכל מקרה, חשוב לתת את הבמה הראויה לתיקון של חובות טכניים משמעותיים - להלל ולהעריך בפומבי את מי שפתר בעיה מהותית. ההוקרה גם מצדיקה עבודה שהיא פעמים רבות קשה ומתישה, וגם משדרת בארגון שאנו מעריכים הנדסה טובה - ולא רק עמידה ביעדים ("בכל מחיר").
סיכום
שוב אמרתי לעצמי, שאבחר נושא קצרצר לפוסט, ואכתוב משהו באורך 4 tweets לכל היותר. לא הצלחתי - היה לי יותר מה לומר משחשבתי.
כמה דגשים שחשוב לי שלא תצאו מקריאת הפוסט בלעדיהם:
נקודת האופטימום הארגונית היא בהחלט לא "אפס חוב טכני", או לפחות לא בתפיסה המקובלת. "מקסימום הנדסה" - היא לא מקום טוב לביזנס או למערכת חיה להיות בו. חשוב לקחת כמה סיכונים, ולהתקדם בקצב טוב.
"חוב טכני" הוא מושג מאוד סובייקטיבי. בהגדרה מסוימת - רעיון החוב הטכני עשוי להיתרגם לאיסוף עבודה חסרת חשיבות.
• חשוב חשוב חשוב להתמקד בטיפול בחוב טכני שיש לו השפעה חיובית מורגשת (Impact).
• לעתים יש חוב טכני (Design, שמות של משתנים) שעצם קיומו מציק לנו כמהנדסים, אבל אין לו חשיבות לפעילות המערכת.
o הייתי משקיע מעט עבודה (low hanging fruits) עבור ההרגשה הטובה, בנוסח "החלונות השבורים" (לשמר אווירה של אכפתיות במערכת)
o הייתי מתאמץ לקבל גם אלמנטים לא-אלגנטיים במערכת, ואפילו צורמים - כל עוד העלות / תועלת לפתור אותם היא לא סבירה. למשל: עניין ה-referer ב HTTP.
o מערכות מתחדשות מטבען. אם תתעדו ("רשימה") ותשתפו ("שיקוף") בבעיה - יש סיכוי טוב שבשכתוב הבא, המצב יהיה טוב יותר.
o הכי מעצבן זה לראות קוד ששוכתב ושימר חובות טכניים מהותיים - מחוסר הבנה.
• חוב טכני לא צריך להיפתר לחלוטין. הורדה של בעיה מרמת Critical לרמת Medium - עשויה להיות התקדמות חשובה ומספיקה.
• בפעם הבאה שנרצה לשפר משהו, כנראה שנבחר בעיה קריטית אחרת - על פני העלמה של בעיה בעלת חומרה בינונית.
למרות ש"חוב טכני" הוא עניין בד"כ עניין טכני וטכנולוגי - מציאת המנגנון לצמצום חובות טכניים הוא בעיקר ארגוני. עבדו עם ההנהלה ומי שיכול לקדם דברים בארגון - לא רק עם מקצועני התוכנה.
שיהיה בהצלחה!
מאת: ליאור בר און, ארכיטקט ראשי בחברת Gett וכותב בבלוג http://www.softwarearchiblog.com
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
בחלק א' התמקדנו בהימנעות מטעויות בהחזרת חוב טכני. היום נעסוק בצד החיובי – איך (כן) מחזירים חוב טכני?
איך (כן) מחזירים חוב טכני?
בגדול, יש שלושה אלמנטים חשובים בטיפול בחוב טכני:
• זיהוי החוב הטכני, וסיווגו ע"פ השפעה על המערכת / הארגון.
• שיקוף ושיתוף החוב הטכני, לחלקים שונים בארגון.
• מציאת המנגנון הארגוני לצמצום חוב טכני.
חוב טכני תמיד יגדל (עוד קוד נוסף, הביזנס משתנה, המערכת גדלה ונעשית מורכבת, הקוד מתיישן ו"נרקב") - וחשוב להוריד אותו בקצב שקול לגדילה - על מנת, לפחות, להישאר במקום.
כארכיטקטים, או מובילים טכניים בארגון, עליכם להתכונן כ"שבט של ציידים": להתכונן לשעת כושר, וכשהיא מגיעה - לנצל ממנה את המיטב.
הציד הוא דליל רוב ימות השנה, וחשוב להתמודד עם המחסור.
אבל מידי פעם, יעבור באזור עדר גדול של בפאלו נודד. שבט שמתחיל לפעול רק כאשר העדר כבר הגיע - לא ישרוד לאורך זמן. עליו להיות מוכן ליום הזה, ולנצל את ההזדמנות ברגע שהגיעה - עד תום.
באופן דומה, הזדמנויות לצמצום החוב הטכני, לא נופלות מהשמיים, ולא כל ימות השנה. עליכם להיות מוכנים עם תוכנית אופרטיבית - שכאשר יש הזדמנות ("אוי - יש לנו מפתח פנוי בחודש הקרוב"), אנחנו יודעים בדיוק מה לעשות, יש לנו מגוון אפשרויות - ואנו יכולים להפיק מההזדמנות את המירב.
ניהול "רשימת בעיות":
• כל פעם שאני מבין שיש פה חוב טכני בעייתי שארגון סובל בגללו (או שעומד להיות) - אני מוסיף אותו לרשימה.
• מדי פעם בצורה פרואקטיבית - אני יושב עם המפתחים הוותיקים, מעדכן ומתקנן את הרשימה.
• את הרשימה חשוב לתעדף. אם יש לרשות הארגון מפתח זמין לחודש, עדיף מאוד שיפתור בעיה חמורה שהנזק ממנה ברור - מאשר "לסדר קצת את הקוד". יצירת Impact חיובי הוא גם מפתח על מנת שהארגון ימשיך וירצה להשקיע בצמצום חובות טכניים בעתיד.
• אם יש בעיה ללא פתרון - זה לא עוזר. לפחות למספיק מהבעיות - חשוב שיהיה פתרון ידוע. אם צריך להשקיע ב Design - השקיעו מדגמית בכמה עניינים חשובים באזורים שונים. אי אפשר לדעת באיזה אזור של המערכת "יעבור עדר הבאפלו".
השיקוף של הבעיות - הוא חשוב מאוד גם כן. גם לצד ההנהלה, וגם לצד המפתחים:
• אם ההנהלה לא יודעת שיש בעיות חמורות, זה לא הוגן ולא אחראי. היא לא תדע להקצות את המשאבים (שתמיד נמצאים במחסור) בכדי להתמודד עם הבעיה.
• אם המפתחים לא מבינים שדברים מסוימים מהווים בעיה חמורה - הם לא ידעו לצמצם ולהגביל את הבעיה. מכירים את ה-Anti-Pattern של "שכפול Anti-Patterns במערכת"?
• אם אתם לא מבינים את הבעיה, איך המפתחים לא יתקנו אתכם ויסבירו לכם - אם לא תדברו איתם על זה. תנו להם הזדמנות לתקן אתכם, ולחסוך לכם חוסר-נעימות.
מציאת המנגנון הארגוני לטיפול בבעיה:
זה לפעמים החלק הכי קשה, ואני מקווה עבורכם שזו לא "הבעיה שעל כתפכם בלבד".
בחלק הבא (והאחרון) נעסוק בה קצת יותר בהרחבה.
רשימה לדוגמה של חובות טכניים שיש לפתור במערכת.
הרשימה רק תלך ותתארך, אז חשוב כל הזמן לפתור בעיות, לבדוק אלו עדיין רלוונטיות, ולתעדף.
הרשימה רק תלך ותתארך, אז חשוב כל הזמן לפתור בעיות, לבדוק אלו עדיין רלוונטיות, ולתעדף.
מציאת המנגנון הארגוני לצמצום חובות טכניים
תפיסה נפוצה (נתקלתי בה כבר מספר פעמים) היא שיש להקצות זמן נתון (הכלל המקובל: כ-20% בזמן העבודה) לצמצום חובות טכניים.
גישת הצוות:
ברוח ה-Empowerment (עניין מבורך) מורים לכל צוות להקצות את הזמן שלו - מבלי שישתף את שאר הארגון כיצד הוא מנצל אותו.
• כאשר המשאבים הם מקומיים (ברמת הצוות) - קשה עד בלתי אפשרי לפתור את הבעיות הגדולות.
• כבר נתקלתי לא-פעם בצוותים שניצלו את רוב הזמן שניתן להם בכדי לנסות טכנולוגיות "חדשות ומגניבות" שלא עשו שום השפעה חיובית משמעותית על המערכת או הארגון. זה בטח טוב לריצוי עובדים - ברמה כלשהי.
הגישה הגלובאלית:
גם כאשר הזמן המוקצה לצמצום חובות טכניים הוא "גלובאלי" (משותף לכל ארגון הפיתוח) - חשוב מאוד כיצד הוא מתוקשר ומנוהל.
לא פעם ראיתי שהוא תוקשר בצורה כזו שאנשי המוצר הרגישו ש"גוזלים מהם מזמן הפיתוח, בלי הצדקה" (מילים שלי).
למשל: בכל תוכניות העבודה מציגים 20% זמן טכני - ואנשי המוצר מתחלקים הזמן הנותר. זה נשמע כמו רעיון טוב על מנת להסביר מדוע לא כל המפתחים עובדים כל הזמן על משימות מוצר, אבל עלול בקלות לגרום לתחושה של אובדן משאבים מצד אנשי המוצר.
תגובה טיפוסית לתחושה כזו, היא לנסות ולהעמיס על "זמן החזרת החוב הטכני" כל מאמץ אפשרי: תיקוני באגים, כתיבת בדיקות-יחידה, או קבלת חובות טכניים במופגן - בידיעה שהם יכוסו מתקציב אחר. זה אף פעם לא מתחיל כך, אך זה בקלות עלול להתדרדר לשם לאורך הזמן. משאבי-פיתוח הם משאב יקר ערך בארגונים, ורק טבעי שברגע שיש "תקציב חדש" - רבים ינסו לנגוס בנתח ממנו להשגת היעדים הארגוניים שהם אמונים עליהם.
יתירות בפיתוח:
רעיון אחד שנתקלתי בו הוא הרעיון שיתירות בפיתוח (כלומר: יש יותר מפתחים ממה שצריך) - יאפשר לטפל בחוב טכני בצורה טבעית. זה רעיון הגיוני לוגית - אך לא ראיתי אותו אף פעם קורה בפועל:
• כל עוד איש מוצר יכול, בעזרת מצגת שהכין בשעתיים, ליצר עבודה לצוות פיתוח לחודשיים - לא יהיה לעולם זמן פיתוח "יתיר".
• עוד נקודת מפתח והיא יוקרה של צמצום חובות טכניים בארגון: כל עוד מירב מקבלי-ההחלטות בארגון מעריכים יותר פיצ'ר חדש מתיקון של חובות טכניים - הזמן שהוקצה להתמודדות עם חובות טכניים "יזלוג" לכיוון פיתוח פיצ'רים. כאן הפתרון הוא שיקוף יעיל של הבעיות הטכניות (עניין שהזכרנו קודם):
• חשוב שלמקבלי ההחלטות יהיה מושג על בעיות קיימות - ומה ההשפעה השלילית שלהן. הם לא יוכלו להבין את רוב הבעיות הטכניות - אבל כמה דוגמאות משמעותיות עשויות לעשות את ההבדל בתפיסה.
• חשוב שמקבלי ההחלטות יראו גם שבעיות נפתרות, או לפחות יחושו בצורה כלשהי שיש תרומה לחברה מתוך עיסוק בצמצום חובות טכניים (למשל: לשתף מכתב תודה של יחידה אחרת בארגון שסבלה מבעיה כלשהי).
• שיקוף אפשרי בעיקר לבעיות שנוגעות גם לביזנס בצורה ישירה (downtime, אטיות, פגעי-אבטחה), וחשוב לנצל תיקון של בעיות על מנת להדגים את החשיבות במערכת שלא רק כתובה - אלא גם כתובה נכון.
הבחנה חשובה היא בין חוב טכני "טוב" ו"רע":
חוב טכני קצר טווח - הוא פעמים רבות שימושי ומועיל. למשל: מיקוד בשחרור מוקדם ולמידה.
חוב טכני משמעותי ושנמשך לאורך זמן - הוא לרוב "רע"
חוב טכני קצר טווח - הוא פעמים רבות שימושי ומועיל. למשל: מיקוד בשחרור מוקדם ולמידה.
חוב טכני משמעותי ושנמשך לאורך זמן - הוא לרוב "רע"
לפעול במהירות ובנחישות:
גישה שעשויה לעבוד עבור מגוון מקרים היא ניהול פנימי של החוב הטכני בתוך הפיתוח: מיד בסוף הפיצ'ר מקדישים כמה ימים על מנת "לנקות חובות" ולשפר את הקוד היכן שצריך.
• לפעמים זה חצי יום - ולפעמים שבועיים.
• לא מדווחים על סיום המשימה עד שלא מסיימים את החובות הטכניים המיידיים. מסבירים שיש עוד כמה צעדים טכניים נדרשים לסיום המשימה.
• נקודת מפתח להצלחה היא מחויבות עמוקה של מנהלי הפיתוח, והיכולת שלהם לעמוד בלחצים מצד אנשי המוצר. אף אחד לא שמח לשמוח על פיצ'ר שמתעכב בשבועיים (גם אם שוחרר כרגע, ויש רק עוד סדרת תיקונים נדרשת).
• בארגונים מסוימים - עדיף לא לשקף לאנשי המוצר לאן הזמן בדיוק הולך. אולי רק בצורה ראקטיבית לשאלות.
• בארגונים שבהם יש יותר אמון הדדי - שווה לשקף, אבל להיזהר ולהסביר את ההשקעה בצורה שתבנה אמון עם היחידות העסקיות.
צוות לצמצום חובות טכניים:
בגלל שהבעיות לעתים דורשות השקעה ארוכה, ומומחיות - אחד המודלים הוא לייצר "צוות תשתיות" או צוות שיתקן בעיות במערכת.
למי שיש לו ניסיון בתוכנה, הרעיון הזה עשוי להישמע מופרך כמו הרעיון שעובדי outsource יבואו וינקו את הקוד (יבצעו refactoring) עבור המתכנתים של הארגון. אבל היי - גם דבר כזה קיים.
• בעיה עיקרית במודל הזה היא השחיקה של האנשים שבצוות.
• בעיה שניה היא שחובות טכניים רבים הם בליבת המודל הלוגי של המערכת. בלי היכרות אינטימית - לנסות לכתוב קוד טוב יותר זו משימה כמעט בלתי-אפשרית.
• יתרה מכך, גם מי שמכיר את המערכת מצוין ועסוק במשימות טכניות לאורך זמן ארוך - יאבד את הקשר עם פרטי המערכת, שמשתנה כל הזמן.
• אחת הווריאציות היותר הגיוניות לטעמי, היא שצוותים "משאילים" אנשים לצוות לצורך משימות של צמצום חוב טכני - ובסיום המשימה האדם חוזר לצוות.
• דרך ההתנהלות של הצוות שלא כפופים למחזור מוצרי (אם עובדים ב SCRUM) ותמיכה של אנשים טכניים חזקים - יכולה דווקא לעזור, ולייצר גיוון למי שמצטרף זמנית לכזה צוות.
• גם הקצאת המשאבים - היא קלה יותר לניהול, כאשר מדובר בצוות.
צמצום חוב טכני - כאירוע:
מודל אחר שיכול לעבוד הוא לרכז מאמץ של יחידה גדולה, או כל הפיתוח - על מנת לצמצם במרוכז חובות טכניים.
• וריאציה אחת ששמעתי עליה, היא חברה שמקדישה 3 ימים כל תקופה מסוימת - על מנת לשפר ולהעשיר את המערכת בבדיקות אוטומטיות (בדיקות יחידה, בדיקות אינטגרציה, וכו' - בדיקות שמפתחים כותבים). ע"פ הסיפור - זה עבד דיי טוב.
• וריאציה שניסינו לאחרונה בחברה הנוכחית שאני עובד בה (Next-Insurance) היא להפעיל את כל הפיתוח למשך שבועיים - על מנת להתמודד עם רשימת בעיות שהוכנה ותועדפה מראש.
• הזמן הארוך יחסית - מאפשר לפתור בעיות שהן לא רק פצפונות / נקודתיות.
• האמירה שיש השקעה משמעותית באיכות הטכנית של המערכת - משדרת מסר חשוב גם למתכנתים, וגם לשאר הארגון
אני אישית, מאוד נהנה מתקופות כאלו.
בכל מקרה, חשוב לתת את הבמה הראויה לתיקון של חובות טכניים משמעותיים - להלל ולהעריך בפומבי את מי שפתר בעיה מהותית. ההוקרה גם מצדיקה עבודה שהיא פעמים רבות קשה ומתישה, וגם משדרת בארגון שאנו מעריכים הנדסה טובה - ולא רק עמידה ביעדים ("בכל מחיר").
סיכום
שוב אמרתי לעצמי, שאבחר נושא קצרצר לפוסט, ואכתוב משהו באורך 4 tweets לכל היותר. לא הצלחתי - היה לי יותר מה לומר משחשבתי.
כמה דגשים שחשוב לי שלא תצאו מקריאת הפוסט בלעדיהם:
נקודת האופטימום הארגונית היא בהחלט לא "אפס חוב טכני", או לפחות לא בתפיסה המקובלת. "מקסימום הנדסה" - היא לא מקום טוב לביזנס או למערכת חיה להיות בו. חשוב לקחת כמה סיכונים, ולהתקדם בקצב טוב.
"חוב טכני" הוא מושג מאוד סובייקטיבי. בהגדרה מסוימת - רעיון החוב הטכני עשוי להיתרגם לאיסוף עבודה חסרת חשיבות.
• חשוב חשוב חשוב להתמקד בטיפול בחוב טכני שיש לו השפעה חיובית מורגשת (Impact).
• לעתים יש חוב טכני (Design, שמות של משתנים) שעצם קיומו מציק לנו כמהנדסים, אבל אין לו חשיבות לפעילות המערכת.
o הייתי משקיע מעט עבודה (low hanging fruits) עבור ההרגשה הטובה, בנוסח "החלונות השבורים" (לשמר אווירה של אכפתיות במערכת)
o הייתי מתאמץ לקבל גם אלמנטים לא-אלגנטיים במערכת, ואפילו צורמים - כל עוד העלות / תועלת לפתור אותם היא לא סבירה. למשל: עניין ה-referer ב HTTP.
o מערכות מתחדשות מטבען. אם תתעדו ("רשימה") ותשתפו ("שיקוף") בבעיה - יש סיכוי טוב שבשכתוב הבא, המצב יהיה טוב יותר.
o הכי מעצבן זה לראות קוד ששוכתב ושימר חובות טכניים מהותיים - מחוסר הבנה.
• חוב טכני לא צריך להיפתר לחלוטין. הורדה של בעיה מרמת Critical לרמת Medium - עשויה להיות התקדמות חשובה ומספיקה.
• בפעם הבאה שנרצה לשפר משהו, כנראה שנבחר בעיה קריטית אחרת - על פני העלמה של בעיה בעלת חומרה בינונית.
למרות ש"חוב טכני" הוא עניין בד"כ עניין טכני וטכנולוגי - מציאת המנגנון לצמצום חובות טכניים הוא בעיקר ארגוני. עבדו עם ההנהלה ומי שיכול לקדם דברים בארגון - לא רק עם מקצועני התוכנה.
שיהיה בהצלחה!
מאת: ליאור בר און, ארכיטקט ראשי בחברת Gett וכותב בבלוג http://www.softwarearchiblog.com
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר