Передача проекта другому подрядчику занимает от двух недель до трёх месяцев и начинается с аудита, а не с задач. До завершения аудита новая команда не даёт обещаний по срокам.
Документации не существует. Выясняется это на третий день после подписания акта, когда прежняя команда уже не отвечает, а у продукта завтра релиз и позавчера упал платёжный модуль.
Ситуация штатная для рынка, где заказчики всё чаще меняют исполнителей. Ненормально другое: принимать чужой проект по той же схеме, по которой начинают новый. Здесь другой порядок действий, другие сроки и другие обещания на входе. Разберём, что забрать у уходящего подрядчика, из чего состоит первый месяц новой команды и почему честный ответ на вопрос «когда вы начнёте делать задачи» звучит как «после аудита».
Список короткий, но собирать его нужно до того, как отношения испортятся окончательно.
Восьмой пункт стоит дешевле всего и спасает чаще остальных. Один созвон с человеком, который помнит, почему сервис перезапускается по расписанию, экономит новой команде неделю.
Заказчик обычно просит сразу начать с задач. Логика понятная: продукт стоит, бизнес ждёт. Проблема в том, что любая правка в незнакомой системе без понимания её связей превращается в лотерею.
Аудит отвечает на четыре вопроса. Что вообще развёрнуто в продакшене и совпадает ли это с тем, что лежит в репозитории. Какие версии платформ и библиотек используются и какие из них уже не получают обновлений безопасности. Как устроены сборка и развёртывание, можно ли повторить релиз без участия прежней команды. Где находятся места, правка которых ломает соседние части.
Срок аудита зависит от размера системы и обычно укладывается в одну-три недели. По его итогам появляются две вещи: карта рисков и честная оценка задач. До этого момента любая названная оценка это угадывание, и подрядчик, который называет сроки на первой встрече, либо не собирается их соблюдать, либо уже видел ваш код, что маловероятно.
Параллельно с аудитом можно и нужно закрывать аварийные вопросы. Упавший модуль чинят сразу, не дожидаясь карты рисков.
Технический долг редко ощущается как проблема до момента, когда нужно что-то изменить.
В проекте Фортех (fortech.dev), аккредитованной IT-компании из Ростова-на-Дону, для финтех-компании из сегмента B2B команда работала с микросервисом автоматизации постановки юридических лиц на мониторинг в рамках внутренних банковских процессов. Сервис обрабатывает события из очереди сообщений, ведёт список отслеживаемых компаний и общается с внешним шлюзом. Подключение было точечным: заказчику требовался Java-разработчик в команду, где уже работали 9 бэкенд-разработчиков, 4 фронтендера, 3 QA-инженера, аналитик и менеджер проекта.
Дальше формулировка из проектных материалов: обновил десятилетний сервис до приличного состояния. За этим стоят Spring Boot с версии 2 на 3.5.6, Java с 8 на 21, переезд со сборщика Maven на Gradle 8, централизованное версионирование зависимостей, переписанные тесты и настроенный генератор API для OpenAPI и AsyncApi.
Ни одна из этих задач не добавляет пользователю ни одной функции. Все они определяют, можно ли вообще добавить функцию за разумное время. Когда сопровождение и поддержка достаётся команде вместе с чужим кодом, работа начинается именно отсюда, и объяснять бизнесу ценность такого спринта приходится отдельно.
Оговорка: обновлять всё подряд до последних версий не нужно. Обновляют то, что мешает развитию или создаёт риск безопасности. Остальное живёт как есть, пока не появится причина.
Разговор проходит легче, если перевести технический долг в риски, а не в термины.
Работает простая таблица из трёх колонок, которую можно собрать за час: что сломано или устарело, что произойдёт, если это не трогать, сколько стоит починить. Устаревшая версия платформы без обновлений безопасности превращается в строку «уязвимость без исправлений, риск инцидента». Отсутствующие тесты превращаются в строку «каждая правка требует ручной проверки, срок любой доработки вырастает вдвое».
Дальше решение принимает бизнес, и это правильно. Задача команды не победить в споре, а показать цену обоих вариантов.
Хорошая практика для первого месяца: параллельно с аудитом и критическими исправлениями выпустить одну заметную для пользователей мелочь. Это не подмена приоритетов, а способ показать, что продукт жив и работа идёт.
Чтобы следующая передача прошла проще, в договор закладываются те же пункты, которых не хватило при расторжении с предыдущим.
Репозитории и доступы оформляются на компанию-заказчика с первого дня. Документация по развёртыванию обновляется как часть работ, а не как отдельный героический проект в конце. Требования к покрытию тестами фиксируются письменно. Прописывается процедура выхода: что подрядчик обязан передать, в какой срок и в каком виде, сколько часов консультаций входит в стоимость.
Пункт про выход обсуждать на старте неловко, а на финише поздно. Подрядчик, который соглашается на него спокойно, обычно спокойно же его и исполняет.
Приём чужого проекта это управляемая процедура с понятными этапами: сбор доступов, аудит, карта рисков, оценка, работа. Проблемы начинаются там, где первые три этапа пропускают ради скорости.
Если передача уже идёт, соберите список из восьми пунктов выше и пройдите по нему до расторжения договора. Каждый незакрытый пункт после расторжения стоит в несколько раз дороже.
От двух недель до трёх месяцев в зависимости от размера системы и качества документации. Первый этап это аудит: проверка того, что развёрнуто в продакшене, какие версии платформ используются, как устроено развёртывание и где находятся опасные места. Обычно аудит занимает одну-три недели.
Доступы ко всем средам и сервисам, исходный код всех веток, конфигурации окружений и инструкцию по развёртыванию, схему базы данных, список внешних интеграций с реквизитами, перечень известных дефектов и оплаченные часы консультаций с указанием срока их использования.
До аудита команда не знает связей внутри системы и реального состояния кодовой базы. Любая оценка на первой встрече будет угадыванием. Честный порядок такой: аварийные вопросы закрываются сразу, карта рисков и сроки по задачам появляются после аудита.
Перевести технический долг в риски: что устарело, что произойдёт при бездействии, сколько стоит исправление. Устаревшая версия платформы это риск инцидента без доступных обновлений безопасности, отсутствие тестов это удвоенный срок любой доработки. Решение после этого принимает бизнес.
БизнесSLA – ключевой документ, определяющий стандарты качества техподдержки. Разбираем структуру соглашения, критические метрики и методы контроля выполнения обязательств.
Читать
БизнесВыбор между аутсорсингом техподдержки и внутренней командой влияет на бюджет и качество сервиса. Разбираем реальные затраты, метрики эффективности и критерии выбора оптимальной модели для вашего бизнеса в 2026 году.
Читать
