Чек-лист приёмки этапа — это таблица, в которой у каждой строки есть три колонки: что предъявлено, чем это проверено и каким документом закрыто. Одной колонки мало. Список «что должно быть сделано» без способа проверки превращается в обмен мнениями, а проверка без закрывающего документа через полгода не доказывается никому, включая вас самих, когда состав команды сменится.
Мы уже разбирали приёмку как процедуру: последовательность шагов, сценарии, классы замечаний, гарантийный период. Здесь другое — сам документ и его привязка к этапам: что именно предъявляется на обследовании, что на сборке контура, что на передаче, и чем каждый из этих результатов физически проверяется руками заказчика. Плюс два денежных вопроса, которые обычно остаются за скобками: во что обходится формально принятый этап и почему платежи должны стоять ровно в точках приёмки.
Сквозной пример — проект на 980 000 ₽ и 14 недель: обработка входящих документов и автозаполнение учётной системы в компании, где через бухгалтерию проходит 2 400 документов в месяц и примерно 18 % из них нестандартные. Пять этапов, пять точек приёмки, пять платежей.
Из чего состоит один пункт: три колонки
Формат строки одинаков на всех этапах. Слева — результат в терминах заказчика, а не подрядчика: не «реализован модуль разбора», а «счёт из почты появляется в учётной системе заполненным». В середине — конкретное действие, которым это проверяется, с указанием, кто его выполняет. Справа — документ, который остаётся у вас после приёмки.
| Что предъявлено | Чем проверено | Чем закрыто |
|---|---|---|
| Счёт из почты попадает в учётную систему с заполненными шапкой и строками | Бухгалтер обрабатывает 20 своих счетов за текущий месяц без подсказок подрядчика | Протокол испытаний с номерами сценариев и списком расхождений |
| Нестандартные документы уходят на ручную обработку, а не заполняются наугад | Прогон 10 документов из тех самых 18 % исключений, отобранных заказчиком | Тот же протокол, отдельный раздел «исключения» |
| Обмен с учётной системой не создаёт дублей при повторной отправке | Повторная отправка одного пакета дважды и сверка количества записей | Выгрузка до и после с совпадающими числами, приложение к акту |
| Права доступа разграничены по ролям | Вход под учётной записью бухгалтера и попытка открыть чужой раздел | Матрица ролей, подписанная ИТ-контактом заказчика |
| Инструкция позволяет новому сотруднику начать работу | Сотрудник, не участвовавший в проекте, выполняет операцию только по инструкции | Инструкция в вашем формате, переданная файлом, а не ссылкой |
Схема одной строки чек-листа, разложенной на три блока слева направо. Блок 1 «Что предъявлено» с примером «счёт из почты попадает в учётную систему заполненным». Блок 2 «Чем проверено» с примером «бухгалтер обрабатывает 20 своих счетов без подсказок» и пометкой «действие выполняет заказчик». Блок 3 «Чем закрыто» с примером «протокол испытаний с номерами сценариев». Под блоками две перечёркнутые вариации: «только колонка 1 — спор о вкусах» и «колонки 1 и 2 без 3 — через полгода не доказать». Чертёжный стиль, подписи по-русски.
Обратите внимание на среднюю колонку: во всех пяти строках действие выполняет заказчик, а не подрядчик. Это принципиально. Демонстрация, которую ведёт разработчик на подготовленном примере, проверяет, что он умеет пользоваться своей системой, — а вам нужно знать, что ею смогут пользоваться ваши люди на ваших данных.
Пять этапов: что предъявляется и чем это щупается
Состав результата у каждого этапа свой, и путать их нельзя. Самая частая ошибка — требовать работающую систему на этапе обследования или, наоборот, принимать сборку контура по презентации. Ниже — типовая раскладка проекта на 14 недель.
| Этап | Что предъявляется | Чем проверяется заказчиком | Закрывающие документы |
|---|---|---|---|
| 1. Обследование, 2 недели | Отчёт: карта процесса как есть, замеры объёмов, перечень исключений, список систем и ограничений | Сверка карты с реальностью силами исполнителей процесса: три человека читают и отмечают расхождения | Отчёт обследования, акт по этапу |
| 2. Требования, 2 недели | Техническое задание с границами объёма и критериями приёмки, сценарии приёмки списком | Проверка на проверяемость: по каждому критерию заказчик формулирует, как он будет измерен | Утверждённое ТЗ, перечень сценариев приёмки |
| 3. Сборка контура, 5 недель | Работающий тестовый контур на копии ваших данных, доступы под каждую роль | Прогон сценариев сотрудниками на своих документах, без участия подрядчика | Протокол испытаний, реестр замечаний с классами |
| 4. Опытная эксплуатация, 3 недели | Работа в боевом режиме параллельно со старым порядком, журналы и метрики | Сверка результатов за период: доля обработанных без вмешательства, число ошибок, время на документ | Отчёт по метрикам ОЭ, протокол устранения замечаний |
| 5. Передача, 2 недели | Инструкции, обучение, доступы и учётные записи на ваше имя, исходники и документация | Новый сотрудник выполняет операцию по инструкции; ИТ входит во все системы под своими учётными записями | Акт передачи доступов, комплект документации, финальный акт |
Пятый этап заслуживает отдельного внимания, потому что его чаще всего сдают формально. «Доступы переданы» означает не письмо со списком логинов, а факт: ваш ИТ-специалист вошёл в каждую систему под учётной записью, оформленной на компанию, и убедился, что подрядчика можно отключить, а работа продолжится. Если на этом этапе выясняется, что сервер оформлен на личный аккаунт исполнителя, — это не мелочь и не повод торопиться с актом.
Четыре способа проверки и когда каждый честен
Способов проверки ровно четыре, и они не взаимозаменяемы. Подмена одного другим — самый распространённый механизм, которым этап проходит приёмку и при этом остаётся непроверенным.
- 1Способ 1. Прогон сценария вашим сотрудником
Человек, который будет работать в системе, выполняет операцию от начала до конца сам, без подсказок и без подрядчика за плечом. Единственный способ проверить, что интерфейс и логика соответствуют реальному порядку работы. Честен для всего, что делают люди: ввод, поиск, исправление, передача дальше по цепочке.
- 2Способ 2. Сверка чисел на выгрузке
Берётся период, выгружаются данные до и после, числа сравниваются: количество записей, суммы, контрольные значения по нескольким контрагентам. Единственный честный способ проверить обмен и перенос данных — глазами дубли и потери не видны. Работает и там, где результат нельзя «посмотреть»: фоновые обмены, интеграции, ночные операции.
- 3Способ 3. Проверка на исключениях, отобранных вами
Заказчик сам выбирает 10–15 нестандартных случаев и передаёт их на прогон. Ключевое слово — «сам»: набор, подготовленный подрядчиком, проверяет только то, что он уже учёл. В нашем примере это те самые 18 % документов, на которых ломается любая типовая обработка, и именно они определяют, будет ли система полезной в реальности.
- 4Способ 4. Факт наличия на вашей стороне
Применим к документам, доступам, исходникам и учётным записям. Проверяется не показом на экране подрядчика, а тем, что предмет физически у вас: файл скачан, вход выполнен, репозиторий открывается вашим специалистом. Формулировка в чек-листе должна быть именно такой — «получено и открыто заказчиком», а не «передано».
Показ на подготовленных данных с комментариями разработчика проверяет ровно одно: что при этом сочетании условий система не падает. Все известные нам случаи, когда дефект всплывал в первую неделю эксплуатации, объединяет одна деталь — этап был принят по демонстрации. Демонстрация полезна как знакомство с результатом, но в колонке «чем проверено» её быть не должно.
Сравнение в четыре колонки: «Прогон сценария сотрудником — доказывает соответствие реальному порядку работы», «Сверка чисел на выгрузке — доказывает отсутствие дублей и потерь», «Исключения, отобранные заказчиком — доказывает работу на трудных 18 %», «Факт наличия у вас — доказывает, что доступы и документы действительно переданы». Под каждой колонкой отметка, кто выполняет действие: заказчик, заказчик, заказчик, заказчик. Отдельным перечёркнутым блоком сбоку: «Демонстрация подрядчика — доказывает только, что система не падает на его примере». Чертёжный стиль, подписи по-русски.
Комплект закрывающих документов по этапу
Акт сам по себе почти ничего не фиксирует: в нём написано, что работы выполнены, но не написано, какие именно и как это установлено. Поэтому к акту по каждому этапу прикладывается комплект — четыре документа, из которых первые два обязательны всегда.
- 1Перечень состава результата по этапу — то, что было предъявлено, списком, с отсылкой к пункту ТЗ или к строке календарного плана. Это приложение к акту, а не его текст.
- 2Протокол приёмочных испытаний: номера сценариев, кто прогонял, дата, результат по каждому. Если сценариев не было, приёмка не состоялась — как бы её ни назвали в переписке.
- 3Реестр замечаний с классами и сроками устранения. Даже если замечаний нет, реестр прикладывается пустым с отметкой «замечаний не выявлено» — это фиксирует, что проверка была.
- 4Акт передачи доступов и материалов — на тех этапах, где что-то передаётся: учётные записи, файлы, исходники, документация. Формулировка «получено заказчиком, проверено», с фамилией принявшего.
Отдельно про дату. В акте по этапу полезно явно указывать, с какого числа начинается гарантийный период на результат этого этапа, — иначе через несколько месяцев начинается спор о том, покрывается ли найденный дефект гарантией или относится к платной доработке. Что входит в гарантию, а что нет, мы разбирали в статье о приёмке работ; здесь достаточно того, что дату надо поставить.
Мотивированный отказ и кто его подписывает
Отказ принять этап — не конфликт, а штатная процедура, и в большинстве договоров у неё есть срок: если заказчик за 5 рабочих дней не подписал акт и не направил мотивированный отказ, работы считаются принятыми. То есть молчание работает против вас. Отказ держится на трёх элементах, и отсутствие любого из них превращает его в претензию без последствий.
- Ссылка на конкретный пункт требований: номер пункта ТЗ или номер сценария приёмки. Без ссылки замечание становится новым требованием, и подрядчик формально прав, отказываясь его исполнять бесплатно.
- Описание расхождения фактами: что сделали, что ожидали по пункту, что получили. «Работает неудобно» — не расхождение. «По сценарию 12 после сохранения документ должен попадать в очередь на проверку; при прогоне 14 марта из 20 документов в очередь попало 6» — расхождение.
- Предлагаемый срок устранения и дата повторной проверки. Без срока отказ превращается в паузу без даты, а проект — в переписку. Срок предлагает заказчик, подрядчик может его оспорить, но точка отсчёта появляется сразу.
Теперь про подписанта. Приёмку со стороны заказчика должен подписывать тот, кто будет пользоваться результатом каждый день, — руководитель процесса или старший исполнитель, а не директор и не ИТ-специалист «за компанию». Причина простая: подпись человека, который не прогонял сценарии, юридически закрывает этап и одновременно гарантирует, что дефекты всплывут в эксплуатации. Директор при этом может подписывать акт как уполномоченное лицо, но протокол испытаний подписывает тот, кто испытывал.
Если по этапу подписывают трое, ответственность размывается на всех и не остаётся ни на ком. Рабочая схема: один подписант на протокол испытаний — владелец процесса; один на матрицу ролей и передачу доступов — ИТ-контакт; акт подписывает уполномоченное лицо на основании первых двух. Три подписи, три зоны ответственности, ни одной общей.
Цена формально принятого этапа
Принять этап формально — значит перенести дефект на следующий. Это не абстрактный риск: стоимость исправления растёт примерно втрое на каждом переходе, и растёт она по понятной причине. На своём этапе правится одна вещь; на следующем к ней добавляется то, что успели построить сверху; после запуска добавляются накопленные данные, переобучение людей и остановка процесса.
Против этих 155 700 ₽ стоит сравнить трудозатраты на нормальную приёмку: несколько часов работы ваших сотрудников на каждом этапе. Даже если приёмка съест два полных рабочих дня на весь проект, арифметика не оставляет вариантов. И заметьте: правило втрое работает и в обратную сторону — чем раньше этап, тем дешевле в нём ошибиться, поэтому самая окупаемая приёмка в проекте — приёмка отчёта обследования, где ошибка стоит часа обсуждения.
Столбчатая диаграмма из четырёх столбцов, растущих слева направо, ось — рубли. Столбцы: «Свой этап — 3 750 ₽ (1,5 ч)», «Следующий этап — 12 500 ₽ (5 ч)», «Через два этапа — 37 500 ₽ (15 ч)», «После запуска — 112 500 ₽ (45 ч)». У последнего столбца сверху надстроен более светлый сегмент «простой процесса — 43 200 ₽», общая подпись «155 700 ₽». Между столбцами подписи множителей «×3». Внизу подпись: «одно и то же требование, разное время обнаружения».
Точки приёмки и точки оплаты должны совпадать
Последний элемент чек-листа не относится к технике вовсе, но без него всё остальное держится на доверии. Если платёж стоит по календарю, а приёмка — по результату, они рано или поздно расходятся, и возникает этап, за который уже заплачено, но ничего не предъявлено. Дальше разговор о качестве ведётся с позиции, в которой у вас не осталось рычагов.
| Этап | Доля | Сумма при бюджете 980 000 ₽ | Основание платежа |
|---|---|---|---|
| 1. Обследование | 15 % | 147 000 ₽ | Акт по этапу и принятый отчёт обследования |
| 2. Требования | 15 % | 147 000 ₽ | Утверждённое ТЗ с перечнем сценариев приёмки |
| 3. Сборка контура | 30 % | 294 000 ₽ | Протокол испытаний без замечаний блокирующего класса |
| 4. Опытная эксплуатация | 25 % | 245 000 ₽ | Отчёт по метрикам и протокол устранения замечаний |
| 5. Передача | 15 % | 147 000 ₽ | Акт передачи доступов и финальный акт |
Аванс на первый этап — нормальная практика, вопрос в размере: 15 % за обследование, которое само по себе имеет ценность и остаётся у вас даже при расставании, — это честно. Аванс в 50 % за проект целиком до первой приёмки означает, что риск полностью на вашей стороне. Из чего вообще складываются бюджеты проектов такого масштаба, мы разбираем на отдельной странице — с ней полезно сверить и структуру платежей, и состав работ в предложении подрядчика.
Когда чек-лист избыточен
Развёрнутая приёмка по этапам оправданна не на любом проекте. На работе до 150 000 ₽ и в один этап — например, настройка одного обмена или доработка отчёта — процедура из протоколов и реестров стоит дороже самой работы. Там достаточно двух вещей: сценария «что должно получиться» в одну строку и проверки этого сценария вашим сотрудником до оплаты. Всё остальное будет бюрократией, которая замедлит и вас, и исполнителя.
Не нужен полный чек-лист и на этапе, у которого нет самостоятельного результата, — например, если подрядчик разбил сборку на две технические итерации ради собственного удобства. Принимать имеет смысл то, что можно потрогать и что имеет ценность само по себе. Если результат этапа невозможно описать в терминах заказчика, вопрос не к чек-листу, а к разбивке проекта: скорее всего, этапов слишком много и они нарезаны по внутренней логике исполнителя.
И один случай, в котором чек-лист не спасёт вообще. Если требования не были записаны на втором этапе, приёмке не на что ссылаться: любое замечание становится новым требованием, и подрядчик формально прав. Поэтому самый ценный пункт всего чек-листа находится не в нём, а раньше — в согласованном перечне сценариев приёмки, который составляется до начала разработки, а не после её окончания.
Этап принят не тогда, когда подписан акт, а тогда, когда ваш сотрудник прошёл сценарий сам.
