Безболезненный разрыв: когда и почему нужно менять подрядчика на проекте

Автор: Владимир Белозеров, заместитель коммерческого директора KODE.

Чтобы сменить IT-подрядчика без потери продукта, сначала нужно проверить состояние системы, затем зафиксировать состав передаваемых материалов, получить код и доступы, самостоятельно собрать продукт и только после этого подключать полную новую команду. Переход должен идти по плану с ответственными, сроками и критериями приёмки, а не строиться на устных договорённостях.

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

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

Когда смена подрядчика становится разумным решением

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

Сроки переносятся без понятного плана

В разработке бывают неожиданные сложности, поэтому сам перенос даты не говорит о слабой команде. Важнее, способен ли подрядчик объяснить причину, пересчитать объём работы, назвать новую дату и показать, как предотвратит повторение.

Тревожный сигнал — третий перенос подряд без ясного объяснения и обновлённого плана. Бизнес перестаёт понимать, когда получит результат и сколько ещё заплатит.

Проблема распространена: по данным CHAOS Report 2020 от Standish Group, около 31% IT-проектов относятся к успешным, 50% завершаются с задержкой, перерасходом или сокращением объёма, а 19% не достигают результата.

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

Команда больше не соответствует масштабу продукта

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

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

McKinsey изучила более 1700 продуктовых команд в 75 организациях и связывает согласованность стратегии, структуры, людей, процессов и технологий со скоростью, качеством и эффективностью работы.

Как не выбирать исполнителя только по цене, мы рассказали в статье «Как выбрать подрядчика для разработки MVP».

Бизнес потерял прозрачность

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

Основные признаки потери контроля:

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

Такая зависимость называется vendor lock-in. Она делает смену команды дорогой даже при наличии рабочего продукта. Подробный список способов защиты есть в статье «Как избежать vendor lock-in».

Риски качества и безопасности не устраняются

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

В финансовой отрасли цена ошибки особенно высока. По данным IBM Cost of a Data Breach Report 2024, средняя стоимость утечки данных для финансовой компании составила $6,08 млн — на 22% выше среднего значения по всем отраслям.

Эта цифра не означает, что любой сбой приведёт к таким потерям. Она показывает масштаб риска, если критичный продукт развивается без контроля доступов, данных и безопасности.

Нужно ли сначала попытаться восстановить работу

Перед разрывом полезно провести короткую проверку и дать подрядчику возможность представить план исправлений. Это помогает отличить временную проблему от системной.

Попросите команду подготовить:

1. Текущее состояние задач и релизов.
2. Причины последних задержек и сбоев.
3. Список технических ограничений.
4. План на ближайшие четыре–восемь недель.
5. Перечень доступов, документов и ответственных.
6. Оценку ресурсов, которых не хватает.

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

Почему передача проекта часто затягивается

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

Сопротивление не всегда выглядит как прямой отказ. Код могут передать без истории изменений, документы — в устаревшем виде, а доступы — только к части сервисов. Формально обязательство выполнено, но запустить продукт самостоятельно невозможно.

Дополнительная сложность — технический долг. В Stack Overflow Developer Survey 2024 62% профессиональных разработчиков назвали технический долг главным источником недовольства в работе. При смене команды скрытые временные решения увеличивают срок погружения, особенно если причины их появления нигде не записаны.

Чтобы не спорить об абстрактной «полноте передачи», заранее определите проверяемый результат: новая команда должна собрать продукт из полученного кода, запустить его в тестовой среде и выпустить изменение без помощи прежнего подрядчика.

Как сменить IT-подрядчика: четыре этапа

Этап 1. Провести аудит текущего состояния

Сначала нужно понять, что именно принимает новая команда. Аудит охватывает:

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

Цель проверки — не оценить прежних разработчиков, а определить объём перехода и риски. Иногда выясняется, что систему можно продолжать развивать сразу. В другом проекте сначала придётся восстановить процесс выпуска или заменить критичный компонент.

По опыту KODE, при анализе фактической работы расхождение между прежней оценкой и реальной сложностью отдельных задач может составлять 10–15%. Чем меньше документации и автоматизации, тем труднее заранее оценить погружение.

Как подготовиться к такой проверке, описано в статье «Зачем бизнесу аудит IT-проекта».

Этап 2. Зафиксировать план передачи

После аудита составьте единый список материалов. В него должны входить:

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

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

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

