מה עדיף – ספרינט או מרתון?

"מתי זה יהיה מוכן ויעלה לאוויר"?
"בגרסה הרבעונית הבאה".

"על מה אתה מדבר? מתי זה?"
"בעוד שלושה וחצי חודשים".

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

"אני לא יכול יותר איתכם שם ב-IT, המתחרים לא מחכים, הם מעלים שרות חדש בעוד שבועיים, אני חייב להיות עם זה באוויר לפניהם".

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

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

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

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

אבל – ויש כאן אבל גדול מאוד – נזכיר לעצמינו שוב ושוב שאנחנו כאן כדי לשרת את לקוחותינו. ובמצב שבו הסביבה משתנה, התחרות בעיצומה, ההצלחה העסקית תלוייה במערכות המידע, אנחנו צריכים לצד ה-"כבדות", להפגין גם "זריזות". מהעניין זה נולדה גישת האג'ייל, פיתוחים ומענים בסבבים קצרים. אבל גם זה מתודי, פרוייקטאלי, ואני מדבר על יותר מזה, אני מדבר על "להתפרע", אבל לא יותר מדי, לא כשיטה, אלא במידה. לצד המהלכים הסטנדרטיים, לייצר גם Quick Wins של פתרונות Quick and Dirty. לעשות את זה באותם מקרים מיוחדים שהצורך העסקי הוא אמיתי. שהלקוח שלנו יידע, שכשהוא צריך אותנו, אנחנו שם בשבילו. ואם יש מקרה ייחודי שצריך פתרון מיידי שלא יכול לחכות לגרסה, כי המתחרה יקדים אותנו עם הסחורה, אז צריך להתגייס, לעקוף את התיעדוף, לעבוד אם צריך 24 שעות כדי לתת תשובות. אם נדע לעשות מבצעים כאלו, יקבלו יותר בהבנה את השיטה שבשגרה. תכנית העבודה צריכה לקחת בחשבון משאבים לכאלו מבצעים. אין מה לחשוש, זה לא יכול להפוך לשיטה. גם הלקוחות שקוראים את הטור הזה, מבינים שאם כל דבר יהיה "דחוף", אז שוב יהיה תיעדוף.

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