Смена подрядчика по разработке: с чего начать

Смена подрядчика по разработке почти никогда не сводится к «найдём другую команду». Меняется не только исполнитель, но и доступ к знаниям, инфраструктуре, истории технических решений и пониманию того, почему продукт работает именно так.

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

Речь здесь не только про код, а про предсказуемость: можно ли обещать сроки, планировать бюджет на развитие и быть уверенным, что обновление не остановит продажи.

Мы собрали опыт технического директора, менеджера проектов и специалиста по тестированию АЙТИФОКС — людей, которые принимали ИТ-продукты у предыдущих команд и видели, где возникают проблемы.

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

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

• Какая версия продукта работает у клиентов прямо сейчас?

• Как выпускается обновление?

• Какие интеграции критичны для выручки?

• Где хранятся доступы и секреты?

• Какие задачи выполняются автоматически по расписанию?

• Что произойдёт, если обновление сломает систему?

• Можно ли восстановить данные из резервной копии?

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

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

Позже эту историю разобрали в отдельном кейсе — как перезапускали legacy-платформу после двух команд, ускорили загрузку и восстановили интеграции.

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

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

Универсального момента нет. Но есть сигналы, которые стоит проверить, прежде чем принимать решение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но качество кода нельзя оценивать отдельно от задач продукта.

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

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

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

В практике АЙТИФОКС был случай, когда переписали не весь продукт, а только проблемную логику работы с данными. При этом система должна была оставаться доступной для пользователей.

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

Похожий подход — сохранение legacy-ядра и создание современного слоя для взаимодействия с ним — описан в кейсе «Proxy API для legacy-системы».

По итогам технического аудита заказчик может получить схемы текущей и предлагаемой архитектуры, описание проблем, рисков и вариантов исправления. Для этого используют UML, C4, sequence diagrams и другие инструменты.

Единого формального шаблона отчёта нет — его содержание зависит от задач и состояния системы.

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

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

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

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

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

Статусу «всё работает» нельзя доверять без проверки.

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

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

Разбираться пришлось срочно, вместе с представителями внешнего сервиса.

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

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

Это зона, где экономия времени может обернуться серьёзными рисками.

Перед изменениями в действующей системе стоит проверить несколько вещей.

Исходный код и ветки. Убедиться, что ветка, из которой собирается релиз, соответствует версии, работающей у пользователей.

Логи, метрики и уведомления. Проверить доступ к инструментам мониторинга. Например, Sentry или Grafana, если они используются в проекте.

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

CI/CD. Проверить права на запуск, фактическую успешность обновлений и возможность отката.

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

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

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

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

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

Исправлять всё одновременно не нужно.

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

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

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

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

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

Управленческую сторону смены подрядчика часто недооценивают.

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

Это понятно: доверия меньше, контроля хочется больше. Но у таких требований есть цена — время команды.

В одном из проектов подготовка к приёмке в пятницу занимала часть спринта, а приведение документов к требованиям ГОСТ потребовало около 4–5 дней.

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

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

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

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

Перед передачей ИТ-проекта новой команде стоит пройти по основным пунктам:

• Получить исходный код и доступы к репозиториям.

• Сверить ветку релиза с версией, которая работает у пользователей.

• Проверить тестовое окружение или подготовить его.

• Проверить CI/CD, права на запуск и возможность отката обновлений.

• Проверить резервные копии пробным восстановлением.

• Зафиксировать критические пользовательские сценарии.

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

• Проверить доступ к логам, метрикам и уведомлениям.

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

• Собрать документацию: wiki, ADR, API, фоновые задачи, серверы, схемы БД, архитектурные диаграммы.

• Оценить зависимость от отдельных специалистов.

• Классифицировать технические риски по влиянию на работу продукта.

• Определить, какие компоненты сохранить, доработать или заменить.

• Сделать первый релиз небольшим, проверяемым и обратимым.

• Настроить понятную приёмку и критерии готовности задач.

Смена подрядчика по разработке — это управляемый переход, а не лотерея.

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

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

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