Передача ИТ-проекта в поддержку: что передать и как проверить

Передача ИТ-проекта в поддержку - это управляемый handover, после которого новая команда может собрать, запустить, проверить, сопровождать и развивать систему без постоянного участия исходных разработчиков. Передать нужно не только код, но и версию поставки, доступы, инструкции сборки и запуска, changelog, эксплуатационную документацию, контакты владельцев, известные ограничения и список открытых вопросов.

Хорошая передача проекта закрывает три слоя одновременно: юридический состав результата, техническую готовность к сопровождению и передачу знаний. Если один слой пропущен, проект формально может быть сдан, но поддержка будет зависеть от личных аккаунтов, устных пояснений, старых чатов и бывших участников команды.

Передача становится управляемой, когда понятно, кто принимает каждый слой результата. Один общий созвон не заменяет приемку доступа, кода, эксплуатационных инструкций и знаний.

Юридическая передача фиксирует права и состав результата, но сама по себе не доказывает, что систему можно сопровождать. Техническая готовность показывает, что переданные материалы действительно работают и понятны новой команде.

Knowledge transfer нужен, когда передать нужно не только артефакты, но и рабочий контекст. Хорошая сессия передачи объясняет архитектурные решения, критичные ограничения, нестандартные места, частые инциденты, процесс релизов и зоны, где документация еще неполная. Но такая встреча не заменяет документы: после нее должны остаться записи, ссылки, владельцы и список открытых вопросов.

1. Сначала пройти карту системы: компоненты, данные, интеграции, внешние зависимости.
2. Показать сборку и запуск на чистом окружении.
3. Разобрать типовой релиз: версия, миграции, smoke-проверка, rollback.
4. Показать мониторинг, логи, алерты и порядок реакции на инцидент.
5. Зафиксировать вопросы, которые нужно закрыть после передачи.

При переходе от внешнего подрядчика к внутренней команде особенно важно отделить владение результатом от привычки обращаться к старой команде. Внутренняя команда должна получить не только код, но и правила релизов, причины ключевых технических решений, доступ к контурам, список рисков, известный технический долг и порядок работы с инцидентами.

Если подрядчик остается на гарантийной поддержке, это тоже нужно зафиксировать: какие вопросы входят в гарантию, какие считаются новым объемом, какие сроки реакции действуют и кто принимает решение о доработке.

Передача исходного кода заказчику должна быть проверяемой. Недостаточно получить архив и считать задачу закрытой: нужно понимать, соответствует ли код переданной версии, есть ли инструкции сборки, какие библиотеки и лицензии используются, где хранятся конфигурации и можно ли развернуть систему без доступа к личному компьютеру разработчика.

• сверить commit или tag с версией, которая передается по акту;
• проверить, что репозиторий содержит инструкции, миграции и конфигурационные шаблоны;
• отдельно зафиксировать сторонние компоненты, лицензии и ограничения использования;
• подтвердить, что сборка проходит в целевом окружении, а не только на машине автора.

Самая полезная проверка передачи - попросить человека, который не писал проект, поднять стенд по инструкции. Если он сразу упирается в неизвестную переменную окружения, отсутствующий секрет, локальную зависимость или неописанную миграцию, handover еще не завершен. Проверку лучше делать до финального созвона, чтобы исправить инструкцию, а не объяснять все голосом.

• зафиксируйте целевую версию runtime, базы данных, брокера, внешних сервисов и системных пакетов;
• проверьте, что секреты и сертификаты выдаются через управляемый процесс;
• опишите порядок миграций и seed-данных, если без них приложение не стартует;
• добавьте smoke-сценарий: какие страницы, API или фоновые задачи должны подтвердить успешный запуск.

1. Зафиксировать состав поставки и версию, которая передается.
2. Проверить, что репозитории и артефакты доступны целевым ролям.
3. Пройти инструкцию сборки и запуска не автором проекта.
4. Сверить changelog, миграции, rollback и известные ограничения.
5. Передать эксплуатационные инструкции, мониторинг и контакты эскалации.
6. Провести knowledge transfer и записать открытые вопросы.
7. Закрыть временные доступы и подтвердить владельцев постоянных прав.

• новая команда может собрать и запустить проект по инструкции;
• понятно, какая версия передана и какие изменения в нее входят;
• доступы управляются ролями и владельцами, а не личными аккаунтами разработчиков;
• поддержка знает, где смотреть мониторинг, логи и инциденты;
• есть список известных ограничений, технического долга и открытых вопросов;
• эксплуатационная документация связана с кодом, changelog и релизным процессом;
• после передачи не требуется срочно искать бывших участников проекта для базовых операций.

Если при передаче требуется подтвердить восстановимость, выполните согласованное тестовое восстановление резервной копии. Для критичной функции передайте также план аварийного восстановления с ответственными, доступами и критериями завершения.

После handover полезно оставить короткий post-transfer log: дата передачи, версия, кто принял доступы, какие проверки прошли, какие вопросы остались и какие временные договоренности нужно закрыть. Это помогает не потерять контекст между финальной встречей, актом и реальным стартом поддержки.

Если поддержка в первые дни обнаруживает пробелы в инструкции, их нужно дополнять в документации, а не оставлять в переписке. Иначе следующая передача снова начнется с восстановления того же знания.

Отдельно стоит отметить временные исключения: доступ, который еще не переведен на группу, ручной обходной путь, неполный мониторинг или незакрытый дефект. У каждого такого исключения должен быть срок и владелец.

• передать zip-архив вместо репозитория с историей и версиями;
• оставить секреты и доступы в личных аккаунтах;
• не проверить сборку на чистом окружении;
• не описать миграции, настройки и внешние зависимости;
• не связать changelog с релизом и известными дефектами;
• провести knowledge transfer без записи решений и открытых вопросов;
• считать, что эксплуатационная документация нужна только после аварии.

После передачи проекта в поддержку у команды должен быть управляемый комплект: код и версия поставки, инструкции сборки, доступы, эксплуатационная документация, changelog, владельцы и понятные правила работы с инцидентами. Такой комплект снижает риск зависимости от исходной команды и делает дальнейшее сопровождение предсказуемым.

Если после передачи нужна внешняя команда, которая примет обращения и будет работать по согласованным правилам, следующий шаг — сопровождение информационной системы.