Что происходит, когда разработку незаметно передают по цепочке - и почему проблема не в самом субподряде, а в потере контекста и ответственности.

1. Субподряд - нормален. Непрозрачная подмена команды - нет

Субподряд в разработке сам по себе не является проблемой. У компании может не быть собственного специалиста по информационной безопасности, DevOps-инженера с нужной экспертизой или разработчика под редкий стек. Тогда подрядчик привлекает внешнего специалиста, встраивает его в процесс и по-прежнему отвечает за результат.

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

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

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

2. Где именно ломается контекст

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

Для разработчика настоящая задача начинается после этого списка. Что произойдет, если платеж прошел, но callback от провайдера не пришел? Можно ли повторно нажать кнопку? Как обеспечить идемпотентность? Кто является источником истины для статуса оплаты? Как устроены возвраты? Какие роли видят чужие заказы? Нужна ли история изменения статусов? Как система будет жить при росте нагрузки?

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

Бизнес: клиент должен безопасно оплачивать заказ
Мэнеджер: нужен экран оплаты и история платежей
Задача: POST /pay + кнопка «Оплатить»
Результат: status = paid после успешного ответа

Разработчик при этом может реализовать тикет без единой ошибки относительно полученного задания. Ошибка проявится позже - когда окажется, что система не умеет переживать повторные callbacks, частичный возврат или разрыв между статусом банка и локальной базой.

3. Архитектура особенно чувствительна к отсутствию контекста

Архитектура особенно чувствительна к отсутствию контекста

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

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

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

4. Что обычно исчезает раньше кода

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

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

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

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

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

5. Документация - это не README на три страницы

README с командами docker compose up и npm run build полезен, но покрывает очень маленькую часть передачи системы. Для следующей команды ценнее информация, которую невозможно уверенно восстановить из исходников.

• Схема инфраструктуры: какие компоненты существуют и как они связаны.

• Описание интеграций: кто кого вызывает, как устроена авторизация и какие есть ограничения.

• Модель данных для ключевых сущностей и миграций.

• ADR или другой журнал архитектурных решений: не только что сделано, но и почему

• Процесс deploy и rollback: что происходит от merge до production.

• Управление секретами и переменными окружения.

• Процедура backup/restore и действия при аварии.

• Известные ограничения и участки, которые требуют осторожной доработки

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

6. Что видит новая команда

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

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

После этого начинается программная археология: почему у заказа четыре похожих статуса? Почему один расчет продублирован в трех местах? Можно ли удалить колонку old_status или ее использует скрипт, который кто-то запускает вручную раз в месяц? Почему cron-задачу нельзя запускать дважды?

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

7. Репозиторий многое говорит о реальном процессе

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

• Кто и как часто делает коммиты

• Есть ли pull request и code review

• Запускаются ли тесты в CI.

• Есть ли issue tracker и связаны ли задачи с изменениями в коде.

• Кто принимает архитектурные решения и где они фиксируются.

• Как оформляются релизы, миграции и rollback.

• Кому принадлежат облачные аккаунты, домены и внешние сервисы.

8. Самый неприятный сценарий: ответственность без полномочий

Опасная конструкция возникает, когда перед заказчиком отвечает компания А, а технические решения принимает компания Б. У компании А - договор и аккаунт-менеджер. У компании Б - разработчики и доступ к коду.

Пока все работает, разница почти незаметна. При серьезной проблеме заказчик спрашивает, почему решение реализовано именно так. Компания А идет за ответом к компании Б. Компания Б ищет разработчика, который делал эту часть восемь месяцев назад. Разработчик уже на другом проекте. В лучшем случае ответ появляется через несколько дней. В худшем - решение никто не может объяснить.

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

9. Что спросить до подписания договора

Кто будет работать именно над нашим проектом?
Не какие специалисты вообще есть в компании, а кто назначен на проект: технический лидер, backend, frontend, QA. Кто делает code review? Можно ли поговорить с техническим лидером до старта?

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

Где будет находиться код и инфраструктура?
Хорошая практика - когда репозиторий доступен заказчику с начала проекта, а не передается архивом после последней оплаты. То же относится к облачным аккаунтам, доменам и внешним сервисам: критические ресурсы не должны существовать только внутри аккаунтов подрядчика без понятной процедуры передачи.

Что входит в Definition of Done?
Фраза «фича работает» слишком размыта. В зависимости от проекта в готовность могут входить code review, тесты, обновление документации, миграции, логирование, мониторинг и проверка rollback. Это гораздо полезнее обещаний «мы следуем лучшим практикам».

10. Если проект уже идет: проведите тест на независимость

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

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

11. Когда субподряд действительно полезен

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

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

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

Вывод

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

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

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

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

Материалы по теме

Biz360: «Разработчики для разработчиков: как устроен бизнес по модели аутсорс-продакшна»

Stripe: The Developer Coefficient (2018) - исследование потерь времени разработчиков из-за технических факторов