מדוע זכייה עם DevOps פירושה צמצום ההפסדים?
כתב: מאיר אדלר, CTO ומנהל פריסייל של חטיבת CA ישראל ב-NessPRO, קבוצת מוצרי התוכנה של נס ישראל
דמיינו שאתם בקזינו נוצץ בלאס וגאס. כיצד הייתם מרגישים אם הפסדתם או זכיתם ב-100 דולר ברולטה? יש לציין כי מחקרים פסיכולוגיים הראו שלהפסדים יש עוצמה אמוציונלית פי שניים מאשר לזכיות – אנו שונאים להפסיד יותר ממה שאנו אוהבים לזכות.
התובנות האלו לגבי התנהגות, וההטיה הקוגניטיבית, הן אלו שמסייעות לקזינו להרוויח. זה גם משהו שיכול להשפיע על כל יוזמה שקשורה לשינוי בתחום הטכנולוגיה העסקית – כולל DevOps.
עכשיו דמיינו, שאתם עוסקים בפיתוח תוכנה בתחום הטכנולוגיה העסקית. אתם בלחץ לשחרר עדכון חדש לאפליקציה. אתם יודעים שעלולה להיות בעיית ביצועים או איכות, אולם המחשבה על עיכוב הפריסה היא קשה לעיכול. כמו מהמר בקזינו אתם לוקחים סיכון: מגלגלים את הקוביות כדי להימנע מהפסד ודאי. יש לקוות כי התחושה המטרידה לא תתברר כמשהו חמור שיסכן את העסק. אבל מה הסיכוי לכך, כאשר בדיוק כמו בלאס וגאס, הסיכויים תמיד נגדכם?
מומחי IT רבים מפחדים מהפסד יותר מאשר משינוי
הבעיות הקשורות ל"שנאת ההפסד" אינן מוגבלות רק לפיתוח תוכנה. הן כוללות גם את תפעול ה-IT וניהול השירות. צוותים יכולים לבלות אין ספור שעות בהתאמה מדויקת של פונקציות ניהול שינויים ופיתוח Review Boards משוכללים. זה אולי מעיק, אך מצד שני זה משהו שיהיה קשה לוותר עליו כאשר תחזוקה ותמיכה הן מה שמעצב קריירה וביטחון תעסוקתי מובטח.
בעוד חלק מאיתנו עלול להיות מוטרד משינוי, הפחד מהפסד הוא לעתים קרובות הרבה יותר חזק. לדוגמה – נניח שמנהל מערכת (system administrator) מקבל במשך שנים פיצוי כספי הולם על שעות נוספות וכוננויות תמיכה. מה יהיה היחס ל-DevOps, המתמקד בשיתוף פעולה הדוק יותר עם הפיתוח למניעת בעיות ייצור, אם הוא עלול לפגוע במזומנים?
אנו שונאים לוותר על מה שאנו בונים – אפילו על דברים גרועים
שנאת הפסד יכולה להיות מושפעת מניואנסים התנהגותיים וטכניים אחרים, במיוחד מ"אפקט איקאה". אפקט זה, הקרוי על שמה של מעצמת הרהיטים השוודית להרכבה עצמית, מתאר מצב שבו אנשים מייחסים ערך רב יותר לדברים שהם בונים בעצמם.
זהו דבר נהדר בתחום הפיתוח, שבו עלינו להיות גאים בתוכנה שלנו, אך יכול להזיק כאשר אנו מגוננים יותר מדי על מה שיצרנו, כאשר יש צורך לבצע שיפור. הדבר דומה לשמירה על ארון ישן של איקאה (IKEA) עם רגל רופפת. היה צריך להחליף אותו לפני שנים, אבל מאחר שבעליו מושקע בו מבחינה רגשית, קשה לו לזרוק אותו.
אהבת יתר של "רהיטים בעייתיים" אינה רק נחלתו של תחום הפיתוח. בתחום התפעול אנו מגינים על כלים ושיטות לתמיכה בהתמחות בתחומים ספציפיים. אנו גאים בהרכבה עצמית של תהליכים מורכבים, עם הנדסת יתר, על חשבון שינוי נחוץ.
כיצד יכולים ארגונים הבוחרים ב-DevOps להתמודד עם ההשפעות השליליות של שנאת הפסד? איך הם יכולים להבטיח שהצוות לא יקח סיכונים מיותרים, משום שהוא חושש מההשלכות?
● יש להפסיק להמר בתחום הפיתוח – אנשי הפיתוח מסתמכים, באופן מסורתי, על צוותי בקרת איכות ובדיקות שיאתרו באגים ופגמים. יחד עם זאת, אימוץ טכניקות כמו פיתוח מונחה-בדיקות, אומר שאם לא משלימים את הבדיקות, הקוד לא יועבר והמקדדים יקבלו משוב מיידי לגבי איכות התוכנה. לכך יש להוסיף כלים חדשים המונעים מגבלות בדיקות. כלומר – האיכות נקבעת הרבה יותר מוקדם, ואין סיבה שאנשי הפיתוח צריכים לקחת סיכונים ו"חוב טכני" מיותר.
● יש לגלות מחדש את אמנות האומנות – בעידן של פיתוח בסגנון אג'ייל, תהליכים ישנים רבים שתוכננו ונבנו על מנת להבטיח עמידה בתקנות וחוסן, עשויים לפעול עכשיו כמו "מפסקי" חדשנות. כדי לפתור בעיה זו, צוותי פיתוח רבים לוקחים על עצמם תפקיד של "חיילי קומנדו", ומאמצים כלים חדשים כדי לעקוף את מחלקת ה-IT. במקום להתנגד לכך, יש לעודד צוותים ליישם את המומחיות שלהם בתחומים שמעבר לגבולות המבנה הארגוני. הדבר מאפשר לעצב במיומנות, במהלך התכנון והפיתוח, אלמנטים קריטיים שהוזנחו לעתים קרובות, כמו יכולת תמיכה באפליקציות וחוויית לקוח איכותית.
● תמריצים על פי תוצאות עסקיות – קשה לבקש מצוות התמיכה לוותר על תגמולים כספיים, כך שיש להיזהר. אבל במקום לפצות את הצוות על פי ה"פלט" (למשל שורות קוד או מספר הבעיות שתוקנו), יש לשקול באופן שיטתי להציג סדרה של מדדים לפיהם ניתן למדוד ולתמרץ את הצוות לפי המידה שבה פעילותו משפרת תוצאות עסקיות. באופן אידיאלי, דבר זה צריך להיות ישים לגבי כל הקבוצות כדי לעודד שיתוף ידע, משוב ואסטרטגיות שיפור החוצות פונקציות.
קל מדי להניח לבעיות בתרבות המתנגדת לשינוי, אבל אסור לנו לשכוח שהתרבות מעוצבת על ידי התנהגויות. בכל שינוי, טבעי שאנשים פוחדים לאבד דברים רבים, וביניהם רלוונטיות, מיומנויות, קריירה וכסף, ויש התנגדות חריפה כאשר יש איומים כאלו.
ככל ש-DevOps וה-tooling קשורים לביצועים גבוהים ולחוסנה של התוכנה, כך עליהם להיות קשורים גם לאנשים היוצרים אותה. אז, ורק אז, יוכלו ארגונים להתחיל לטפל במה שכל גוף DevOps צריך להיות מודאג שיילך לאיבוד – עסקים, לקוחות והזדמנויות.
