Типичная картина: раз в две недели созвон, подрядчик делится экраном, показывает работающий сценарий и спрашивает, всё ли нравится. Ответить нечего — картинка выглядит убедительно, а языка, на котором можно проверить, у заказчика нет. Так проект и принимается: не по результату, а по впечатлению от показа. Ниже — два пути приёмки, которые из этой ситуации ведут, и честный разбор, кому подходит каждый.
Путь первый: приёмка по демонстрации
Подрядчик собирает работающий кусок и показывает его вживую. Заказчик смотрит, задаёт вопросы, говорит «нравится» или «переделайте вот тут». Этап считается принятым, когда показ прошёл спокойно.
Путь честный по замыслу и рабочий там, где результат видно глазами. Проблема начинается, когда результат глазами не виден. Демонстрация всегда показывает удачный сценарий: подготовленные данные, спокойный канал связи, один пользователь, отсутствие сбоев. За кадром остаётся всё, из-за чего проекты потом рассыпаются.
- •Что происходит, когда приходят настоящие данные — грязные, неполные, в чужом формате,
- •Что видит человек, когда шаг не выполнился: понятную ошибку или пустой экран,
- •Что остаётся у вас, если подрядчик исчезнет: исходники, доступы, документация,
- •Кто и как восстанавливает работу после сбоя,
- •Выдержит ли решение нагрузку, отличную от одного показа.
Отдельная слабость этого пути — асимметрия. Показывает тот, кто делал; выбирает, что показать, тоже он. Это не злой умысел, а естественное поведение: человек демонстрирует то, что получилось. Спор о том, сделано ли, возникает уже на финальном платеже, и опереться в нём не на что — записанного результата нет.
Путь второй: приёмка по записанным критериям
До начала работ стороны записывают, что именно должно быть верно, когда работа закончена. Не «сделать интеграцию», а «заявка с сайта появляется в CRM с именем, телефоном и источником; если поле не заполнено, менеджер видит пометку». Проверка выполняется заказчиком: открыл, нажал, посмотрел, где появилось.
Главное свойство такого списка — он не требует эксперта. Инженерная сложность остаётся на стороне подрядчика, а на приёмку выносится только то, что вы наблюдаете в своей работе. Второе свойство: список дисциплинирует обе стороны ещё до старта. Пункты, которые никто не может сформулировать, обычно и есть недодуманная часть задачи — и лучше споткнуться о неё в переписке, чем на сдаче.
Сравнение двух путей
| Вопрос | Демонстрация | Проверка по критериям |
|---|---|---|
| Кто определяет, что показать | подрядчик | список, написанный заранее |
| Кто может провести приёмку | нужен технический человек рядом | заказчик самостоятельно |
| Когда фиксируется «готово» | на показе, словами | до старта, письменно |
| Что делать при споре | обсуждать заново | вернуться к пункту списка |
| Видны ли сбойные сценарии | обычно нет | да, если внесены в список |
| Затраты на входе | нет | время на формулировки до старта |
Кому подходит каждый путь
Честно: демонстрация — не зло. Она работает, когда предмет работы виден заказчику напрямую: правки на сайте, вёрстка страницы, тексты, оформление каталога, простая посадочная страница. Здесь вы сами себе эксперт: смотрите на результат и понимаете, устраивает он вас или нет. Городить формальный список критериев для такой работы — лишняя бюрократия.
Оговорка про существующий сайт: глазами видно то, что просили изменить, но не то, что стоит рядом. Правка в чужом коде принимается по своим признакам — история изменений, откат, соседние разделы, — и они разобраны отдельно: что входит в доработку сайта, а что нет. Здесь дальше — про работы, где посмотреть на результат нельзя в принципе, чем бы он ни был: обменом данными, оборудованием или ботом.
Критерии обязательны там, где результат невидим или отложен во времени: обмен данными между системами, работа с оборудованием и протоколами, серверная часть, боты, обработка документов. Такую работу нельзя оценить взглядом — её можно только проверить действием. Сюда же относятся решения на базе моделей: у сценарного бота критерий проверяется перебором веток диалога, у бота на нейросети — иначе, потому что ответ не фиксирован; разница разобрана в статье чат-бот с AI или по сценарию. То же и с AI-консультантом на сайте: «отвечает красиво» — это впечатление, а «не выдумывает того, чего нет на сайте» — уже проверяемый пункт.
Как выглядит критерий, который проверит не инженер
Рабочий критерий состоит из 3 частей: действие, наблюдаемый результат и способ проверки. Если одной части нет, пункт превращается в пожелание.
- •Плохо: «бот должен корректно обрабатывать заявки». Проверить нельзя — «корректно» у каждого своё.
- •Хорошо: «пишу боту заявку с адресом и телефоном — в течение рабочего дня она появляется в таблице заявок отдельной строкой, телефон в международном формате».
- •Плохо: «интеграция работает стабильно». Стабильность — не наблюдаемое событие.
- •Хорошо: «выключаю обмен на час, включаю обратно — накопленные заявки приходят, дублей нет».
- •Плохо: «сайт быстро открывается». Быстро — по чьим ощущениям и на каком телефоне.
- •Хорошо: «открываю каталог с мобильного интернета — вижу товары и работающий фильтр, без пустых мест на месте картинок».
Обратите внимание: ни один из «хороших» пунктов не требует технических знаний. Требуется только знание собственного процесса. Смета, кстати, ведёт себя так же — она становится понятной ровно тогда, когда записаны проверяемые пункты; с той же фиксации — какие сценарии закрываем и какие системы подключаем — начинается и оценка бота, об этом в разборе сколько стоит разработать Telegram-бота.
Что делать, если проект уже идёт по первому пути
Переписывать договор задним числом не нужно, и разрывать отношения тоже. Достаточно перевести приёмку в проверяемую форму начиная со следующего этапа.
- •Запишите, что должно быть верно к концу текущего этапа, — своими словами, без терминов.
- •Отправьте список подрядчику письмом и попросите отметить пункты, которые он считает вне объёма работ.
- •Спорные пункты обсудите до того, как этап будет сдан, а не после.
- •На следующем показе идите по списку, а не по сценарию подрядчика: открывайте пункты по очереди и проверяйте сами.
- •Отдельным пунктом внесите передачу — исходники, доступы, инструкция по запуску — и проверьте её так же, как остальные пункты: зайдите по своим доступам сами.
Плата за такой список — время на формулировки до старта, ваше и подрядчика, а не отдельная строка в смете. Взамен разговор становится предметным: вместо «нравится или нет» появляется «этот пункт закрыт, этот нет, вот что мешает». Бывает и обратный исход: критерии вскрывают объём, которого раньше никто не видел, — тогда цена меняется до старта, а не после сдачи. Мы готовы взяться за формулировку критериев вместе с вашей стороной — в том числе на проекте, который начал не мы. Характер работ и то, что остаётся у заказчика после сдачи, — на странице что мы делаем.
Частые вопросы
Что такое критерии приёмки проекта?
Это список проверок, по которым заказчик решает, сделана работа или нет. Каждый пункт описывает наблюдаемое действие и его результат, ответ на пункт — «да» или «нет». Список составляется до начала работ и не меняется задним числом.
Можно ли написать критерии, если я не разбираюсь в технике?
Да, потому что критерий пишется на языке вашей работы, а не на языке кода. Вы описываете, что должно происходить с заявкой, документом, заказом или оборудованием, а подрядчик переводит это в техническое решение. Если пункт нельзя описать без специальных терминов, попросите объяснить его словами вашей предметной области.
Кто должен писать критерии — заказчик или подрядчик?
Черновик обычно готовит подрядчик, потому что он видит границы решения. Но принимает и правит список заказчик: критерий, который заказчик не может проверить сам, для приёмки бесполезен. Нормальная практика — совместная вычитка перед стартом.
Что делать, если подрядчик отказывается фиксировать критерии?
Отказ фиксировать проверяемый результат — сам по себе сигнал. Обычно он означает, что объём задачи не продуман либо исполнитель не хочет отвечать за границу «готово». Разумный шаг — сузить первый этап до маленькой части работы и записать критерии хотя бы на неё.
Демонстрации вообще не нужны?
Нужны, но как способ синхронизации, а не как приёмка. На демонстрации удобно обсуждать удобство, формулировки и порядок экранов. Решение «принято» принимается отдельно и по списку, который написан заранее.