Приложение «готово на 90%»: что проверить после вайбкодинга

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

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

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

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

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

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

Пройдите основные действия под разными ролями: покупатель, сотрудник, администратор. Может ли покупатель увидеть чужой заказ по изменённой ссылке? Остаётся ли доступ у отключённого сотрудника? Можно ли изменить цену отправленным запросом, даже если поле скрыто на странице? Такие проверки должен выполнять специалист в согласованной тестовой среде.

Техническую проверку безопасности можно строить на OWASP ASVS — открытом стандарте требований к защитным механизмам web-приложений. Он помогает договориться о составе проверки. Наличие чек-листа или отчёта само по себе не означает, что продукт получил гарантию безопасности.

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

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

Затем проверьте восстановление на тестовой копии: вернулись ли нужные данные, сохранились ли связи между заказами и платежами, понятны ли действия сотруднику. Файл резервной копии и успешное восстановление — разные результаты. Для продуктов с офлайн-режимом добавляется отдельный вопрос: как разрешаются изменения, сделанные до синхронизации.

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

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

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

В видео о проекте, готовом на 90% разобрана эта ловушка оценки по видимому результату. Если приложение уже собрано, начните с одного критичного сценария и перечня условий его запуска. Такой материал можно принести на обсуждение технического аудита: разговор будет о рисках конкретного продукта и вариантах продолжения.