Смена подрядчика: как не потерять продукт
Или история о том, как бизнес получает работающую систему, которой не может управлять.
Представьте: продукт годами делает одна команда. Всё работает, релизы выходят, бизнес растёт. А потом команда уходит — и выясняется, что никто не знает, какая версия кода сейчас у клиентов, как выпускается обновление, какие интеграции критичны и что сломается, если нажать не ту кнопку. Формально у компании есть код, репозиторий, серверы и договор. Фактически — система, которой она не управляет.
Знакомая картина? Мы собрали опыт технического директора, менеджера проектов и специалиста по тестированию АЙТИФОКС — людей, которые принимали IT-продукты у предыдущих команд и видели, где обычно рвётся.
Когда пора менять подрядчика, а когда ещё можно исправить ситуацию. Как понять, что продукт замедляется по мере роста, знания закреплены за людьми, а не за командой, а обновления выпускаются со страхом. И почему решение стоит принимать не по сумме уже потраченного, а по прогнозу.
Что запросить при передаче проекта. Код, инфраструктуру, доступы, документацию, фоновые процессы, историю решений. Отдельно — про ADR: зачем нужен журнал архитектурных решений и почему это не документ для галочки.
Как провести диагностику IT-продукта. С чего начинать, как проверять нагрузку, когда переписывать компонент, а когда сохранять существующее решение. И почему «красивый код» — не то же самое, что «код, который решает задачу бизнеса».
Какие сценарии и интеграции проверить в первую очередь. Включая историю о том, как подтверждение отправки на экране не равно доставке данных во внешний сервис — и чем это обернулось на важном мероприятии.
Как выстроить приёмку, чтобы отчётность не съедала спринт. С примером из проекта, где на приведение документов к требованиям ГОСТ ушло около 4–5 дней, а после двух спринтов переделок стало меньше.
В статье есть раздел «Что не стоит считать гарантией». Это не оговорка на всякий случай, а важная часть: часть выводов в таких историях — экспертные наблюдения и иллюстрации, а не измеренные факты. Мы отдельно проговорили, где заканчивается опыт и начинаются предположения, чтобы не выдать желаемое за доказанное. Внутри — десять ограничений, которые полезно держать в голове, когда читаешь любую историю про смену подрядчика.
Смена подрядчика — это управляемый переход, а не лотерея. Чем раньше бизнес получает доступы, документацию, понимание критических сценариев и возможность безопасно выпускать изменения, тем меньше он зависит от конкретной команды.
В статье — чек-лист заказчика и разбор реального кейса: как принимали продукт после двух предыдущих команд, что из этого вышло и почему иногда достаточно хирургического вмешательства, а не полной замены.
Полный текст — на сайте: https://itfox-web.ru/ru/blog/kak-smenit-podriadchika-po-razrabotke-i-ne-poteriat-kontrol-nad-it-pro?utm_source=teletype&utm_medium=article&utm_campaign=change_contractor_2026