Объём перестройки за 24 часа: одна траектория, чёткие критерии приёмки

Когда прототип действительно непригоден

Прототип непригоден, когда его починка занимает больше времени и несёт больше рисков, чем перестройка небольшого, надёжного варианта. Это часто встречается в AI‑сгенерированных приложениях: в демо всё выглядит нормально, а с реальными пользователями регистрация, сброс пароля или оплата разворачивают проблемы.

Явные признаки появляются быстро:

• Баги возвращаются после небольших изменений (хрупкий код).
• Пробелы безопасности, которые вы не можете уверенно закрыть (раскрытые секреты, слабая аутентификация, риск инъекций).
• Запутанная логика, когда никто не может объяснить, что сломается после правки.
• Отсутствуют основы (нет тестов, неясная модель данных, грязное управление состоянием).
• Поведение «работает у меня на машине», которое блокирует деплой.

Попытки «исправить всё подряд» обычно взрывают сроки. Каждая правка обнаруживает ещё одну зависимость, ещё одно жёстко захардкоженное предположение, ещё один кусок кода, собранный без плана. Работа превращается в бесконечную отладку вместо построения.

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

Определите цель для 24‑часовой перестройки

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

Относитесь к цели как к контракту по времени. Каждое решение должно отвечать на вопрос: сохраняет ли это нас в рамках 24 часов или превращает в более продолжительный проект?

Как выглядит успех

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

Напишите одно короткое заявление об успехе, которое можно произнести вслух. Пример: «Новый пользователь может зарегистрироваться, войти, выполнить основное действие и увидеть результат — с обработкой ошибок и корректным сохранением данных.»

Затем добавьте приёмочные проверки, которые легко верифицировать:

• Траектория работает сквозным образом в чистой среде с реальными значениями конфигурации.
• Ошибки показывают понятное сообщение (не пустой экран).
• Данные сохраняются и корректно появляются после обновления страницы.
• Базовая безопасность обеспечена (нет раскрытых секретов, устранены очевидные инъекции).
• Деплой на выбранный хост работает без ручных хаков.

Что пока не делаем

Чтобы защитить временной лимит, явно укажите, что откладывается. Частые «ещё не» элементы: полноценно roles/права, кейсы оплаты, админ‑дашборд, аналитика, оптимизация производительности и большие миграции.

Простое правило: помечайте каждую просьбу как «требуется для этой одной траектории» или «в будущем». Если это «в будущем», отложите.

Конкретный пример: для прототипа бронирования цель первого дня может быть «поиск доступности и подтверждение брони». Отзывы, купоны, реферальные программы и импорт старых тестовых данных можно отложить.

Выберите одну пользовательскую траекторию для перестройки в первую очередь

Подход сработает только если вы выберете одну траекторию и всё остальное отнесёте к «потом». Выберите ту, которая приносит наибольшую ценность быстро (первое «ага») или снимает самый большой риск (например, сломанная аутентификация или небезопасные записи данных).

Избегайте траекторий, которые кажутся простыми, но скрывают сложные зависимости. «Просмотр дашборда» часто зависит от прав, модели данных, фоновых задач и крайних случаев. Лучше выбрать первую траекторию, которая вынуждает открыть основы: вход, реальная запись в базу и один понятный экран успеха.

Опишите траекторию в 5–10 простых шагах. Пусть каждый шаг — действие или то, что видит пользователь, а не внутренняя задача.

Пример (регистрация до первого сохранённого объекта):

Шаг 1: Пользователь открывает приложение. Шаг 2: Пользователь нажимает «Создать аккаунт». Шаг 3: Пользователь вводит e‑mail и пароль. Шаг 4: Приложение валидирует и создаёт аккаунт. Шаг 5: Пользователь попадает на главный экран. Шаг 6: Пользователь создаёт первый объект (заметка, задача, лид и т. п.). Шаг 7: Приложение сохраняет его и показывает в списке.

Напишите приёмочные проверки, чтобы все были на одной волне

День перестройки провалится, если «готово» расплывчато. Превратите выбранную траекторию в чёткие проверки «пройден/не пройден». Если проверку можно обсуждать — перепишите её.

Пишите проверки так, будто вы тестируете как впервые уставший пользователь, который делает реальные ошибки. Держите их маленькими и конкретными. Привязывайте к видимому поведению (что видит пользователь) плюс к одному‑двум фактам на бэкенде (что должно быть верно за сценой).

Пример проверок для «вход и попадание в дашборд»:

