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

Начните с одной операции

Выберите сценарий, за который продукт будут покупать. Для площадки это может быть создание заявки и её обработка, а для кабинета предоставление клиенту доступа к собственным данным. Опишите исходное состояние, действие пользователя и результат, который должен сохраниться после закрытия браузера.

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

Отделите фасад от реализации

В 2020 году ко мне обратились фаундеры эстонского проекта. Разработка шла два года, сменились две команды. По результатам моего аудита за внешним фасадом не оказалось необходимой реализации. После разбора я создал новую краудфандинговую платформу с нуля за три месяца. Дальнейшая версия развивалась девять месяцев двухнедельными итерациями, включая интеграцию LemonWay.

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

Попросите минимальный набор доказательств

Для ближайшего результата достаточно связки из нескольких вещей:

  • задача с понятным ожидаемым поведением;
  • изменение кода, которое её реализует;
  • тест или повторяемая инструкция проверки;
  • доступная версия на тестовом окружении;
  • известные ограничения и решение, что с ними делать.

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

Проверяйте неприятный путь

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

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

Сделайте статус пригодным для решения

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

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

Когда достаточно второго мнения

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

В TechnicalAngel эти роли разделены. Можно начать с проверки конкретного решения, а затем менять уровень только тогда, когда действительно меняется моя ответственность. Посмотреть реальный кейс или сравнить форматы участия.