Проект закрыт, когда у вас на руках комплект из шестнадцати позиций и вы можете развернуть систему заново, сменить в ней пароль и позвать другого исполнителя — не спрашивая прежнего. Подписанный акт этого не доказывает: он закрывает обязательства по договору, а не зависимость от конкретной команды. Это две разные вещи, и вторая обычно обнаруживается через полгода.
Проверка на зависимость простая. Если, чтобы поменять текст письма клиенту или добавить поле в форму заявки, вы пишете прежнему подрядчику, потому что больше некому и негде посмотреть — вы не купили систему, вы арендовали команду. Аренда бывает осознанным выбором, но она стоит других денег и оформляется другим договором.
Ниже — форма из шестнадцати пунктов по шести группам с признаком закрытия к каждому, порядок проверки комплекта чужими руками, список действий по отзыву доступов и итоговая сверка с тем расчётом окупаемости, который вы делали до старта. Все суммы — модельные, для проекта внедрения на 1 200 000 ₽ с поддержкой 25 000 ₽/мес, по состоянию на сентябрь 2026 года.
Шестнадцать пунктов по шести группам
Пункт чек-листа состоит из двух частей: что передаётся и по какому признаку это считается принятым. Вторая часть важнее первой. Признак — это действие, которое выполняете вы или ваш человек: вошли под своей учётной записью, развернули по инструкции, восстановили из копии, нашли нужную заявку в журнале. Присланный архив, скриншот и фраза «всё передали» признаками не являются.
| Группа | Пункт | Признак, что пункт закрыт |
|---|---|---|
| Доступы | 1. Реестр учётных записей во всех системах проекта | Каждая запись оформлена на домен и юрлицо заказчика, вход выполнен без участия подрядчика |
| Доступы | 2. Две административные записи у разных сотрудников | Обе проверены входом и сменой пароля в разные дни |
| Доступы | 3. Внешние сервисы и платные подписки | В личном кабинете каждого сервиса плательщик — ваше юрлицо, карта не подрядчика |
| Код | 4. Репозиторий с историей изменений и ветками | Копия развёрнута на вашей стороне, последний коммит совпадает с продуктивной версией |
| Код | 5. Список переменных окружения и конфигураций | По документу собран рабочий стенд; сами секреты передаются отдельно и меняются после приёмки |
| Код | 6. Реестр сторонних компонентов и лицензий | У каждой позиции указан владелец, срок и что произойдёт при неоплате |
| Документация | 7. Инструкция развёртывания с нуля | Сторонний инженер поднял среду по ней, не задавая вопросов авторам |
| Документация | 8. Схема обменов: какие системы, что передают, где журналы | По схеме удалось найти, на каком шаге потерялась тестовая заявка |
| Документация | 9. Инструкции для сотрудников: памятка и сценарии частых задач | Новый сотрудник выполнил три сценария без подсказок |
| Данные | 10. Выгрузка данных в открытом формате | Файлы открываются без систем подрядчика, справочники читаемы |
| Данные | 11. Резервное копирование: расписание, место, срок хранения | Одно восстановление из копии выполнено при вас и до конца |
| Данные | 12. Персональные данные: где лежат, кто обрабатывал, что с копиями | Подписан акт об уничтожении копий у подрядчика либо зафиксирован срок хранения |
| Договор | 13. Право на результат работ и право на переработку | Формулировка есть в договоре, а не в переписке; названы компоненты, которые переданы по лицензии |
| Договор | 14. Комплект закрывающих документов по этапам и финальный акт | Перечень приложений в акте совпадает с фактически переданным по пунктам 1–13 |
| Поддержка | 15. Решение о сопровождении принято до расставания | Подписан договор поддержки либо назначен свой ответственный с именем и объёмом часов |
| Поддержка | 16. Итоговая сверка с расчётом окупаемости | Посчитана фактическая экономия и записана причина расхождения с расчётом до старта |
Шестнадцать — не догма, а рабочий минимум для проекта, где есть своя разработка, обмен между системами и персональные данные клиентов. На настройке готового сервиса без единой строки кода пункты 4–6 схлопываются в один, а на проекте с производственным контуром к списку добавляется регламент действий при отказе оборудования. Меняется состав, не меняется правило: у каждой позиции есть проверяемый признак, и его выполняете вы.
Схема из шести горизонтальных дорожек, подписанных «Доступы — 3 пункта», «Код — 3», «Документация — 3», «Данные — 3», «Договор — 2», «Поддержка — 2». В каждой дорожке — прямоугольники по числу пунктов с короткими подписями. Справа от каждой дорожки колонка «признак закрытия» с глаголом действия: «вошли», «развернули», «восстановили», «нашли», «подписали», «посчитали». Внизу подпись «16 пунктов, 62 400 ₽, около 24 человеко-часов». Чертёжный стиль, подписи по-русски.
Проверка комплекта: развернуть чужими руками
Комплект проверяется одним способом: человек, который в проекте не участвовал, поднимает систему по инструкции развёртывания и не задаёт вопросов авторам. Всё, что ему пришлось спросить, — это дыра в документации, и закрывать её надо сейчас, пока подрядчик рядом и заинтересован в подписании акта. Механику самой проверки мы подробно разбирали в материале о передаче системы в эксплуатацию; здесь важен момент, в который она делается — до финального акта, а не после.
- 1Развернуть систему на чистом стенде строго по инструкции. Любой вопрос автору — дефект документации, он записывается и устраняется.
- 2Восстановить данные из резервной копии и открыть три произвольные записи: заявку, документ, карточку клиента.
- 3Прогнать один сквозной сценарий целиком: заявка пришла, прошла обмен, попала в учётную систему, ушёл ответ клиенту.
- 4Найти этот же сценарий в журналах обменов по схеме из пункта 8 — если по схеме заявка не находится, схема неверна.
Сорок восемь тысяч из этих шестидесяти двух — оплата чужого времени, и именно на них экономят чаще всего. Логика понятная: проект сдан, деньги освоены, документация выглядит формальностью. Но 24 000 ₽ за контрольное развёртывание — это цена ответа на вопрос, работает ли комплект. Без ответа вы узнаете правду в момент, когда прежнего подрядчика уже нет, а система лежит.
Автор системы разворачивает её по памяти, а не по инструкции, и не замечает пропусков — он знает, что перед запуском надо выполнить ещё одну команду и положить один файл. Проверяющим должен быть человек со стороны: инженер другой команды, ваш системный администратор или подрядчик, которого вы рассматриваете на поддержку. Если позвать некого, порядок проверки хотя бы записывается, а развёртывание делается на видеозвонке с демонстрацией экрана — так фиксируется, где автор отступил от текста.
Отзыв доступов и смена секретов: один рабочий день
Доступы отзываются в тот же рабочий день, когда подписан финальный акт. Не через неделю и не «когда дойдут руки»: забытая учётная запись подрядчика живёт годами, а отвечать за то, что через неё сделали, будете вы. Порядок передачи и выдачи доступов на входе в проект мы разбирали в чек-листе безопасной передачи доступов — на выходе он читается в обратную сторону.
- 1Отключить именные учётные записи подрядчика во всех системах проекта. Не удалять — отключать: удаление ломает историю действий в журналах.
- 2Сменить пароли всех технических и служебных записей, которые подрядчик знал.
- 3Перевыпустить ключи и токены интеграций по одному, с проверкой обмена после каждого. Одновременная замена ломает обмены разом, и заканчивается это возвратом старых ключей навсегда.
- 4Отозвать доступы к репозиторию, хостингу, панели домена и почтовому сервису.
- 5Проверить, не осталось ли у подрядчика прав плательщика во внешних сервисах и права восстановления пароля через его почту.
- 6Забрать администрирование каналов уведомлений: боты, рассылки, номера телефонии.
- 7Зафиксировать в журнале дату и исполнителя по каждому пункту — это тот документ, который спросят при любом разборе инцидента.
Шесть из семи действий занимают минуты. Всё время съедает третье: ключей интеграций на среднем проекте от четырёх до десяти, и после каждой замены надо дождаться прохождения обмена. Отсюда 3 часа в расчёте выше, а не 20 минут.
Итоговая сверка: что обещали и что получилось
Шестнадцатый пункт — единственный, который не про передачу, а про деньги. До старта вы считали окупаемость: сколько часов уходит на процесс сейчас, сколько останется потом, за сколько месяцев вложение вернётся. Через два-три месяца эксплуатации у вас появляются факты, и их надо сравнить с тем расчётом. Методику мы разбирали в материале о том, как измерить эффект автоматизации; в закрытии проекта она нужна не для отчёта, а чтобы понять, что доделывать в первую очередь.
Смысл сверки не в том, чтобы предъявить подрядчику. Расхождение почти всегда состоит из вещей, которые не запустили внутри компании: сценарии, под которые не нашлось владельца, и проверка, которую не решились отключить. Обе строки в модели дают 52 000 ₽ в месяц — это больше двух месяцев поддержки, и заниматься ими стоит до того, как проект перестанут вспоминать.
Столбчатая диаграмма из двух столбцов на общей шкале месяцев. Левый столбец «по расчёту до старта — 9,8 месяца», подпись «экономия 148 000 ₽/мес». Правый столбец «факт на третий месяц — 16,9 месяца», подпись «экономия 96 000 ₽/мес», разбит выносками на две причины: «два сценария из семи не запущены — 31 000 ₽/мес» и «ручная проверка на 20 % документов — 21 000 ₽/мес». Под шкалой подпись «вложение 1 200 000 ₽, поддержка 25 000 ₽/мес». Чертёжный стиль, подписи по-русски.
Что дальше с поддержкой: три сценария
Решение о сопровождении принимается до расставания. Если оно не принято, по умолчанию срабатывает четвёртый сценарий — никакой: система работает, пока не сломается, а потом её чинит тот, кто первым согласится. Три рабочих варианта и то, что каждому из них нужно от комплекта закрытия:
| Сценарий | Что нужно иметь на руках | Во что обходится в модели | Когда выбирают |
|---|---|---|---|
| Свои силы | Все 16 пунктов, инструкции для сотрудников и свой человек с правами администратора | 8–12 часов в месяц времени ответственного, 14 400–21 600 ₽/мес по внутренней ставке | Правок мало, система стабильна, есть кому держать картину целиком |
| Тот же подрядчик | Договор поддержки с описанным составом работ и сроками реакции | 25 000 ₽/мес в модельном проекте плюс работы сверх абонемента | Система живая, планируются доработки, отношения рабочие |
| Другой подрядчик | Полный комплект плюс две недели параллельной работы двух команд | 128 200 ₽ на организованную передачу против 462 000 ₽ на подхват брошенной системы | Цена выросла, сроки поехали или прежняя команда потеряла интерес |
Третий сценарий — тот, ради которого чек-лист и заполняют. Разница между 128 200 ₽ и 462 000 ₽ состоит ровно из шестнадцати пунктов и присутствия человека, который систему строил: детали и порядок двухнедельной передачи разобраны в статье о смене подрядчика поддержки. Что входит в саму поддержку и из чего складывается её цена, мы считали отдельно.
Когда шестнадцати пунктов слишком много
Полный список — форма для проекта, который вы собираетесь эксплуатировать годами. Есть работы, где он превращается в бюрократию и съедает больше, чем защищает.
- Настройка облачного сервиса без своей разработки. Дорабатывать нечего, разворачивать нечего: остаются группы «доступы», «данные» и «поддержка» — семь пунктов вместо шестнадцати. Контрольное развёртывание заменяется входом под своей записью и выгрузкой данных.
- Доработка на 80 000–150 000 ₽ внутри уже принятой системы. Комплект по ней уже собран при первом закрытии; здесь достаточно дописать в него изменённые конфигурации и обновить схему обменов. Отдельная процедура закрытия стоила бы дороже самой работы.
- Пилот, который вы заранее готовы выбросить. У пилота другая цель — проверить гипотезу. Из списка остаются только пункты 10 и 12: забрать данные и убрать копии персональных данных у подрядчика. Всё остальное закрывается вместе со стендом.
- Работы, которые ведёт ваш штатный инженер. Передавать некому и незачем, но пункты 7, 8 и 11 всё равно нужны — уже не от подрядчика, а от собственного сотрудника, потому что он тоже когда-нибудь уйдёт в отпуск или из компании.
И честная оговорка про сам чек-лист. Он не гарантирует, что система хорошая: по всем шестнадцати пунктам можно закрыть плохо спроектированный проект, который вы полностью получили в собственность и который вам не нужен. Качество решения проверяется приёмкой этапов и сверкой с расчётом окупаемости, а закрытие отвечает на другой вопрос — сможете ли вы жить с этой системой без тех, кто её построил. Оба вопроса надо задать, и второй — обязательно до подписания финального акта.
Если результат проекта нельзя развернуть без автора, вы купили не систему, а его доступность.
