איך לעדכן את האפליקציה שבניתם עם בינה מלאכותית בלי לשבור אותה לאנשים שכבר משתמשים בה

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

בעלת עסק שיעורים פרטיים שאנחנו מכירים למדה את זה בדרך הכואבת. אפליקציית התזמון שלה רצה חלק במשך חודשים, אז ערב אחד היא ביקשה מהכלי שלה שיפור קטן: לשנות את השם של “Session” ל-”Lesson” בכל מקום, כי זו המילה שהמורים שלה באמת השתמשו בה. הכלי בשמחה שינה את השם — כולל, כך התברר, את המקום שבו ההזמנות הקיימות נשמרו. בבוקר שלמחרת, שלושה מורים פתחו את היומנים שלהם ומצאו אותם ריקים. הנתונים לא נעלמו, אבל האפליקציה כבר לא יכלה למצוא אותם, והיא בילתה יום מלחיץ בלחבר אותם מחדש.

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

למה עדכונים מרגישים שונה ברגע שיש לכם משתמשים

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

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

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

הרגל 1: גבו לפני שאתם נוגעים במשהו

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

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

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

הרגל 2: שאלו “מה זה יכול לשבור?” לפני שאתם אומרים כן

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

“לפני שאתה עושה את השינוי הזה — אילו פיצ’רים או נתונים קיימים זה יכול להשפיע עליהם?”

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

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

הרגל 3: שנו דבר אחד בכל פעם, ובדקו אותו כמו זר

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

שינוי אחד, ואז בדקו. הבדיקה חשובה כמו הפיצול:

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

הרגל 4: בחרו רגע שקט, ודעו את הביטול שלכם

שני חלקים אחרונים של חוש תזמון שמקצוענים משתמשים בהם ולא-מתכנתים נדיר ששומעים עליהם:

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

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

וכששינוי גלוי למשתמשים — כפתור שזז, שדה ששמו שונה, צעד חדש — ספרו להם. הודעה קצרה אחת (“תשימו לב ש-Sessions נקראים עכשיו Lessons — אותן הזמנות, שם ידידותי יותר”) הופכת הפתעה מבלבלת לסימן שמישהו מטפל באופן פעיל במוצר שהם סומכים עליו.

הגרסה של חמש-עשרה דקות

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

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

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