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

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

Мера соответствия — документ, который подрядчик подписал сам

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

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

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

Считайте готовность деньгами, а не задачами

«Сделано 8 из 11 блоков» — бессмысленная метрика. Блоки стоят по-разному, и три оставшихся могут быть половиной бюджета. Считать надо взвешенно по стоимости.

Возьмите перечень работ со стоимостями и проставьте напротив каждой строки честную оценку готовности. Картина меняется радикально. В одном из проектов, который я разбирал, по количеству пунктов выходило «больше половины», а взвешенно по деньгам — 27–35%: самые дорогие блоки оказались нетронутыми, а сделанным было то, что дешевле.

Отдельно отмечайте строки с готовностью «ноль». Не «мало сделано», а именно ноль: ни строчки кода, ни таблицы в базе, ни подключённой библиотеки. Такие блоки в любом сколько-нибудь крупном проекте обычно находятся — и именно они дают самый весомый аргумент.

Пять проверок за час и без разработчика

Для этого нужен доступ к репозиторию на чтение. Если его не дают — это уже ответ; в договорах на разработку доступ заказчика к коду обычно предусмотрен.

1. Запускаются ли тесты при сборке

Откройте файл конфигурации сборки (в разных системах это .gitlab-ci.yml, .github/workflows/*.yml, Jenkinsfile) и найдите перечень стадий. Выглядит он примерно так:

stages:
  - build
  - publish
  - deploy

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

2. На чём собран проект

Откройте файл зависимостей (package.json, composer.json, requirements.txt) и посмотрите на версии. Тревожные признаки:

  • beta, alpha, rc, nightly, canary в номерах версий — это предрелизные сборки, которые сами авторы не рекомендуют для боевого использования;
  • "latest", "*", "next" вместо конкретной версии — проект будет собираться по-разному в разные дни и может сломаться сам по себе, без единой правки;
  • требование очень свежей версии платформы, которая ещё не вышла в стабильном статусе.

Один-два таких пункта — обычное дело. Когда на предрелизных версиях стоит фундамент проекта, вы платите за эксперимент подрядчика на своих деньгах.

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

3. Есть ли документация

Загляните в папку docs/ и в файл README.md. Вас интересует не инструкция по запуску для разработчиков, а описание системы: как устроена, как связаны части, где какие данные, как это разворачивать и поддерживать.

Документация — это то, что остаётся у вас навсегда и почти всегда входит в оплачиваемый объём. Когда её нет, устройство системы живёт в головах нескольких человек и в переписке. Практический смысл простой: вы привязаны к этой команде. Новый подрядчик будет вынужден расследовать чужой код без карты — это долго, дорого и часто заканчивается предложением всё переписать.

Отдельно посмотрите, не осталось ли в README текста от стартового шаблона, на котором начинали проект. Это мелочь, но красноречивая.

4. Нет ли выдуманных данных на витрине

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

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

5. Что обещает интерфейс

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

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

Демо на живом стенде, а не по записи

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

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

Три вопроса, которые нельзя обойти общими словами

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

  1. Проведите при нас полный сценарий с деньгами — от действия пользователя до появления средств на счёте. Не описание, а выполнение на стенде.
  2. Зарегистрируйте при нас нового пользователя целиком — со всеми проверками, которые обещаны в интерфейсе, до состояния «готов пользоваться».
  3. Покажите, что происходит при нагрузке — результаты нагрузочного тестирования, если оно требовалось по договору. Заявление «выдержит тысячу пользователей» без испытаний — это не характеристика, а надежда.

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

«Это же MVP» — самая частая подмена понятий

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

MVP — minimum viable product, минимально жизнеспособный продукт. Ключевое слово «жизнеспособный». Это не «недоделанная версия всего понемногу», а продукт с намеренно узким набором функций, которым реально можно пользоваться — с оговорками, но без катастрофических рисков. Функций мало, но то, что есть, работает и безопасно.

Проверьте текущее состояние по трём признакам:

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

Если ни по одному пункту не проходит, честное название — ранний черновик. Это не придирка к терминам: от того, MVP перед вами или черновик, зависит, имеет ли смысл его доделывать.

Фундамент и отделка

Отсюда следует главный вопрос приёмки: чего именно не хватает — отделки или фундамента?

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

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

Мотивированный отказ — не скандал, а процедура

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

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

Именно поэтому проверки выше стоит проводить до получения акта, а не после. Срок на отказ короткий, и собрать за него фактуру, когда в проекте пятьдесят тысяч строк кода, нереально.

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

Чек-лист

  1. Найти документ, где подрядчик сам расписал состав этапа.
  2. Проставить готовность по каждой строке и посчитать взвешенно по стоимости.
  3. Выписать блоки с нулевой готовностью отдельно.
  4. Проверить: запускаются ли тесты при сборке; на каких версиях собран проект; есть ли документация; не вшиты ли данные в витрину; что обещает интерфейс.
  5. Провести демо на живом стенде, по своему списку вопросов, в формате «проведите при нас».
  6. Отделить недостающие функции от недостающего фундамента.
  7. Зафиксировать состояние кода на день проверки.
  8. Успеть до срока на мотивированный отказ.

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

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