Як оновлювати свій застосунок на ШІ, не ламаючи його для тих, хто вже ним користується

Першу версію вашого застосунку було легко змінювати. Якщо щось ламалося, єдина людина, що помічала, — це ви. Потім справжні люди почали ним користуватися — і тепер кожна зміна відчувається як операція на пацієнті, що не спить. Навчитися оновлювати застосунок на ШІ, не ламаючи його, — це здебільшого питання рутини, і ця рутина менша, ніж вам здається.

Знайома нам власниця репетиторського бізнесу навчилася цього болісним шляхом. Її застосунок для запису працював гладко місяцями, тож одного вечора вона попросила свій конструктор на ШІ невелике покращення: перейменувати «Сесія» на «Урок» усюди, бо саме це слово використовували її репетитори. Конструктор радо перейменував його — включно, як виявилося, з місцем, де зберігалися наявні бронювання. Наступного ранку троє репетиторів відкрили свої календарі й знайшли їх порожніми. Дані не зникли, але застосунок більше не міг їх знайти, і вона провела стресовий день, з’єднуючи їх назад.

Нічого в цій зміні не було нерозумного. У неї просто ще не було рутини, як оновлювати застосунок на ШІ, щойно в нього є користувачі. Цей допис — це та рутина — чотири звички, що займають, мабуть, п’ятнадцять додаткових хвилин на зміну й запобігають більшості катастроф.

Чому оновлення відчуваються інакше, щойно в вас є користувачі

Три речі змінюються тієї миті, коли хтось інший покладається на ваш застосунок:

Тепер у ньому є дані. Зміни, що були нешкідливими на порожньому застосунку — перейменування речей, реструктурування форм, — можуть від’єднати чи переплутати інформацію, яку люди вже ввели.
У людей є звички. Ваші користувачі вивчили, де кнопки. Навіть покращення — це порушення, якщо воно зсуває щось, чим вони користуються щодня.
Ви не можете обирати час проблем. Коли застосунок був лише вашим, зламаний вечір не мав значення. Тепер зламаний вівторковий ранок — це троє репетиторів із порожніми календарями.

Нічого з цього не означає, що вам варто перестати покращувати свій застосунок. Застосунки, що перестають змінюватися, помирають повільно замість раптово. Це означає, що зміни потребують трохи церемонії.

Звичка 1: Зробіть резервну копію, перш ніж щось торкати

Це та, що без торгу. Перед будь-якою зміною, більшою за виправлення друкарської помилки, переконайтеся, що у вас є актуальна резервна копія даних вашого застосунку — і знаєте, як її відновити.

Якщо ви вже налаштували автоматичні резервні копії, ця звичка зменшується до одного запитання вашому конструктору на ШІ: «Коли була остання резервна копія і як би я її відновив?» Якщо відповідь упевнена й свіжа, продовжуйте. Якщо ви ще не налаштували резервні копії, зробіть це перед наступним оновленням — ми написали повний гайд із резервного копіювання застосунку на ШІ, і це найкраща година, яку ви витратите на свій продукт цього місяця.

Історія про репетиторський застосунок вище мала щасливий кінець саме тому, що її платформа тримала резервні копії. Стресовий день інакше був би катастрофічним.

Звичка 2: Запитайте «що це може зламати?», перш ніж казати «так»

Ось запитання, яке більшість будівників ніколи не думає поставити, а воно робить більше роботи, ніж три інші звички разом. Після того, як ви описали зміну своєму конструктору на ШІ, і перш ніж її затвердити, додайте один рядок:

«Перш ніж робити цю зміну — які наявні функції чи дані вона може зачепити?»

Це працює, бо ШІ зазвичай бачить зв’язки, яких не бачите ви. Власниця репетиторського застосунку не могла знати, що «Сесія» також була назвою місця, де жили бронювання. Конструктор знав — вона просто ніколи не питала. Коли вона перебудувала свою рутину потім, це єдине запитання стало кроком, що ловив проблеми: воно позначило, що зміна її форми цін зачепить два старі рахунки, і що додавання обов’язкового поля заблокує наявних клієнтів, які зареєструвалися без нього.

