Компания получает репозиторий, документацию и доступы — кажется, что проект передан. А через неделю выясняется: без подрядчика никто не может выпустить обновление, восстановить систему после сбоя или объяснить, почему архитектура устроена именно так.
Формально исходный код уже у заказчика. Фактически системой по-прежнему управляют люди, которые её создали. Важные знания остались в переписке и памяти разработчиков, инструкции успели разойтись с реальностью, часть инфраструктуры контролирует внешняя команда. Инхаус боится трогать код, потому что не знает всех зависимостей и возможных последствий.
В статье разберём, как подготовить IT-проект к передаче, организовать совместную работу команд и проверить результат. А главное — как не оказаться в ситуации, когда компания владеет исходным кодом, но всё ещё зависит от его создателей.
Когда проект имеет смысл передавать в инхаус
Проект можно годами развивать с подрядчиком. Для многих компаний это проще и дешевле, чем содержать собственную команду. Инхаус становится оправданным, когда внутренняя экспертиза, скорость решений и контроль над системой начинают перевешивать преимущества внешней разработки.
Система критична для работы компании. От неё полностью зависят продажи, производство, расчёты, обслуживание клиентов или обязательства перед партнёрами. Малейшие риски для системы, в которые входит зависимость от подрядчика, угрожают выручке и ежедневной работе бизнеса.
Продукт предстоит постоянно развивать. Команда регулярно меняет бизнес-логику, подключает новые интеграции и запускает дополнительные сценарии. Внутренние специалисты быстрее принимают решения, потому что лучше знают контекст и находятся ближе к бизнесу.
В системе накапливается уникальная экспертиза. Архитектура, данные, алгоритмы и знание предметной области постепенно становятся частью конкурентного преимущества. Оставлять весь этот контекст только у внешней команды рискованно.
Нужен полный контроль над данными и инфраструктурой. Это особенно важно для финансовых, медицинских, промышленных и других систем с высокими требованиями к безопасности, аудиту и управлению доступами.
Зависимость от подрядчика стала операционным риском. Компания не может самостоятельно оценить состояние системы, заменить специалистов или продолжить разработку без первоначальной команды. Достаточно потерять нескольких ключевых инженеров на стороне подрядчика, чтобы развитие продукта остановилось.
Но передавать проект в инхаус только ради идеи «забрать всё внутрь» не стоит. Решение нужно принимать с учётом экономики, планов развития и реальных рисков. Если система стабильна, изменения выходят несколько раз в год, а постоянной загрузки для разработчиков нет, собственная команда может оказаться дороже поддержки подрядчика.
Что означает контроль над проектом
Права на исходный код ещё не дают контроля. Компания может владеть репозиторием и при этом обращаться к подрядчику при каждом релизе, сбое или изменении архитектуры.
Чтобы работать самостоятельно, заказчику нужно принять пять связанных контуров.
Код и архитектура
Исходный код всех компонентов хранится в доступном заказчику репозитории. Внутренняя команда понимает, как устроена система, где проходят границы сервисов, как они связаны между собой и почему были приняты ключевые архитектурные решения.
Внутренним инженерам недостаточно знать, как всё работает. Нужно понимать, почему система устроена именно так: какие ограничения в неё заложены, где накопился технический долг и какие изменения могут затронуть соседние модули.
Инфраструктура
Заказчик управляет средами разработки, тестирования и промышленной эксплуатации. Под его контролем находятся сборка, развёртывание, мониторинг, журналирование, резервное копирование и восстановление системы.
Критичные ресурсы — серверы, облачные кабинеты, домены, сертификаты и контейнерные реестры — должны принадлежать компании, а не отдельным сотрудникам подрядчика.
Данные и доступы
Компания понимает, какие данные обрабатывает система, где они хранятся, как перемещаются между компонентами и внешними сервисами и кто может их использовать.
У каждой учётной записи и интеграции есть владелец. Пароли, токены, ключи API и сертификаты хранятся в управляемом хранилище. Права можно централизованно выдавать, ограничивать и отзывать.
Процессы
Инхаус умеет пройти весь рабочий цикл: поставить задачу, изменить код, проверить результат, выпустить релиз, при необходимости откатить его, отреагировать на инцидент и восстановить систему.
Процессы нельзя передать одним комплектом инструкций. Они считаются освоенными только после того, как команда повторила их на практике без постоянных подсказок авторов системы.
Знания и люди
История решений, особенности предметной области, договорённости с бизнесом, известные ошибки и причины компромиссов редко помещаются в документацию целиком. Значительная часть контекста остаётся у людей.
Поэтому внутреннюю команду нужно подключать до ухода подрядчика и на некоторое время объединять с внешней.
Первым обычно приходит технический руководитель — он принимает архитектурный контекст и определяет, какие специалисты понадобятся для дальнейшей работы. Копировать состав команды подрядчика один к одному необязательно: некоторые роли могли подключаться временно, а отдельные компетенции выгоднее сохранить на внешней поддержке.
Передачу нужно планировать заранее
Собрать все контуры за последний месяц договора не получится. К этому времени часть знаний уже потеряна, документация отстаёт от системы, а внутреннюю команду, возможно, ещё даже не начали нанимать.
Поэтому будущую передачу стоит предусмотреть ещё до начала разработки:
- - Закрепить в договоре права на код, документацию и другие результаты работ.
- - Разместить основные репозитории и критичные учётные записи в контуре заказчика.
- - Вести документацию и фиксировать архитектурные решения по мере развития системы.
- - Предусмотреть период совместной работы подрядчика и инхауса.
- - Заранее определить состав передаваемых материалов и критерии приёмки.
- - Согласовать формат ограниченной поддержки после выхода подрядчика из регулярной разработки.
Если проект уже развивается, переход стоит начать с аудита пяти контуров. Он покажет, чем компания действительно управляет, какие ресурсы и знания всё ещё остаются у подрядчика и что предстоит восстановить до начала передачи.
Что должен передать подрядчик
Ниже — практический комплект, который понадобится инхаусу для самостоятельной работы. Точный состав зависит от архитектуры и отрасли, но основные группы обычно остаются неизменными.
Код, сборка и архитектура
- - Исходный код всех компонентов и полную историю изменений.
- - Список зависимостей, их версии и правила обновления.
- - Автоматические тесты и инструкции по их запуску.
- - Инструкции по локальному развёртыванию проекта.
- - Сценарии сборки, выпуска, развёртывания и отката релиза.
- - Схемы компонентов, интеграций и потоков данных.
- - Границы ответственности сервисов и ключевые архитектурные решения.
- - Известные ограничения, узкие места и технический долг.
Особенно важно сохранить причины спорных решений. Без этого новая команда снова пройдёт уже проведённые исследования или повторит ошибки, от которых проект когда-то отказался.
Инфраструктура, данные и безопасность
- - Тестовые и промышленные среды, серверы и облачные ресурсы.
- - Системы CI/CD, контейнерные реестры, мониторинг и журналы событий.
- - Резервные копии и проверенные инструкции по восстановлению.
- - Домены, сертификаты, лицензии, подписки и данные внешних провайдеров.
- - Модель и источники данных, правила хранения, передачи и резервного копирования.
- - Роли, права доступа, учётные записи, ключи API и другие секреты.
- - Результаты проверок безопасности, известные уязвимости и ограничения.
- - Владельцы, способ оплаты и ответственные за поддержку каждого критичного ресурса.
После передачи временные права подрядчика закрывают или ограничивают. Ключи и токены, к которым имела доступ внешняя команда, меняют.
Разработка и эксплуатация
- - Порядок постановки и приёмки задач.
- - Правила работы с ветками, кодом и Merge Request.
- - Сценарии тестирования и критерии качества.
- - Порядок выпуска и отката релизов.
- - Правила обработки дефектов, инцидентов и эскалаций.
- - Порядок поддержки пользователей и работы с внутренними заказчиками.
- - Правила обновления технической и эксплуатационной документации.
Продуктовый контекст
- - Дорожная карта, бэклог и текущие приоритеты.
- - Требования к текущим задачам и список незавершённых работ.
- - Принятые продуктовые решения, включая причины отказа от альтернатив.
- - Риски, зависимости и ограничения.
- - Договорённости с внутренними заказчиками и владельцами процессов.
Передаваемый комплект — не архив на всякий случай. Все материалы должны быть актуальны, доступны внутренней команде и пригодны для ежедневной работы.
Как происходит передача проекта
Проект передают постепенно. Сначала инхаус наблюдает за действующей командой, затем работает вместе с ней, принимает разработку и только после этого — полную ответственность за систему.
1. Инхаус подключается к действующей работе
Подрядчик продолжает вести проект, а внутренняя команда участвует в планировании, разбирает архитектурные решения, приходит на code review, изучает порядок выпуска релизов, инфраструктуру и мониторинг.
Важно не просто присутствовать на встречах, а включаться в реальные задачи, обновления и разборы инцидентов. Именно там обнаруживаются зависимости и неформальные правила, которые редко попадают в документацию.
2. Команды выполняют задачи совместно
Инхаус берёт отдельные компоненты, исправляет дефекты, дорабатывает интеграции, пишет тесты и участвует в релизах.
Подрядчик объясняет контекст, проверяет решения и помогает пройти весь путь задачи — от постановки до промышленной среды.
3. Инхаус ведёт разработку, подрядчик аудирует
Внутренняя команда самостоятельно проектирует изменения и готовит Merge Request. Внешние инженеры проверяют архитектуру, код, тестовое покрытие, безопасность и производительность. Заодно фиксируют повторяющиеся ошибки и пробелы в компетенциях.
Один удачный Merge Request ещё не результат — нужна серия задач, в которых команда стабильно соблюдает границы компонентов, обновляет тесты и доводит изменения до релиза.
4. Инхаус самостоятельно выпускает обновления
Команда собирает и тестирует релиз, разворачивает изменения, следит за мониторингом, при необходимости выполняет откат и устраняет возникшие проблемы.
Подрядчик остаётся рядом, но подключается только там, где внутренним специалистам действительно нужна помощь.
Готовность инхауса подтверждает не один успешный релиз, а повторяемый результат. Несколько изменений и хотя бы один разбор сбоя должны пройти без постоянного управления со стороны авторов системы.
5. Подрядчик переходит на ограниченную поддержку
После устойчивого перехода внешняя команда выходит из ежедневной разработки. Она подключается к редким архитектурным вопросам, сложным изменениям и критическим инцидентам.
Формат такой поддержки лучше согласовать заранее: зафиксировать время реакции, доступность ключевых специалистов, порядок эскалации, объём консультаций и стоимость дополнительных работ.
Тогда подрядчик остаётся страховкой, а не скрытой точкой зависимости.
Как принять проект после передачи
Техническая приёмка
Инхаус получает доступ к исходному коду всех компонентов и разворачивает систему с чистого окружения по актуальной инструкции.
Автоматические тесты запускаются и дают понятный результат. Сборка, выпуск и откат релиза воспроизводятся. Мониторинг и журналирование охватывают критичные процессы.
Отдельно команда проверяет восстановление из резервной копии. Архитектура, интеграции и зависимости должны быть описаны, а дефекты, ограничения, технический долг и незавершённые работы — собраны в одном реестре.
Замечания, которые подрядчик не закроет до выхода, принимают вместе с приоритетами, ответственными и дальнейшим планом.
Операционная приёмка
Внутренняя команда самостоятельно меняет бизнес-логику, выпускает обновление, проверяет систему после релиза и при необходимости выполняет откат.
Затем она разбирает тестовый или реальный инцидент, восстанавливает сервис и проверяет одну из внешних интеграций.
Хороший способ проверить качество передачи — подключить нового специалиста. Если он может развернуть проект, найти нужную документацию и выполнить первую задачу без серии созвонов с подрядчиком, знания действительно перешли внутрь компании.
Организационная приёмка
У каждого критичного компонента, а также у инфраструктуры, данных и безопасности появляется внутренний владелец.
Рабочие учётные записи, лицензии, подписки и договоры с внешними сервисами переходят под контроль компании. Одновременно назначаются ответственные за оплату, продление и поддержку.
Стороны фиксируют порядок работы с инцидентами и формат дальнейшей поддержки. Подрядчик может выйти из регулярной разработки только после того, как техническая, операционная и организационная приёмка завершены одновременно.
Типовые ошибки при передаче
Передача кода без эксплуатационного контура
Репозитории оказываются у заказчика, а сборка, развёртывание, мониторинг, резервное копирование и сертификаты остаются у подрядчика.
Код можно менять, но безопасно довести изменения до промышленной среды невозможно.
Написание документации в самом конце
Подрядчик откладывает документацию до передачи проекта, а затем пытается за несколько недель описать систему, которую команда развивала годами.
К этому моменту часть решений уже забыта, архитектурные схемы расходятся с кодом, а инструкции описывают прошлую версию системы. В результате инхаус получает документы, которым нельзя доверять.
Подключение инхауса после ухода подрядчика
Новые специалисты изучают систему методом проб и ошибок, а задать вопросы уже некому.
Компания экономит несколько недель совместной работы, но затем расплачивается месяцами адаптации, простоями и дорогими ошибками.
Первый релиз принимается за доказательство готовности
Один знакомый сценарий можно пройти с активной помощью авторов системы.
Устойчивая передача подтверждается только серией самостоятельных задач, релизов и технических решений.
Не фиксируется технический долг и ограничения
Новая команда не знает, какие решения были временными, где уже обнаружены проблемы и какие изменения особенно рискованны.
В итоге она заново исследует проект или ломает его самые хрупкие участки.
Ресурсы и ответственность остаются у отдельных людей
Домены, облачные кабинеты и ключи оформлены на сотрудников подрядчика, а внутри компании не назначены владельцы компонентов.
После ухода внешней команды даже продление подписки или решение обычного инцидента превращается в отдельный проект.
Как мы передаём проекты в SVK.Digital
Мы готовим систему к возможной смене команды ещё на этапе проектирования.
Разделяем архитектуру на компоненты с понятными зонами ответственности, фиксируем ключевые решения и интеграции, сохраняем историю изменений. Код проходит проверку, критичная логика покрывается тестами, а сборка и развёртывание автоматизируются.
Документацию ведём вместе с проектом. Описываем устройство системы, локальный запуск, выпуск релизов, работу с инфраструктурой, известные ограничения и технический долг. Так знания не остаются в памяти отдельных инженеров, а новые специалисты быстрее включаются в работу.
Во время перехода инхаус принимает реальные задачи, участвует в code review и самостоятельно выпускает обновления. Мы проверяем первые решения как технические аудиторы. При необходимости помогаем определить нужные роли, оценить кандидатов и собрать будущую команду.
Заказчик получает отчуждаемую систему, которую можно читать, менять и развивать без постоянного участия первоначальных разработчиков. Смена команды остаётся управляемым процессом и не заставляет каждый раз разбираться в проекте с нуля.
Заключение
Главный результат передачи проекта — отсутствие критической зависимости от сторонней команды.
Инхаус может самостоятельно использовать, поддерживать и развивать систему. Компания сохраняет контроль над продуктом, даже если внутри своей команды меняются люди.
Для этого нужен подрядчик на заказную разработку, который не просто отдаёт код и документацию, а помогает собрать зрелую команду, передаёт архитектурный контекст, проверяет первые изменения и остаётся рядом до тех пор, пока самостоятельная работа не станет устойчивой.