Все расхождения нужно записывать в протокол: чего не хватает, кто передаёт и к какой дате. Устной договорённости для критичного материала недостаточно.

Этап 3. Подключить минимальную новую команду

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

Они должны:

1. Получить и проверить доступы.
2. Собрать продукт из переданного кода.
3. Запустить тестовую среду.
4. Проверить автоматические тесты.
5. Выпустить безопасное небольшое изменение.
6. Проверить наблюдение за системой и восстановление.

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

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

Этап 4. Передать знания и завершить переход

Документы не объясняют всех причин, по которым команда принимала решения. Поэтому полезны рабочие встречи прежних и новых специалистов.

На таких встречах разбирают:

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

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

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

Когда можно считать передачу завершённой

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

Проверьте пять результатов:

1. Код собирается из репозитория компании.
2. Тестовая и рабочая среды доступны и описаны.
3. Новая команда может выпустить и откатить версию.
4. Данные резервируются и восстанавливаются.
5. Критичные сервисы, домены, сертификаты и аккаунты находятся под контролем заказчика.

Если хотя бы один из этих пунктов зависит от прежней команды, переход ещё не закончен.

Какие ошибки чаще всего допускают при смене подрядчика

Ошибка 1. Сначала расторгнуть договор, потом разбираться с продуктом

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

Ошибка 2. Считать архив с кодом полноценной передачей

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

Ошибка 3. Сразу подключить большую новую команду

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

Ошибка 4. Пытаться сразу переписать всю систему

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

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

Ошибка 5. Не проверить права и владельцев аккаунтов

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

Все критичные аккаунты должны принадлежать заказчику, а подрядчики получать только необходимые роли.

Чек-лист смены IT-подрядчика

До решения о переходе

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

Во время аудита

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

Во время передачи

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

Перед завершением перехода

• Новая команда самостоятельно собрала продукт.
• Тестовая среда работает.
• Выпущено небольшое изменение.
• Проверен откат версии.
• Проверены резервные копии и восстановление.
• Критичные аккаунты находятся под контролем компании.
• Секреты и пароли обновлены.
• Назначены владельцы систем и процессов.

Сколько времени занимает смена IT-подрядчика

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

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

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

Сколько стоит смена подрядчика

Стоимость включает не только работу новой команды. Нужно учитывать:

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

Чем раньше компания сохраняет контроль над кодом, инфраструктурой и знаниями, тем дешевле будущая смена исполнителя.

Как снизить зависимость от подрядчика заранее

Лучший переход — тот, к которому компания технически готова даже при хорошем сотрудничестве.

Для этого:

1. Оформляйте репозитории, облако, домены и магазины приложений на компанию.
2. Выдавайте подрядчику ролевые доступы вместо владения аккаунтами.
3. Требуйте актуальные инструкции по сборке, выпуску и восстановлению.
4. Храните архитектурные решения и историю изменений.
5. Регулярно проверяйте резервные копии.
6. Не допускайте концентрации критичных знаний у одного человека.
7. Фиксируйте порядок передачи в договоре до начала разработки.

Эти меры не означают недоверие к партнёру. Они делают цифровой продукт самостоятельным активом компании.

Главное

Смена IT-подрядчика не должна начинаться с поиска новой команды. Сначала бизнесу нужно вернуть контроль над продуктом: понять его состояние, получить код и доступы, проверить права и зафиксировать знания.

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

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

Нужно оценить состояние проекта перед сменой подрядчика? Команда KODE поможет провести технический аудит, определить риски перехода и составить план передачи продукта.
Оценить проект

FAQ о смене IT-подрядчика

Когда пора менять IT-подрядчика?

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

Что нужно получить от старого подрядчика?

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

Как проверить, что проект действительно передан?

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

Можно ли сменить подрядчика, если документации нет?

Да, но переход займёт больше времени. Новой команде придётся восстанавливать устройство системы по коду, инфраструктуре и поведению работающего продукта.

Нужно ли останавливать разработку на время перехода?

Не обязательно. При хорошем состоянии проекта команды могут некоторое время работать параллельно. Но критичные изменения лучше ограничить, пока новая команда не проверит сборку, выпуск и восстановление.

Стоит ли сразу переписывать продукт после смены команды?

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

Как избежать зависимости от нового подрядчика?

Хранить код и инфраструктуру в аккаунтах компании, поддерживать документацию, распределять знания между несколькими специалистами и заранее закреплять порядок передачи в договоре.