Передача системы в эксплуатацию — это опись из семи позиций, которую подписывают вместе с актом запуска: доступы и владение учётными записями, исходный код и права на него, схема развёртывания, описание интеграций, инструкции, реестр внешних зависимостей и журнал изменений. Не «передали доступы, всё хорошо», а поимённый перечень с проверкой каждого пункта.
Момент этот проходит незаметно, а последствия у него долгие. После него вы либо владеете системой, либо арендуете её у подрядчика, не зная об этом. Разница обнаруживается через год-полтора, когда нужно что-то доработать, а автор занят другим проектом, или когда выясняется, что домен и сервер оформлены не на вас.
Ниже — состав пакета передачи, объяснение, почему доступы важнее кода, способ проверить передачу за один день чужими руками, разница между гарантией и платной поддержкой и расчёт того, во что обходится непереданная система. Отдельно замечу: готовность к эксплуатации — это другой список, про администратора, мониторинг и резервные копии, и он разобран в статье жизнь системы после запуска. Здесь речь только о том, что переходит от подрядчика к заказчику.
Семь позиций описи
Каждая строка ниже — отдельный пункт с отдельной проверкой. Формулировка «как проверить» важнее формулировки «что передаётся»: передать можно что угодно, вопрос в том, работает ли переданное без автора.
| Позиция | В какой форме передаётся | Как проверить за 15 минут |
|---|---|---|
| Доступы и владение учётными записями | Владелец — ваше юрлицо, восстановление привязано к корпоративной почте, доступ подрядчика оформлен как приглашённый | Войти самому, сменить пароль, отозвать доступ подрядчика и вернуть обратно |
| Исходный код и права на него | Репозиторий в вашем аккаунте плюс пункт договора о передаче исключительных прав после оплаты | Скачать архив и собрать проект на чистой машине по инструкции |
| Схема развёртывания | Документ на 2–4 страницы плюс конфигурации и скрипты запуска | Найти в ней ответ на вопрос «как поднять систему заново с нуля» |
| Описание интеграций и обменов | Таблица: система, направление, что передаётся, частота, поведение при сбое, где журнал | Взять один обмен и найти по описанию его журнал за вчерашний день |
| Инструкции пользователя и администратора | 2–3 страницы на роль, написанные по задачам, а не по кнопкам интерфейса | Дать сотруднику, не участвовавшему в проекте, выполнить три типовые задачи |
| Реестр внешних зависимостей и ключей | Перечень сервисов, тарифов, ключей, дат истечения и того, на кого оформлен договор | Сверить с выпиской по счёту: все ли платежи объяснены строками реестра |
| Журнал изменений | Первая запись — состав системы на дату запуска, дальше каждая доработка с датой | Найти дату и содержание последней доработки без обращения к подрядчику |
Опись подписывается вместе с актом запуска, а не «в течение месяца после». После подписания акта интерес подрядчика к оформлению документов физически падает — люди переходят на другие проекты, и это нормально. Порядок приёмки самих работ разобран отдельно — приёмка работ по автоматизации; передача идёт следующим шагом и оформляется своим документом.
Отдельного внимания стоит пятая строка. Инструкция, написанная по кнопкам интерфейса, устаревает при первом же обновлении и не помогает новому сотруднику: он не знает, какую кнопку искать. Инструкция, написанная по задачам, живёт годами, потому что задачи меняются медленнее интерфейсов. Нормальный объём — 2–3 страницы на роль: что делаю каждый день, что делаю раз в месяц, что делаю, когда пошло не так и к кому иду. Двухсотстраничное руководство, дублирующее экраны, — признак того, что документацию писали для отчётности, а не для людей.
Схема: слева вертикальный список из семи блоков-позиций — «Доступы и владение учётками», «Исходники и права», «Схема развёртывания», «Описание интеграций», «Инструкции», «Реестр внешних ключей», «Журнал изменений». Справа три блока-ситуации, к которым от позиций идут стрелки: «Ключевой сотрудник уволился», «Подрядчик недоступен», «Меняем исполнителя». Под схемой подпись «Опись подписывается вместе с актом запуска». Чертёжный стиль, подписи по-русски.
Доступы важнее кода
Передача исходников звучит внушительно и обсуждается в договорах чаще всего. На практике же система, у которой код передан, а доступы нет, работает ровно так же, как система, которую не передавали вообще: вы не можете ни развернуть её, ни оплатить сервисы, ни восстановить после сбоя. Шесть вещей должны быть оформлены на ваше юрлицо, и это не предмет для торга.
- Домен и управление DNS. Регистратор — на вашу компанию, контакт для восстановления — корпоративная почта. Домен, оформленный на подрядчика, превращает любое расставание в переговоры.
- Сервер или хостинг и его оплата. Договор с провайдером и карта оплаты — ваши. Подрядчик получает доступ как администратор, а не как владелец счёта.
- Репозиторий с кодом. Организация в вашем аккаунте, подрядчик приглашён с правами разработчика. Обратная схема — самая частая и самая незаметная привязка.
- Аккаунты внешних сервисов. Провайдер языковой модели, распознавание, телефония, SMS, почтовый сервис — каждый со своим тарифом, ключом и датой истечения. Ключ, выписанный на аккаунт подрядчика, перестанет работать в день расставания.
- Резервные копии и место их хранения. Не просто «настроено», а известно, где лежат копии, кто их владелец и как из них восстановиться. Копии в личном облаке инженера копиями не являются.
- Учётные записи администратора в CRM и учётной системе. Как минимум одна административная учётка должна принадлежать вашему сотруднику, а не только подрядчику.
Первый: письма о продлении домена или тарифа приходят не на вашу почту. Второй: чтобы получить доступ к репозиторию или серверу, нужно попросить подрядчика. Третий: в счетах есть строки, которых нет в реестре внешних зависимостей. Любой из трёх означает, что часть системы вам не принадлежит, и обнаруживать это лучше сейчас, а не в момент, когда подрядчик недоступен. Как мы фиксируем эти обязательства до договора — на странице гарантий, общая схема доступов и их отзыва — в разделе про безопасность.
Сравнение в две колонки по шести строкам. Строки: «Домен и DNS», «Сервер и его оплата», «Репозиторий кода», «Аккаунты внешних сервисов», «Резервные копии», «Административная учётка в CRM». Левая колонка помечена «оформлено на подрядчика — привязка», правая «оформлено на заказчика, подрядчик приглашён — норма». В левой колонке у каждой строки значок замка, в правой — значок ключа с подписью «владелец». Внизу подпись: «Код без доступов развернуть невозможно». Чертёжный стиль, подписи по-русски.
Проверка передачи: развернуть по инструкции чужими руками
Все документы можно передать формально, и они будут выглядеть убедительно. Единственная честная проверка — попросить человека, который не участвовал в проекте, развернуть систему по переданной инструкции, не задавая вопросов авторам. Это четыре шага и один рабочий день.
- 1Шаг 1. Найти проверяющего вне проекта
Свой ИТ-специалист, если он есть, или внешний инженер на разовую работу. Главное условие — он не участвовал в разработке и не может спросить у авторов. Именно это и проверяется: работает ли документация без людей, которые её писали.
- 2Шаг 2. Развернуть систему в отдельном контуре
По схеме развёртывания, на чистом сервере, с тестовыми данными. Все места, где проверяющий застрял и полез спрашивать, — это дыры в документации, и их правит подрядчик, пока проект ещё открыт.
- 3Шаг 3. Пройти по описанию интеграций
Взять два обмена из таблицы, найти их журналы, отключить одну из сторон и убедиться, что поведение при сбое совпадает с описанным. Это же проверка того, что журналы вообще есть и в них можно разобрать инцидент.
- 4Шаг 4. Выполнить три типовые задачи по инструкции
Сотрудник, не участвовавший в проекте, делает три обычные операции только по написанному. Если ему нужен наставник — инструкция описывает интерфейс, а не работу, и её надо переписать по задачам.
Что делать, если проверка провалилась, — вопрос практический. Пока проект открыт и последний платёж не прошёл, всё решается просто: перечень мест, где проверяющий застрял, идёт подрядчику как замечания по этапу передачи, и правки входят в согласованную смету. Если акт уже подписан, разговор становится переговорным: формально обязательство закрыто, фактически документ не работает. Поэтому проверку планируют до последнего платежа, а не после — это единственная точка, где у сторон совпадают интересы.
К этой сумме добавляется то, что деньгами не считается: время, когда система работает, но её никто не понимает, и любая доработка откладывается «до выяснения». Обычно именно на этом этапе рождается решение «давайте перепишем заново», которое стоит уже полной сметы проекта.
Гарантия и поддержка — это разные вещи
После передачи начинаются два параллельных обязательства, которые постоянно путают. Гарантия — про соответствие тому, что заказывали. Поддержка — про то, что мир вокруг системы меняется. Первую оплачивает подрядчик, вторую — заказчик, и путаница между ними даёт самые тяжёлые споры на второй-третий месяц эксплуатации.
| Гарантия | Поддержка | |
|---|---|---|
| Что покрывает | Несоответствие системы ТЗ и приёмочным сценариям | Изменения внешних API, новые требования, консультации, мониторинг, развитие |
| Кто оплачивает | Подрядчик, за свой счёт | Заказчик по договору |
| Что не входит | Новые требования, ошибки в данных заказчика, изменения регламентов и чужих систем | Ничего из перечисленного слева — оно как раз входит |
| Как оформляется требование | Ссылка на пункт ТЗ или номер приёмочного сценария | Заявка с уровнем срочности по SLA |
| Срок действия | У нас — весь срок действия договора поддержки | От 6 месяцев, дальше продлевается или прекращается |
Практический вывод один: спор «это дефект или доработка» решается не голосом, а ссылкой на документ. Поэтому качество ТЗ и приёмочных сценариев определяет не только приёмку, но и всю последующую эксплуатацию — формулировки, которые нельзя проверить, через полгода превращаются в счёт. Что именно должно быть записано в договоре на этот счёт, разобрано в статье что должно быть в договоре на разработку.
Две горизонтальные ленты разной длины. Верхняя короткая, подписана «Пакет передачи есть»: «Знакомство с описью и репозиторием», «Развёртывание по инструкции», «Первая доработка» — общая длина «2–3 рабочих дня, 30 000–50 000 ₽». Нижняя длинная, подписана «Пакета нет»: «Поиск доступов и владельцев», «Разбор кода без документации — 40 ч», «Восстановление схемы интеграций — 16 ч», «Настройка копий и мониторинга — 12 ч» — общая длина «3–6 недель, 183 600 ₽». Справа скобка между концами лент с подписью «разница в 8,5 раза». Чертёжный стиль, подписи по-русски.
Когда полная передача не нужна
Есть случаи, когда требовать весь пакет из семи позиций бессмысленно, и настаивать на нём — значит платить за документы, которыми никто не воспользуется.
- Вы купили подписку, а не систему. Если решение работает на платформе вендора и вы платите ежемесячно, исходников не будет и быть не должно. Передавать здесь надо другое: доступы администратора, экспорт ваших данных в открытом формате и описание настроек, чтобы восстановить конфигурацию у другого партнёра.
- Настройка внутри готового продукта. Сценарии в CRM, правила в учётной системе, шаблоны документов. Здесь пакет сводится к описанию настроек и выгрузке конфигурации — схема развёртывания просто не существует.
- Маленькая обратимая доработка. Один обмен, уведомление, отчёт по расписанию. Полная опись на такую задачу дороже самой задачи; достаточно кода, доступов и одной страницы описания.
- Вы точно не будете менять подрядчика ближайшие годы. Это допустимая позиция, но её надо принимать осознанно и с открытыми глазами, а не по умолчанию. Минимум, который стоит закрыть даже в этом случае, — владение доменом, сервером, аккаунтами внешних сервисов и резервными копиями.
Пакет передачи нужен не для смены подрядчика. Он нужен для того, чтобы смена подрядчика была вашим решением, а не следствием обстоятельств.
