בלוג > מיתוסים

מיתוס 21: שחרור גרסאות תוכנה בתדירות גבוהה, נותן ערך טוב יותר ללקוח

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

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

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

אז זהו, שלא תמיד. לפעמים אפילו להיפך.

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

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

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

מכיוון שלא כל כך נעים לומר זאת, יש כאלה המנסים להיות יצירתיים. במקום

"Bug fixes and performance improvements"

הם כותבים משהו כמו:

" We are always working on making our application better and we release new features and improvements frequently… "

יש כאלה שלא כותבים כלום ב"מה חדש" (לפחות מגלים כנות) ואחרים מצמידים את תיאור החידוש המשמעותי האחרון להרבה גירסאות שאחריו.

כל אלו אומרים לי שגם גירסה זאת לא מחדשת עבורי כמעט כלום. כדברי השיר:

Always something happening and nothing going on.

אז בטווח הקצר ההתקדמות מבחינת המשתמש היא לרוב מינורית, אך מה קורה בטווח הבינוני והארוך?

ברוב החברות אליהן אנחנו מגיעים, אנחנו מוצאים road map עבור התקדמות ממשית כזאת, אך ללא תכנון ברור איך להגיע אליו (backlog הוא לא ממש תוכנית, רק רשימה). בעיקר חסרה היכולת להעריך מתי יושלם הפיתוח של features גדולים. כבר ראינו מדוע ניהול ה-backlog בעזרת טבלה (מיתוס 3) או גרף (מיתוס 17) נותן תחזית לא נכונה ומאפשר לזהות זאת כשמאוחר מדי.

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

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

נכתב ע"י רונית סנה
IntelliManage