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

Передача ИТ-проекта в поддержку - это управляемый 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, владельцы и понятные правила работы с инцидентами. Такой комплект снижает риск зависимости от исходной команды и делает дальнейшее сопровождение предсказуемым.