• Успешный вход: С валидным e‑mail и паролем пользователь попадает в дашборд и видит своё имя в течение 3 секунд.
• Неправильный пароль: С валидным e‑mail и неверным паролем приложение показывает понятную ошибку и не выполняет вход.
• Пустая форма: Если e‑mail или пароль пусты, приложение блокирует отправку и показывает, что пропущено.
• Надёжность: После входа обновление страницы сохраняет сессию (или явно выходит). В медленной сети приложение показывает состояние загрузки и не отправляет форму дважды.
• Базовая безопасность: Дашборд требует аутентификации (нет прямого доступа), вводы валидируются, секреты не раскрыты в клиенте.

Добавьте один‑два крайних случая, подходящих для вашего продукта (просроченная magic‑ссылка, заблокированный аккаунт, удалённый пользователь). Не добавляйте все будущие функции.

Сожмите объём до минимального шипабельного среза

Думайте о скоупе как о багажной сумке на ночь: берёте то, что нужно на завтра, а не всё, что у вас есть.

Ограничьте объём только тем, что касается выбранной траектории. Запишите это в виде трёх инвентарей: экраны, API‑эндпойнты и данные. Всё, что не в списке, — вне рамок, даже если кажется быстрым.

Простое определение среза:

• Экраны, необходимые для завершения траектории
• API‑эндпойнты, которые эти экраны используют (auth, read, write)
• Модель данных и поля, нужные для этого потока

Внешние зависимости часто дробят перестройки. Если зависимость медленно настраивается или её трудно тестировать, замокайте её в первые 24 часа и оставьте чёткое место для подмены на реальную. Пример: сохраняйте статус «оплата ожидает/успех» и возвращайте фейковый успешный ответ вместо попытки закончить настройку биллинга под давлением.

Зафиксируйте границы письменно, чтобы никто не «ещё чуть‑чуть» не добавил лишнего:

• Никаких редизайнов или полировки UI сверх базовой удобочитаемости
• Никаких миграций, если траектория может работать без них
• Никакого паритета с старым прототипом
• Никаких рефакторов вне перестроенного среза
• Никаких новых интеграций, если они не требуются для завершения траектории

Практический план на 24 часа (по шагам)

Относитесь ко дню как к срочной поставке, а не спасательной миссии. Цель — одна рабочая траектория в условиях продакшена, с чёткими приёмочными проверками и коротким списком ограничений (стек, хостинг, данные, которые нужно сохранить, и что мы сегодня не делаем).

Простой план:

• Часы 0–2: Зафиксируйте одну траекторию, напишите приёмочные проверки, подтвердите ограничения (аккаунты, роли, платежи, e‑mail или их отсутствие) и заморозьте список фич. Зафиксируйте известные риски вроде отсутствующих API‑ключей.
• Часы 2–8: Постройте основной поток сквозь все слои с минимальным UI, доказывающим работоспособность. Держите верстку простой.
• Часы 8–16: Добавьте скучные, но критичные части: правила аутентификации, валидацию вводов, проверки прав, безопасные записи в БД и понятные ошибки.
• Часы 16–22: Прогоните приёмочные проверки как тест‑скрипт. Исправьте провалы, удалите мёртвый код, убедитесь, что поведение воспроизводимо.
• Часы 22–24: Подготовьте деплой и напишите короткую заметку для передачи: что построено, как запускать, известные пробелы, что дальше.

Пример: если траектория «регистрация → создание workspace → приглашение коллеги», отправьте это с базовыми экранами, реальными правилами прав и понятными ошибками. Не добавляйте аватары, аналитику или админ‑панель.

Безопасно откладываем некритичные функции и миграции

«Хорошо было бы» — причина, по которой однодневная перестройка превращается в неделю.

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

Миграции — другой убийца времени. Если возможно, сохраните текущую модель данных в день один, даже если она не идеальна. Если старая модель грязная, положите тонкий адаптер поверх неё, чтобы новый код разговаривал со стабильным интерфейсом.

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

Несколько безопасных паттернов:

• Оставьте существующие таблицы и добавьте функцию‑транслятор или view в коде.
• Пишите новые данные в старую схему сейчас, а будущие поля храните в metadata.
• Если нужно менять поле — делайте добавочное изменение (новая колонка), а не перестройку всего.
• Добавьте валидацию на границе чтения/записи, а не по всему приложению.

Когда кто‑то говорит «нам нужна аналитика, роли, платежи», относите это к доп. возможностям, если это не требуется для единственной траектории. Для первого дня простая таблица логов событий заменит полноценную аналитику. Одна админ‑роль может заменить полную систему ролей. Ручная выставляемая накладная может заменить биллинг, если заряд — не ключевой сценарий.

Ведите маленький «паркинг‑лот» с владельцем и триггером, когда пункт становится «сейчас».

Частые ловушки, которые портят 24‑часовую перестройку

Большинство срываний дедлайнов происходят из предсказуемого расширения объёма.

