פרפקציוניזם נתפס לעיתים כתכונה חיובית. לא בהטמעת טכנולוגיות וממש לא במערכות מידע ארגוניות!
האמירה הזו, מן הסתם, נכונה בתחומים רבים, אבל בפוסט זה נדגיש מדוע עשיית יתר ,Over Doing, או במקרה שלנו IT-Overdoing, ממש אסורה או במילים אחרות, מדוע המיקוד והפשטות הן דרכי הפעולה הנכונות, בכלל ובעולם הטכנולוגי בפרט.
הערה: אין הכוונה לפער המתודולוגי שבין Waterfall ל Agile. בפוסט זה הדגש הוא על Over Doing.
הגדרת הבעיה
הקרקע בעולם הטכנולוגי מבעבעת וזזה. מהר. כמה עובדות חיים בעולם הטכנולוגי:
כל פתרון טכנולוגי הוא פתרון מורכב. החל מעולם התקשורת, השרתים, האחסון, המחשבים האישיים והטלפונים הניידים, דרך אבטחת המידע וניהול הרשתות על ידי גורמים שונים, דרך התוכנות, מערכות ההפעלה, וירטואליזציה, דוקרים, בסיסי הנתונים, אינטרגרציה, BI ועולמות התצוגה (UI/UX) וכל מה שצוין, צוין על דרך ההפשטה והצמצום (כמות הרכיבים במציאות היא כנראה בין פי 3 לפי 10)...
החל מהבסיס ההנדסי, שכל שנה וחצי/שנתיים כוח המחשוב במעבדים מוכפל, כל רכיב חומרה משתדרג בקצב גבוה. ברבדים שמעל, כל רכיב תוכנה משתדרג בקצב של גרסה מג'ורית בכל שנה (לפחות). המשמעות היא, שאם עושים את מכפלת השינויים האפשריים (למשל, לפי מודל 7 השכבות - שהורחב בעקבות מימושי הענן והמובייל), ייקרה שינוי משמעותי בקצב של כל כמה דקות. כלומר בעולם הטכנולוגי הקרקע, זזה מהר. מי שלא משדרג, לא נהנה מפונקציונאליות נדרשת, משיפור נדרש בביצועי ובקיבולת המערכות, מהתאמת הסביבה הטכנולוגית לאיומי האבטחה ובפשט – מהחזר על ההשקעה שלו.
גם העולם העסקי נע בקצב גבוה. בכל תחום הקונגלומרטים הגדולים נוגסים בחברות הגדולות, שבולעות את החברות הבינוניות וגו'. לארגון המבקש שינוי אין זמן לחקות שנתיים ליכולת עסקית כלשהיא. המשמעות היא שכאשר נידרש שינוי, ה Time To Market הוא קריטי. מענה לצורך עסקי שמתעקב ומושק באיחור של כמה חודשים כבר פוגש מציאות שונה מזו שאליה נדרש.
כאשר זה המצב, אספקת פתרונות בקצב הנמוך מקצב השינוי הוא בעייתי. ואם לא די באתגר הטכנולוגי, הרי שאתגרים מנטליים כמו פרפקציוניזם כבר חורג מהגדרת אתגר והופך לבעיה. וכיצד נגדיר את הבעיה?:
העיכוב הנובע מעשיית יתר, לכאורה מכוונה טובה, אך גורר את הארגון להחטאת מטרותיו.
מהי עשיית יתר (IT-OverDoing)?:
דרישות יתר מצד המשתמשים ואי הפרדה בין עיקר לטפל בהשפעת הדרישה על העסק.
תכנון יתר כתוצאה מהעמקה ורצון להביא פתרון מושלם.
ביצוע יתר מצד הצוותים הטכניים שלעיתים "רוכבים" על השינוי ומנצלים אותו להוספה או שיפור הכלים שלהם, סוגרים חוב טכני, וכד'.
בדיקות יתר (על נושא זה יש אין ספור ויכוחים אבל אין ויכוח שיש פיצ'רים חשובים יותר ויש שפחות..).
מה מחיר העיכוב?
ניתן לחלק את מחיר העיכוב לשני חלקים. החלק הנובע ממחירי החומרה, התוכנה והעבודה והחלק הנובע מהשפעת העיכוב על העסק.
את החלק הנובע ממחירי החומרה אפשר לחשב על ידי חלוקת מחיר החומרה לתקופת זמן העיכוב וסכימת כל הרכיבים. את החלק הנובע ממחירי התוכנה והעבודה אפשר לחשב לפי הוצאות הרישוי והשכר (לפי אורך חיים צפוי) וסכימת הרכיבים.
את עלויות ההשפעה על העסק – בהרבה מקרים קשה או כלל לא ניתן לחשב. אבל ברור שכאן הכאב המשמעותי ביותר, שכן לשם שיפור העסק נבנה המערך הטכנולוגי כולו בין שאר מערכי החברה. דוגמאות למחירים הנגבים:
פגיעה בתחרותיות של החברה אל מול מתחרה ממוקד.
ייקור המוצרים כתוצאה מייקור העלויות.
דחיה או ביטול פרויקטים רווחיים לעסק לטובת פרויקטים שאינם רווחיים.
נטילת קשב ניהולי מהעיקר לכיוון הטפל.
אובדן אמון מצד לקוחות ושותפים עסקיים המצפים לשירות טוב יותר, בזמן תגובה טוב יותר ובמחיר נמוך יותר.
התמודדות עובדי החברה מהתסכול הנובע מהחמצת העיקר.
מי הם המעכבים?
אידאולוגים אירגוניים שלמדו היטב את התיאוריה ופחות מבינים את השפעת הזמן על הפרקטיקה.
כוחניים ארגוניים שרוצים להוכיח שהדרישות שלהם – הכי חשובות.
פרפקציוניסטים שדורשים – בטווח שבין "רק עוד קצת" לבין "הכל או כלום".
אנשי תמיכה "שייתנו הכל" בשביל הלקוח...
והיה אם...
הארגון היה בונה גוף טכנולוגי המסוגל לפתח את כל מה שהמשתמשים והלקוחות היו דורשים, האם הארגון היה מוצלח יותר? ממש לא! מדוע?:
ביישום ומימוש של פיתוח המבוסס על טכנולוגיה, האם רק הגף הטכנולוגי מעורב? מסתבר שלא, כי מאחורי כל פונקציונאליות יש צורך בקשב ארגוני, מההנהלה ומטה ומהארגון החוצה ל Echo System שלו. ואם קצב השינוי יהיה גבוהה, לכאורה כפי הנדרש, למעשה – יאבד הקשב הארגוני. יאבד המיקוד. יחד איתם גם לקוחות.
בכדי שהגוף הטכנולוגי יהיה מסוגל לפתח כל דרישה, צריך כח אדם וטכנולוגיה בהיכון למשימה חדשה. והמשמעות: בזבוז אדיר של משאבים.
המחיר הגבוה ביותר שארגון משלם, הוא לפיתוחי סרק (למשל אותם פיתוחים ששנה שעברה היו חשובים, אולם עקב פרפקציוניזם, יצאו ליישום בעיכוב) זאת מאחר שהיתה השקעה, מאחורי ההשקעה יש כבר וקטור (כוח של קבוצת אנשים, חדורי מטרה) בארגון שרוצה להצליח, אבל הארגון כבר לא שם, כבר אין צורך. והוקטור הזה, שאיחר את המועד, כולו מושקע ברעש ולא בצורך קיומי.
התגובה לפתרונות "מושלמים" כבר כאן
את בעיית תפסת מרובה - לא תפסת, העולם לא גילה עם כתיבת פוסט זה... בעיית ה"שלמות" מופיעה בכל עולם הפתרונות הטכנולוגיים.
פחות זה יותר היא כבר סיסמה מוכרת ומהווה דגל בתגובה לבעיית הפרפקציוניזם. אמנם באופן אבולוציוני, אמנם לא באופן ממוקד, אבל בהחלט ניתן לראות קו מגמה. כיצד התגובה באה לידי ביטוי?:
המעבר מפיתוח מוצרי תוכנה מרכזיים וגדולים (מונוליט) לפיתוח Microservices, שהן יחידות תוכנה קטנות אך עצמאיות.
המעבר מאגפי פיתוח תוכנה הבנויים במבנה הירארכי לצוותי תוכנה עצמאיים, המתוחמים בתחומי ידע ובאחריות לרכבי התוכנה הספציפיים (Microservices) ובתחומי בנזק הפוטנציאלי שלהם.
השינוי המתודולוגי בכל תהליך הפיתוח ומעבר מה Water Fall ל Agile, שגם הוא נובע מההפנמה שכאשר תהליך לאספקת פתרון טכנולוגי מתארך – בעיית המקור כבר משתנה. כלומר הפתרון לא מתאים.
הרחבת השימוש ב PaaS וב SaaS בכל רכיבי התוכנה וה DevOps שאינם ליבת העסק.
קו מגמה זה מצביע על פירוק פרוייקטים גדולים לפרוייקטים שהם ניתנים לעיכול בקלות, בזמן מהיר, תוך תיחום הפרפקציוניזם והשלמות באופן שהשפעתם על העסק פוחתת. פוחתת בפונקציונאליות, בכ"א דרוש ובזמן פיתוח ובכך כמובן אנו מקוים להשיג Time To Market טוב יותר.
התובנות וההתקדמות הן חלק מההתרחשות בעולם ייצור התוכנה. אולם פרפקציוניזם ואידאולוגים ארגוניים קיימים גם מחוץ לאגפים הטכנולוגיים ושם בגיוון הארגוני לא תמיד המתודולוגיה מושתת. לכן חשוב שההנהלות תהינה מודעות, חשוב לזהות את התופעה, להפריד עיקר מטפל בטרם הגוף הטכנולוגי מבצע השקעה מיותרת ולכוון לפשרה שעיקרה קיצור הזמן לאספקת הפתרון הבא.
לסיכום – כמה אמירות מנופחות...
אם ארגון החליט לרכוש או לפתח יישום שיש בו צורך עסקי וכדאיות כלכלית, האוייב של יישום ומימוש טוב, הוא היותר טוב...
הדרך הנכונה היא מלכתחילה לשאוף ליישום של הפיצ'רים העיקריים. חשוב לדעת לוותר ולהגדיר בכל פרוייקט מה מביא פחות תועלת לארגון. ולנסות להקטין ככל הניתן את הפרוייקטים.
החתירה למיקוד ופשטות היא נשמת אפו של הארגון המנצח. לכן, כלל הפארטו הוא מאד חשוב. מי שמשקיע ב 20% הטפלים במקום ב 80% העיקריים, יפסיד הרבה יותר מאשר העלות הישירה של הפרוייקט.
ארגון אשר מסוגל להשיל משקל עודף של פונקציונאליות יתר, זריז יותר בעולם התחרותי.
מנהל שלא ישחרר מערכת עד שהיא לא 100% הוא למעשה אוייב הארגון. לא פחות.
והערה חשובה: לא לבלבל ולהחליף את המסר בזלזול
בפוסט זה, אין קריאה לזלזול בהגדרת דרישות קפדנית, תכנון קפדני וביצוע מצויין. אלא חידוד הצורך בהבדלה בין עיקר לטפל, בין מה יותר חיוני לעסק ובין מה שפחות, בין מה שייושם עכשיו ומה שיידחה.