Несколько IT-подрядчиков одновременно: мультивендорная модель

Коротко: когда это работает

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

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

Как делить работу между подрядчиками

Хорошая граница — та, через которую команды общаются редко и формально.

• По компонентам системы: мобильное приложение, backend, админка, интеграции. Самый понятный вариант.
• По бизнес-доменам: каталог, заказы, платежи. Подходит для крупных систем с независимыми сервисами.
• По типу работ: разработка у одних, тестирование или инфраструктура у других. Требует особенно чёткого процесса передачи.

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

Интерфейсы и владение

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

1. Контракт API. Описание эндпоинтов, форматов, ошибок и версий — например, в спецификации OpenAPI. Изменения — только через согласование.
2. Контракт данных. Какие сущности кто создаёт, кто является источником истины для каждого поля.
3. Тестовые стенды и моки. Чтобы команда могла работать, не дожидаясь готовности соседа.
4. Матрица ответственности. Для каждого компонента — один владелец.

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

Как согласовывать релизы

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

Как избежать перекладывания ответственности

Ситуация «это не у нас, это у них» — самый частый симптом размытых границ.

• Логи и мониторинг на стыках: по ним видно, кто отправил и что получил.
• SLA для каждого подрядчика с понятными сроками реакции на инциденты.
• Правило первого ответчика: тот, кто получил инцидент, разбирается и при необходимости передаёт его дальше с данными, а не просто перенаправляет.
• Разбор инцидентов без поиска виноватых: цель — исправить процесс или контракт, а не найти виновника.

Когда нужен ведущий интегратор

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

Он нужен, если:

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

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