Приёмка работ по автоматизации — это процедура из шести шагов, занимающая около 10 рабочих дней: подрядчик уведомляет о готовности и передаёт комплект для проверки, заказчик за 5 рабочих дней прогоняет согласованные сценарии силами своих сотрудников, замечания собираются в протокол и делятся на три класса, блокирующие и существенные устраняются, проводится повторная проверка только по замечаниям, и лишь после этого подписывается акт. Подпись на акте — последний шаг из шести, а не единственный.
Самая частая ошибка выглядит безобидно: систему показали, она открылась, всё вроде работает, акт подписали. Через месяц выясняется, что при недоступности учётной системы заявки теряются, отчёт расходится с 1С на 4 %, а права доступа настроены так, что менеджер видит закупочные цены. Формально этап принят, и всё перечисленное превращается в платную доработку.
Ниже — порядок приёмки, который можно взять в свой проект целиком: шесть шагов с фиксированными сроками, правила классификации замечаний, чек-лист на 18 пунктов, расчёт того, во что приёмка обходится заказчику в рабочих часах, и формулировка мотивированного отказа, которая не разрушает отношения с подрядчиком. Модельный проект тот же, что и в разборе технического задания: оптовая компания на 70 человек, приём заявок из почты и Авито с созданием заказа в 1С:УТ и карточки в amoCRM, бюджет 1 200 000 ₽, 26 приёмочных сценариев.
Шесть шагов приёмки этапа
Порядок и сроки прописываются в договоре один раз и дальше работают на всех этапах. Ключевых чисел здесь три: срок на проверку, срок на устранение и срок, после которого этап считается принятым по умолчанию, если заказчик молчит. Последний пункт защищает подрядчика от бесконечно висящей приёмки и потому обычно есть в договоре — заказчику важно про него знать.
- 1Шаг 1. Уведомление о готовности и комплект для проверки
Подрядчик письменно сообщает, что этап готов, и передаёт комплект: адрес тестового контура, учётные записи под каждую роль, перечень сценариев с номерами из ТЗ, инструкцию на 1–2 страницы и набор тестовых данных. Уведомление без комплекта сроком на проверку не считается: часы начинают идти с момента, когда заказчик физически может проверять.
- 2Шаг 2. Проверка силами будущих пользователей, 5 рабочих дней
Сценарии прогоняют те, кто будет работать в системе, а не ИТ-специалист и тем более не разработчик. Каждый участник получает свой набор сценариев и форму замечания: номер сценария, шаги, ожидаемое, фактическое, снимок экрана. Замечание без этих полей в работу не принимается — иначе протокол превращается в чат с впечатлениями.
- 3Шаг 3. Протокол замечаний с классами
Все замечания собираются в один документ, каждому присваивается класс — блокирующее, существенное, косметическое — и рядом ставится отметка «дефект» или «новое требование». Спорные строки разбираются в получасовой сессии, а не в переписке: письменный спор о классе замечания живёт неделю, устный — десять минут.
- 4Шаг 4. Устранение, 3 рабочих дня на блокирующие
Подрядчик устраняет блокирующие и существенные замечания в срок, записанный в договоре. Косметические уходят в отдельный список с датой — они не задерживают акт и закрываются в ближайшем плановом окне. То, что признано новым требованием, оценивается отдельным запросом на изменение и в этап не добавляется.
- 5Шаг 5. Повторная проверка только по замечаниям
Проверяются исправленные сценарии и те, которых исправление могло коснуться, — обычно это 6–10 сценариев из 26, а не весь набор заново. Полный повторный прогон нужен только тогда, когда правки затронули общую часть системы, и это решение принимается совместно, а не по умолчанию.
- 6Шаг 6. Акт с приложением протокола
В акте перечисляются номера принятых сценариев, прикладывается протокол с закрытыми замечаниями и открытый список косметических с датами. Формулировка «работы выполнены в полном объёме» без приложений в спорной ситуации не значит ничего: она не позволяет установить, что именно принято.
Горизонтальная лента времени на 10 рабочих дней с шестью дорожками: уведомление и передача комплекта (день 0), проверка сценариев силами пользователей (дни 1–5), протокол замечаний с классами (день 5), устранение блокирующих и существенных (дни 6–8), повторная проверка по замечаниям (день 9), акт с приложением протокола (день 10). Под дорожками — результат каждого шага: комплект для проверки, отметки по 26 сценариям, протокол на 34 замечания, исправления, 6–10 перепроверенных сценариев, подписанный акт. Отдельной отметкой: «если заказчик молчит 5 дней, этап считается принятым — так написано в большинстве договоров». Подписи по-русски.
Это когда систему показывают на созвоне, она открывается, кнопки нажимаются, и акт подписывается в тот же день. Демонстрация всегда идёт по счастливому пути: разработчик показывает то, что работает, и на тех данных, на которых работает. Всё, что не показано, автоматически считается принятым, а дальше действует простая арифметика — исправление дефекта, найденного на приёмке, стоит подрядчику часов внутри этапа, тот же дефект в эксплуатации стоит заказчику 40 000–120 000 ₽ отдельной доработкой и месяца ожидания в очереди поддержки. Замена простая: показ длится 30 минут и не заменяет пяти дней прогона сценариев вашими людьми.
Сценарии приёмки: откуда берутся и кто их прогоняет
Сценарии не пишутся в день приёмки — они рождаются в техническом задании вместе с критериями и согласуются до начала разработки. На проект в 1–1,5 млн ₽ получается 20–40 сценариев. Меньше двадцати означает, что часть процесса будет обсуждаться устно; больше сорока — обычно признак того, что в список попали варианты, отличающиеся одной кнопкой.
Прогоняют сценарии будущие пользователи. Это принципиально: разработчик проверяет, что система делает то, что он запрограммировал, а менеджер отдела продаж проверяет, что она делает то, что нужно ему в среду в 11 утра при 40 письмах в очереди. Второе находит другие дефекты. Роль ИТ-контакта или руководителя — сверка прав доступа, отчётов и журналов, а не прогон пользовательских сценариев.
| Группа сценариев | Сколько | Кто прогоняет | Пример проверяемого критерия |
|---|---|---|---|
| Основной путь: заявка от письма до заказа | 6 | Два менеджера отдела продаж | Из 100 реальных писем заказ в 1С создан не менее чем в 88 % случаев, ошибки в номенклатуре до 2 % |
| Исключения: нечитаемая спецификация, неизвестный контрагент, дубль заявки | 7 | Менеджер и владелец процесса | Все три случая попадают в интерфейс исключений с исходным письмом и не создают заказ автоматически |
| Интеграции и сбои: недоступная 1С, повтор отправки, обрыв связи | 5 | ИТ-контакт вместе с инженером подрядчика | На 10 принудительных отключениях ни одного дубля заказа и ни одной потерянной заявки |
| Права и роли | 4 | Владелец процесса | Менеджер не видит закупочных цен ни в одном из четырёх интерфейсов, включая печатные формы |
| Отчётность | 3 | Руководитель отдела | Отчёт за месяц сходится с выгрузкой из 1С по количеству и сумме с расхождением не более 0,5 % |
| Производительность и журналы | 1 | ИТ-контакт | Время ответа интерфейса не более 3 секунд при 50 одновременных пользователях |
Эти 27 часов — не накладные расходы, а часть цены проекта, которую просто не выставляют счётом. Их стоит заранее согласовать с руководителями отделов: приёмка, на которую сотрудников «выделят, если будет время», не проводится никогда. По нашей практике достаточно назвать конкретные даты пяти дней проверки при подписании календарного плана — тогда неделя резервируется вместе с отпусками и сменами.
Схема из трёх зон слева направо. Слева блок «ТЗ, приложение 1: критерии приёмки» с подписью «числовой порог, выборка, определение ошибки». В центре веер из шести групп сценариев с количествами: основной путь — 6, исключения — 7, интеграции и сбои — 5, права и роли — 4, отчётность — 3, производительность — 1; общая подпись «26 сценариев с номерами». Справа четыре узла проверяющих: два менеджера, владелец процесса, ИТ-контакт, руководитель отдела — со стрелками от соответствующих групп. Внизу подпись «27 человеко-часов, около 29 700 ₽». Подписи по-русски.
Три класса замечаний и разные правила для каждого
Без классификации приёмка застревает: одна сторона считает опечатку в подписи кнопки поводом не подписывать акт, другая считает потерю заявки при сбое мелочью, которую поправят потом. Классы вводятся в договоре одним абзацем и снимают почти весь спор. В модельном проекте на первом прогоне 26 сценариев обычно набирается 25–40 замечаний, и распределение по классам устойчивое.
| Класс | Определение | Пример | Срок устранения | Влияние на акт |
|---|---|---|---|---|
| Блокирующее | Сценарий не выполняется или выполняется с потерей данных; работать по процессу нельзя | При недоступности 1С заявка исчезает без следа в журнале | 3 рабочих дня | Акт не подписывается до устранения и повторной проверки |
| Существенное | Сценарий выполняется, но не соответствует критерию из ТЗ либо требует обходного пути | Распознавание даёт 71 % вместо порога 88 %; менеджер дозаполняет позиции руками | 5 рабочих дней | Акт не подписывается, но этап не останавливается: работа над следующим идёт параллельно |
| Косметическое | Не влияет на результат сценария: тексты, подписи, порядок полей, оформление | В подписи кнопки опечатка, колонки в списке идут в неудобном порядке | Ближайшее плановое окно, обычно до 20 рабочих дней | Акт подписывается, замечания уходят в открытый список с датами |
Столбчатая диаграмма из трёх столбцов по количеству замечаний первого прогона: блокирующие — 4, существенные — 11, косметические — 19, всего 34. Каждый столбец разделён штриховкой на две части: «дефект по ТЗ» и «новое требование» (в блокирующих — 4 и 0, в существенных — 8 и 3, в косметических — 12 и 7). Справа подписи сроков: 3 рабочих дня, 5 рабочих дней, до 20 рабочих дней. Внизу пометка: «10 замечаний из 34 оказались новыми требованиями и ушли в запрос на изменение». Ось — количество, подписи по-русски.
Дефект или новое требование: тест из трёх вопросов
Это самый частый конфликт на приёмке, и он почти всегда добросовестный: заказчик увидел работающую систему и понял, чего ему на самом деле хочется. Проблема в том, что «хочется» и «должно было быть» оплачиваются по-разному. Разделяются они тремя вопросами, которые задаются в этом порядке.
- 1Есть ли это в ТЗ или в сценарии приёмки? Если требование записано и не выполняется — это дефект, устраняется бесплатно. Если его в документе нет, дальше вопрос только один: сколько это стоит.
- 2Требование не записано, но следует из записанного однозначно? Пример: в ТЗ сказано «заказ создаётся в 1С:УТ», а система создаёт заказ без указания склада, хотя без склада документ не проводится. Это дефект: записанное требование физически не выполняется. А вот «пусть заодно подставляет договор поставки» из записанного не следует — это новое требование.
- 3Это ошибка в самом ТЗ, обнаруженная на приёмке? Такое бывает, и здесь нет правых: требование описано, реализовано по описанию, а в жизни работает плохо. Нормальная практика — разделить стоимость доработки пополам либо перенести её в ближайший этап без наценки. Спорить о вине в этой ситуации дороже, чем починить.
Схема-дерево решений сверху вниз. Вход: «Замечание с приёмки». Первый ромб: «Есть ли требование в ТЗ или в сценарии приёмки?» — ветка «да» ведёт в блок «Дефект: устраняется бесплатно в срок по классу». Ветка «нет» идёт ко второму ромбу: «Следует ли оно из записанного однозначно?» — «да» тоже ведёт в блок дефекта. «Нет» идёт к третьему ромбу: «Это ошибка самого ТЗ?» — ветка «да» ведёт в блок «Делим стоимость доработки или переносим в ближайший этап без наценки», ветка «нет» — в блок «Новое требование: запрос на изменение с оценкой в часах и рублях». Внизу подпись: «в модельном протоколе из 34 замечаний новыми требованиями оказались 10». Подписи по-русски.
Худшее, что можно сделать с новым требованием на приёмке, — отказать без записи. Через месяц оно вернётся в виде претензии «мы же говорили». Правильно — завести отдельный раздел протокола «новые требования», где по каждому пункту стоит оценка в часах и деньгах и решение: берём в следующий этап, откладываем, отказываемся. В модельном проекте таких пунктов из 34 замечаний оказалось 10, и семь из них потом вошли во второй этап отдельным запросом на изменение.
Чек-лист приёмки: 18 пунктов, которые можно взять в свой проект
Список проходится в день подписания акта и занимает около часа. Пункты 1–6 проверяются до начала прогона, 7–13 — по его результатам, 14–18 — перед подписью. Провал по любому из пунктов 3, 9, 11 и 16 мы считаем блокирующим независимо от общего счёта.
- 1Уведомление о готовности получено письменно, и в нём указана дата начала срока проверки.
- 2Передан комплект: адрес стенда, учётные записи под каждую роль, инструкция, тестовые данные.
- 3Перечень сценариев совпадает с приложением к ТЗ по номерам, ни один сценарий не исчез по дороге.
- 4Проверяющие назначены поимённо, и их время согласовано с руководителями отделов.
- 5Выборку для проверки формирует заказчик, а не подрядчик: свои 100 писем, свои документы, свои данные.
- 6Форма замечания роздана: номер сценария, шаги, ожидаемое, фактическое, снимок экрана.
- 7Все 26 сценариев прогнаны, а не выборочно «те, что успели»; непройденные отмечены отдельно.
- 8Проверены сценарии сбоев: недоступность смежной системы, повтор отправки, обрыв связи.
- 9Проверены права доступа под каждой ролью, включая печатные формы и выгрузки.
- 10Отчёты сверены с источником: расхождение по количеству и сумме в пределах согласованного порога.
- 11Каждому замечанию присвоен класс, и спорные классы разобраны устно, а не в переписке.
- 12По каждому замечанию отмечено, дефект это или новое требование, с оценкой по новым требованиям.
- 13Протокол подписан обеими сторонами с датой — до начала устранения, а не после.
- 14Повторная проверка проведена по исправленным сценариям и по тем, которых правки могли коснуться.
- 15Открытый список косметических замечаний имеет даты закрытия, а не формулировку «позже».
- 16В акте перечислены номера принятых сценариев, а не строка «работы выполнены в полном объёме».
- 17Заказчик получил на руки то, что положено на этом этапе: доступы, конфигурации, инструкции, журналы.
- 18Зафиксировано, с какой даты начинается гарантийный период и что в него входит.
Мотивированный отказ: как написать, чтобы он работал
Мотивированный отказ — обычное рабочее действие, а не начало конфликта. Он нужен ровно для одного: остановить срок, после которого этап считается принятым по умолчанию. В большинстве договоров этот срок 5 рабочих дней, и если заказчик за него не ответил или ответил невнятно, работы считаются принятыми со всеми последствиями.
Работающий отказ содержит четыре элемента: ссылку на этап и договор, перечень непройденных сценариев по номерам, ссылку на протокол с датой и предлагаемый срок устранения с датой повторной проверки. Оценок работы подрядчика, эмоций и общих формулировок в нём быть не должно — не потому, что это невежливо, а потому, что по ним нельзя установить, что именно требуется исправить.
| Так отказ не работает | Так работает |
|---|---|
| «Система нас не устраивает, работать в ней невозможно» | «Этап 3 не принимается: сценарии 7, 12 и 19 приложения 1 не выполняются» |
| «Много ошибок, доработайте и покажите ещё раз» | «Протокол от 12.09.2026: 4 блокирующих и 11 существенных замечаний, перечень приложен» |
| «Ждём исправлений в разумные сроки» | «Срок устранения блокирующих — до 17.09.2026, повторная проверка 18–19.09.2026» |
| «Оплату приостанавливаем до полного решения вопроса» | «Оплата этапа производится по пункту 4.3 договора после подписания акта по результатам повторной проверки» |
Отдельно стоит помнить, что отказ работает в обе стороны. Если из четырёх блокирующих замечаний два вызваны тем, что заказчик не предоставил тестовый контур с копией боевой базы, честнее это признать в том же протоколе: подрядчик не может проверить обмен на данных, которых у него нет. Протокол, где отмечены обе стороны просрочки, разбирается за час, а протокол, где виноват только исполнитель, разбирается неделю.
Гарантийный период: что входит и что за него не считается
Гарантия — это обязательство бесплатно чинить несоответствие системы тому, что записано в ТЗ и сценариях приёмки. Она не покрывает изменение внешнего мира и не покрывает изменение ваших желаний. Мы считаем гарантийным весь срок действия договора поддержки, но конкретика важнее названия: смотреть надо не на слово «гарантия», а на список, приложенный к договору.
| Что покрывает гарантия | Что гарантией не считается |
|---|---|
| Сценарий из ТЗ перестал выполняться или выполняется с ошибкой | Требование, которого в ТЗ нет: новое поле, новый отчёт, новая роль |
| Дефект, проявившийся под нагрузкой в пределах заявленных объёмов | Нагрузка выше заявленной в нефункциональных требованиях |
| Ошибка обмена при неизменных интерфейсах смежных систем | Смена API маркетплейса, банка или мессенджера — это работа по договору поддержки, а не дефект |
| Расхождение отчётов сверх порога, зафиксированного в критериях | Расхождение из-за ошибок в исходных данных, внесённых пользователями |
| Некорректная работа прав доступа по описанной ролевой модели | Появление новой роли или изменение оргструктуры компании |
| Дефект, обнаруженный после приёмки, но существовавший на момент подписания акта | Обучение новых сотрудников, принятых через полгода после запуска |
Практический вывод для договора: гарантийный период имеет смысл привязывать не к календарной дате, а к сроку действия договора поддержки — иначе через 90 дней вы остаётесь один на один с системой, которую никто не мониторит. Подробнее о том, что входит в поддержку, во что она обходится и почему без неё решение начинает деградировать через 3–4 месяца, мы писали отдельно.
Чего приёмка не гарантирует
Приёмка проверяет соответствие системы заданию — и только его. Она не отвечает на вопрос, было ли задание правильным. Система может пройти все 26 сценариев и при этом не дать заявленной экономии, потому что процесс изменился, объёмы оказались вдвое ниже расчётных или люди продолжили работать по-старому. Это отдельный слой контроля: метрики «до» и «после» на тех же правилах, замер через 4–8 недель эксплуатации, а не в день подписания акта.
- Приёмка не заменяет пилота. Прогон 26 сценариев на тестовом контуре и две недели боевой работы на части потока находят разные вещи: первое ловит несоответствие заданию, второе — несоответствие реальности.
- Приёмка не проверяет экономику. Соответствие ТЗ и окупаемость — независимые вещи; вторую меряют по метрикам процесса через месяц-полтора после запуска.
- Приёмка не отменяет обучение. Система, принятая по всем сценариям, но с сотрудниками, которые о ней не знают, даёт ровно нулевой эффект при полной оплате.
- Приёмка не гарантирует, что система переживёт смену подрядчика. Для этого нужен отдельный перечень передаваемого: доступы, исходники, схема развёртывания, описание обменов.
И последнее, самое скучное соображение. Вся описанная процедура держится не на юридических формулировках, а на одном условии: у заказчика есть пять рабочих дней людей, которые действительно прогонят сценарии. Там, где эти дни выделены и записаны в календарный план заранее, приёмка занимает 10 рабочих дней и заканчивается подписанным актом. Там, где их «постараются найти», всё сводится к получасовой демонстрации и подписи — и дальше начинается уже не приёмка, а платная доработка в эксплуатации.
Принято не то, что показали, а то, что вы проверили и записали номером сценария.
