החלפת מוצר תוכנה: איך מתכננים תקופה עם שתי גרסאות?

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

מה מלמד הסיפור של FreshBooks?

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

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

מגדירים גבול ברור לניסוי

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

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

מחליטים איפה נרשמת העבודה

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

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

מתקצבים את התקופה הכפולה

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

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

הפרדה מעשית מכלי הפרסום שלנו

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

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

מתכננים חזרה וסיום מראש

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

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