Как обновлять приложение на ИИ, не ломая его для тех, кто им уже пользуется

Первую версию вашего приложения было легко менять. Если что-то ломалось, единственным, кто это замечал, были вы. Затем им начали пользоваться реальные люди — и теперь каждое изменение ощущается как операция на пациенте, который не спит. Научиться обновлять приложение на ИИ, не ломая его, — в основном вопрос рутины, а рутина меньше, чем вы думаете.

Одна знакомая нам владелица репетиторского бизнеса усвоила это болезненным путём. Её приложение для расписания месяцами работало без сбоев, поэтому однажды вечером она попросила свой ИИ-конструктор о небольшом улучшении: переименовать «Сессия» в «Урок» везде, потому что именно это слово использовали её репетиторы. Конструктор охотно переименовал — включая, как выяснилось, и то место, где хранились существующие записи на занятия. На следующее утро три репетитора открыли свои календари и обнаружили их пустыми. Данные не пропали, но приложение больше не могло их найти, и она провела напряжённый день, восстанавливая связь.

В том изменении не было ничего необоснованного. У неё просто ещё не было рутины, как обновлять приложение на ИИ, когда у него есть пользователи. Эта статья — и есть та рутина: четыре привычки, которые занимают, может, пятнадцать дополнительных минут на изменение и предотвращают большинство катастроф.

Почему обновления ощущаются иначе, когда у вас есть пользователи

Три вещи меняются в тот момент, когда на ваше приложение начинает полагаться кто-то ещё:

• Теперь в нём есть данные. Изменения, которые были безобидными на пустом приложении — переименование, перестройка форм, — могут отвязать или перепутать информацию, которую люди уже ввели.
• У людей есть привычки. Ваши пользователи выучили, где находятся кнопки. Даже улучшение — это нарушение, если оно сдвигает то, чем они пользуются каждый день.
• Вы не можете выбирать время для проблем. Когда приложение было только вашим, сломанный вечер не имел значения. Теперь сломанное утро вторника — это три репетитора с пустыми календарями.

Ничто из этого не означает, что вы должны перестать улучшать приложение. Приложения, которые перестают меняться, умирают медленно, а не внезапно. Это означает, что изменениям нужна капля церемонии.

Привычка 1: делайте бэкап, прежде чем что-либо трогать

Это та, что не обсуждается. Перед любым изменением крупнее, чем исправление опечатки, убедитесь, что у вас есть актуальный бэкап данных приложения — и что вы знаете, как восстановиться.

Если вы уже настроили автоматические бэкапы, эта привычка сжимается до одного вопроса вашему ИИ-конструктору: «Когда был последний бэкап и как мне восстановиться из него?» Если ответ уверенный и свежий — действуйте. Если вы ещё не настроили бэкапы, сделайте это до следующего обновления — мы написали полное руководство по резервному копированию приложения на ИИ, и это лучший час, который вы потратите на свой продукт в этом месяце.

У истории с репетиторским приложением выше был счастливый конец именно потому, что её платформа хранила бэкапы. Иначе напряжённый день обернулся бы катастрофическим.

Привычка 2: спрашивайте «что это может сломать?» до того, как сказать «да»

Вот вопрос, который большинству разработчиков и в голову не приходит задать, а он делает больше работы, чем остальные три привычки вместе взятые. После того как вы описали изменение своему ИИ-конструктору и прежде чем его одобрить, добавьте одну строчку:

«Прежде чем внести это изменение — на какие существующие функции или данные оно может повлиять?»

Это работает, потому что ИИ обычно видит связи, которых не видите вы. Владелица репетиторского приложения не могла знать, что «Сессия» — это также название места, где жили записи. Конструктор знал — она просто не спросила. Когда она потом перестроила свою рутину, этот единственный вопрос стал шагом, который ловил проблемы: он отметил, что изменение её формы цен затронет два старых счёта, и что добавление обязательного поля заблокирует существующих клиентов, которые зарегистрировались без него.

Читайте ответ как пилот читает сводку погоды. «Это косметика, ничего больше с этим не связано» — ясное небо, вперёд. «Это изменит то, как хранятся записи» — это ваш сигнал притормозить, снова сделать бэкап и, возможно, попросить более щадящую версию изменения.

Привычка 3: меняйте по одной вещи за раз и тестируйте как незнакомец

Объединять пять улучшений в одно большое обновление кажется эффективным. На деле всё наоборот: когда что-то сломается, вы не узнаете, какое из пяти стало причиной, а отмена сломанного означает отмену всех пяти.

Одно изменение, затем проверка. Проверка важна не меньше, чем разбиение:

• Используйте второй аккаунт, а не аккаунт владельца. Вы видите приложение как его администратор; ваши пользователи — нет. Войдите как обычный пользователь — держите постоянный тестовый аккаунт ровно для этого — и пройдите по пути, которого коснулось ваше изменение. (Если вы никогда раньше не тестировали собственное приложение, вот как это делать без бэкграунда в QA.)
• Проверьте то, что вы изменили, и то, что рядом с этим. Если вы обновили форму записи, сделайте запись — а затем откройте и старую запись и убедитесь, что она всё ещё отображается. Большинство поломок от обновлений проявляется в старых данных, а не в новых.
• Делайте это сейчас, а не завтра. Тестируйте сразу после изменения, пока оно свежее и небольшое. Проблема, найденная через пять минут после обновления, очевидно вызвана обновлением. Проблема, найденная в пятницу, может быть чем угодно.

Привычка 4: выберите тихий момент и знайте свой откат

Два последних чувства тайминга, которыми пользуются профессионалы и о которых не-разработчики редко слышат:

Выпускайте, когда ваши пользователи в отлучке. Вы наверняка знаете ритм своего приложения — репетиторское было занятее всего в будние дни после обеда и почти безмолвным воскресными вечерами. Воскресный вечер — это когда происходят изменения. Если что-то пойдёт не так, у вас есть часы, чтобы починить, прежде чем кто-то придёт, а не минуты.

Знайте свой откат до того, как он понадобится. Спросите свой ИИ-конструктор: «Если это изменение вызовет проблемы, ты сможешь его откатить? Что для этого потребуется?» Иногда ответ — «один клик». Иногда — «откатить изменение легко, но данные, созданные после изменения, могут не подойти к старой версии». Вы хотите услышать этот ответ, пока спокойны, а не пока три репетитора пишут вам.

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

Версия на пятнадцать минут

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

Владельцы, которые следуют чему-то подобному, обновляют свои приложения на ИИ не реже безрассудных — они обновляют чаще, потому что каждое изменение перестаёт быть азартной игрой. В этом и есть настоящая отдача: не в избегании поломок, а в том, чтобы оставаться достаточно уверенным, чтобы продолжать улучшать то, на что люди рассчитывают.

В следующий раз, когда соберётесь попросить конструктор об изменении, попробуйте вопрос из одной строки из Привычки 2 и посмотрите, что он выявит. А если это та статья, которая наконец подтолкнёт вас настроить бэкапы, — начните здесь.