Когда приложение, созданное с ИИ, перерастает свою первую версию: рефакторинг или переписывание
Вы что-то выпустили. Пользователям понравилось. Теперь у вас десять пользователей, и их потребности не укладываются в ту форму, что вы построили. Вот как решить — рефакторить текущее приложение или признать, что это был прототип, и пересобрать его как надо.
Вы что-то выпустили. Пользователям понравилось. Теперь у вас десять пользователей, и они хотят функций, которые не укладываются в исходную форму. Вы стоите на развилке: латать приложение под новый сценарий или признать, что первая версия была прототипом, и построить как надо. Это вопрос, который убивает больше небольших проектов, чем любой другой, потому что у него нет технического ответа — только деловой.
Момент, когда вы понимаете, что приложение успешно
Большинство приложений, созданных с ИИ, начинаются как одно, а становятся другим. Вы сделали форму приёма клиентов для своей коучинговой практики; теперь клиенты хотят видеть прошлые встречи и сами переносить их. Вы сделали инструмент для скоринга лидов; теперь отдел продаж хочет, чтобы сводки выгружались в их CRM. Вы сделали систему хранения файлов; теперь люди хотят работать внутри неё совместно.
Каждый запрос разумен. Каждый из них немного уводит приложение от того, чем оно задумывалось. И в какой-то момент — через полгода, или через два месяца, иногда через две недели — вы чувствуете трение. Всё, что вы добавляете, борется с фундаментом. Новые функции требуют: «а, нам сначала нужно переорганизовать вот эту часть». Приложение замедляется. На изменения уходит больше времени.
Это ощущение — ваш сигнал задуматься: это всё ещё то же самое приложение, или вы из него выросли?
Что даёт и чего стоит рефакторинг
Рефакторинг означает сохранить то же приложение, но навести в нём порядок, чтобы можно было строить дальше. Вы просите свой ИИ-конструктор переорганизовать код, разбить переусложнённый процесс или переделать экран, превратившийся в свалку функций. На это уходит несколько часов. Это не добавляет новых функций. Это просто делает фундамент крепче.
Когда рефакторинг срабатывает — это магия. Вы будто боролись с приложением; и вдруг — больше не боретесь. Вы добавляете три новые функции за неделю — те, что раньше заняли бы три недели.
Но рефакторинг работает только если проблема в форме того, что у вас есть. Если вы сделали форму приёма, а пользователи хотят более быструю форму приёма — рефакторинг медленной части это работа на полдня. Если они хотят форму приёма, которая быстрее и хранит историю — это всё ещё одно приложение, и рефакторинг может помочь. Но если они хотят историю встреч, интеграции с календарём, SMS-напоминания и выставление счетов — вы уже строите не «более удачную форму приёма», вы строите бэк-офис для коучинговой практики. А это другой продукт.
Что даёт и чего стоит переписывание
Переписывание означает: вы поняли, чем приложение на самом деле должно быть, и собираетесь построить его с нуля уже с этим знанием. Вы не выбрасываете первую версию — ваши пользователи по-прежнему на неё опираются. Но вы строите новое приложение с фундамента, опираясь на то, чему вас научило старое, а затем переводите пользователей, когда оно готово.
Переписывание ощущается как расточительство. Вы что-то построили — а теперь строите это заново. Это психологическая цена. Практическая цена — время: на новую версию у вас уйдёт от двух до четырёх месяцев, прежде чем она будет готова к переводу пользователей. У вас больше не будет первой версии как костыля — вы движетесь вперёд без страховки.
Но переписывание даёт вам одну вещь, которую не даёт ничто другое: свободу. Новое приложение не стеснено формой старого. Если исходник был простой формой, а новое должно стать полноценным бэк-офисом, вы проектируете под это с самого начала. Если важна производительность — вы проектируете под неё. Если важны безопасность, интеграции или процессы — это не доделки задним числом, это часть фундамента.
Приложения, которые добиваются успеха после пересборки, обычно делают это потому, что понимание проблемы у команды ушло настолько далеко от исходного кода, что попытки латать были как ношение одежды, которая не совсем сидит. Переписывание означало строить под себя.
Три вопроса, чтобы выбрать между ними
Вопрос 1: Верна ли всё ещё базовая форма?
Ваша базовая форма — это один-два главных процесса, которые определяют приложение. Для коучинговой формы приёма это «клиент заполняет анкету, коуч просматривает, коуч назначает встречу». Если вы добавляете другие процессы — выставление счетов, управление календарём, переписку с клиентами — вы не расширяете ядро, вы прикручиваете сбоку побочные функции. Это признак того, что вы строите другой продукт, а значит — переписывание.
Если вы добавляете вариации того же ядра — «приём для частных лиц, приём для команд, приём с настраиваемыми полями» — это всё ещё то же приложение. Рефакторьте и расширяйте его.
Вопрос 2: Если вы сделаете рефакторинг сегодня, через сколько месяцев трение ударит снова?
Будьте честны. Если трение уйдёт на полгода — рефакторинг правильный ход. Если оно снова заболит через два месяца, потому что проблема не в форме кода, а в самом фундаменте, — тогда переписывание избавит вас от ложной экономии «залатать дважды». Спросите свой ИИ-конструктор: «Если мы наведём здесь порядок, через сколько нам придётся делать это снова?» Если ответ «вероятно, скоро» — пора пересобирать.
Вопрос 3: На что на самом деле опираются ваши пользователи?
Если у вас три активных пользователя на v1 и вы думаете о пересборке — вы можете перевести их за день-два. Если у вас пятьдесят пользователей, чья работа критически зависит от текущего приложения, — переписывание означает, что вам придётся месяцами поддерживать обе версии в рабочем состоянии, а это своя особая боль.
Путь, который обычно работает
Большинство основателей, у которых пересборка получается, делают её параллельно: они держат исходное приложение работающим и используют свободные ресурсы, чтобы строить новое. Когда у нового появляется функциональный паритет со старым, они тратят неделю на миграцию данных и пользователей — и готово.
Путь, который обычно не работает: рефакторинг, рефакторинг, рефакторинг — пока после третьего рефакторинга вы не осознаёте, что архитектура всё ещё неверна, а вы уже слишком вложились в «старую» версию, чтобы это признать и начать заново.
Подходящий момент, чтобы решить
В следующий раз, когда почувствуете трение, спросите себя: «Я заставляю это приложение делать лучше то, для чего оно было задумано? Или я прошу его быть тем, для чего оно никогда не проектировалось?» Если первое — рефакторьте. Если второе — нет ничего постыдного в том, чтобы построить с самого начала то, чем оно и должно было быть. Большинство успешных приложений живут на версии 2 своего ядра, а не на версии 1.