Одна ловушка — перестраивать две траектории одновременно. Кажется эффективным сделать onboarding и биллинг вместе, но это удваивает решений, экраны и крайние случаи. Выберите одну траекторию и сделайте её надёжной.

Ещё одна ловушка — расплывчатые приёмочные проверки. Если команда не может ответить «сдано/нет» вы будете спорить до поздней ночи.

Повторяющиеся ошибки:

• Начать вторую траекторию «чуть‑чуть», когда первая почти готова
• Проверки вроде «работает» или «достаточно быстро» без четкого pass/fail
• Недооценка аутентификации и прав
• Вмешивание миграций в день перестройки
• Постройка только счастливого пути и игнорирование ошибок

Аутентификация заслуживает отдельного предупреждения. «Простой вход» часто скрывает часы работы: истечение сессий, сброс пароля, проверки прав на каждом эндпойнте, лимиты запросов. Если вы не заскоупите её, она заскоупит вас.

Быстрый чеклист перед объявлением «готово»

Прежде чем остановить часы, докажите, что перестройка работает для реальных пользователей, а не только в вашей dev‑среде.

Используйте это как gate релиза:

• Выбранная траектория завершена сквозным образом без ручных правок в базе. Создайте новый аккаунт (или тестового пользователя), выполните основное действие и подтвердите, что результат сохранён и виден после свежего перезагрузки.
• Аутентификация на местах: защищённые страницы блокируют анонимов, публичные страницы остаются публичными, и секреты не появляются в клиентском коде или логах.
• Вводы обрабатываются безопасно: обязательные поля проверяются, некорректные значения показывают понятные сообщения, и вы не получаете пустые экраны.
• Базовая производительность в норме: повторные клики не создают дубликатов, а основное действие не таймаутится случайно.
• Деплой не загадка: сборка проходит в чистой среде, все нужные env‑переменные перечислены (имя, назначение, пример формата), и есть простая заметка про откат.

Пример: если траектория «регистрация → создать проект → пригласить коллегу», протестируйте её в режиме инкогнито, затем повторите с вторым пользователем. Если для работы нужны скрытые шаги — это не готово.

Пример: скоп перестройки для сломанного AI‑приложения

Распространённый непригодный случай: AI‑собранное приложение, где вход иногда работает, ломается после обновления страницы, а сохранённые данные появляются случайно (или не появляются вовсе). Можно потратить дни на поиск призраков. Однодневная перестройка часто быстрее, если выбрать один чистый путь и сделать его скучным и надёжным.

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

Приёмочные проверки, которые вы проверите за минуты:

• Новый пользователь может зарегистрироваться и автоматически попадает в систему.
• Вошедший пользователь может выйти и успешно войти снова.
• Аутентификация сохраняется после обновления страницы (сессия хранится или явно истекает).
• Создание одного объекта проходит успешно и показывает состояние успеха.
• Объект сразу появляется в списке пользователя.

Добавьте проверки, которые ловят «работает у меня» отказоустойчивость:

• Объект остаётся после закрытия браузера и возврата позже.
• Каждый пользователь видит только свои объекты.
• Секреты не раскрыты в браузере или логах.
• Ошибки показывают понятные сообщения и не стирают работу пользователя.
• Поток работает в обычном и приватном окне браузера.

Отложите: админ‑роли, полное редизайн, миграцию провайдера и сторонние интеграции (платежи, e‑mail, аналитика). Запишите их с заметками.

«Готово за 24 часа» означает, что основной поток стабилен, задеплоен и тестируем не‑техническим человеком, с чётким списком того, что намеренно не сделано.

Следующие шаги после первых 24 часов

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

Держите всё на одной странице:

• Приёмочные проверки (выполнено): что прошло, в каком окружении и какие известные ограничения
• Паркинг‑лот (потом): фичи, интеграции, миграции, пожелания
• Открытые риски: пробелы безопасности, краевые случаи с данными, проблемы с производительностью
• Владелец + дата: кто решает, что дальше, и когда будет ревью
• Выбор на день 2: одно внимание для следующего рабочего блока

День 2 может быть второй траекторией, проходом по безопасности (особенно если трогали auth, платежи или данные пользователей) или добавлением мониторинга для быстрого обнаружения реальных сбоев. Миграции начинайте только если реально нужно переносить данные сейчас.

Если вы унаследовали AI‑сгенерированную кодовую базу от Lovable, Bolt, v0, Cursor или Replit, короткая диагностика перед расширением объёма часто экономит часы угадываний.

Если хотите второе мнение по сломанному AI‑сгенерированному прототипу, FixMyMess (fixmymess.ai) специализируется на диагностике и ремонте AI‑сгенерированных кодбаз, включая усиление безопасности и приведение к продакшен‑уровню. Они предлагают бесплатный аудит кода для картирования проблем, и многие исправления выполняются в течение 48–72 часов.