Читайте відповідь, як пілот читає зведення погоди. «Це косметика, більше ніщо цього не торкається» — чисте небо, вперед. «Це змінить, як зберігаються бронювання» — це ваш сигнал сповільнитися, зробити резервну копію ще раз і, можливо, попросити лагіднішу версію зміни.

Звичка 3: Міняйте одну річ за раз і тестуйте її як незнайомець

Об’єднати п’ять покращень в одне велике оновлення здається ефективним. Насправді це навпаки: коли щось ламається, ви не знатимете, яке з п’яти спричинило це, а скасувати зламане означає скасувати всі п’ять.

Одна зміна, потім перевірка. Перевірка важить так само, як і розділення:

Використовуйте другий акаунт, а не свій акаунт власника. Ви бачите застосунок як його адміністратор; ваші користувачі — ні. Увійдіть як звичайний користувач — тримайте постійний тестовий акаунт саме для цього — і пройдіться шляхом, якого торкнулася ваша зміна. (Якщо ви ніколи раніше не тестували власний застосунок, ось як це робити без бекграунду в QA.)
Перевірте те, що ви змінили, і те, що поруч. Якщо ви оновили форму бронювання, зробіть бронювання — потім також відкрийте старе бронювання й переконайтеся, що воно все ще відображається. Більшість поломок від оновлень з’являється у старих даних, а не нових.
Робіть це зараз, а не завтра. Тестуйте одразу після зміни, поки вона свіжа й мала. Проблема, знайдена за п’ять хвилин після оновлення, очевидно спричинена оновленням. Проблема, знайдена в п’ятницю, могла бути чим завгодно.

Звичка 4: Оберіть тиху мить і знайте, як скасувати

Два останні відчуття щодо часу, які використовують професіонали, а нерозробники рідко про них чують:

Випускайте, коли ваші користувачі відсутні. Ви, ймовірно, знаєте ритм свого застосунку — репетиторський застосунок був найзайнятішим у будні пообіді, майже тихим недільними вечорами. Недільний вечір — це коли стаються зміни. Якщо щось піде не так, у вас є години, щоб виправити це, перш ніж хтось прийде, замість хвилин.

Знайте, як скасувати, перш ніж це знадобиться. Запитайте свій конструктор на ШІ: «Якщо ця зміна спричинить проблеми, чи можеш ти її відкотити? Що для цього треба?» Іноді відповідь — «один клік». Іноді це «відкотити зміну легко, але дані, створені після зміни, можуть не вписатися в стару версію». Ви хочете почути цю відповідь, поки ви спокійні, а не поки троє репетиторів вам пишуть.

А коли зміна видима користувачам — переміщена кнопка, перейменоване поле, новий крок — скажіть їм. Одне коротке повідомлення («Ви помітите, що Сесії тепер називаються Уроками — ті самі бронювання, дружніша назва») перетворює заплутану несподіванку на знак, що хтось активно дбає про продукт, на який вони покладаються.

П’ятнадцятихвилинна версія

Ось уся рутина, достатньо маленька, щоб тримати на стікері: резервна копія → запитай, що може зламатися → одна зміна за раз → тестуй як незнайомець, разом зі старими даними → тихі години → знай, як скасувати → скажи своїм користувачам.

Власники, що дотримуються чогось такого, оновлюють свої застосунки на ШІ не менше за безрозсудних — вони оновлюють більше, бо кожна зміна перестає бути азартною грою. Ось справжня винагорода: не уникання поломок, а збереження достатньої впевненості, щоб продовжувати покращувати річ, на яку люди розраховують.

Наступного разу, коли ви збиратиметеся попросити свій конструктор про зміну, спробуйте однорядкове запитання зі Звички 2 й подивіться, що воно виявить. А якщо це той допис, що нарешті змусить вас налаштувати резервні копії — почніть тут.