Кто на самом деле пишет ваш проект
Субподряд в разработке сам по себе не представляет угрозы. Компания может привлечь внешнего специалиста по информационной безопасности, DevOps-инженера или разработчика редкого стека - и это будет разумным решением. Важны не формальные отношения между организациями, а прозрачность процесса, сохранение контекста и понятное распределение ответственности.
Риски появляются тогда, когда заказчик выбирает одну команду, обсуждает с ней продукт, знакомится с ключевыми специалистами, изучает портфолио, а после подписания договора значительная часть работы незаметно передается другой компании. Иногда новая команда также привлекает исполнителей, и проект проходит через несколько уровней посредников.
Внешне ситуация может выглядеть благополучно: менеджер выходит на связь, спринты закрываются, на демонстрациях появляются новые экраны. Однако фактическую разработку ведут люди, с которыми заказчик никогда не общался. Они могут быть сильными специалистами, но не знать целей продукта, ограничений бизнеса и причин, по которым ранее были приняты те или иные решения.
Главная проблема здесь не в субподряде как таковом. Она возникает в тот момент, когда по цепочке теряются бизнес-контекст, право принимать решения и ответственность за результат системы в целом.
Как искажается исходная задача
Фраза "нужен личный кабинет клиента с оплатой" для владельца продукта означает гораздо больше, чем набор экранов. В ней могут подразумеваться авторизация, история заказов, безопасность платежей, возвраты, повторная оплата, разграничение доступа и корректное отображение статусов.
Для технической команды важны уже другие вопросы:
- что делать, если банк подтвердил платеж, но уведомление не дошло;
- можно ли повторно отправить запрос без двойного списания;
- какой источник считается главным для статуса операции;
- как обрабатываются возвраты и частичные возвраты;
- кто имеет право видеть данные другого пользователя;
- нужна ли полная история изменения статусов;
- как система будет работать при росте количества клиентов.
Если разработчик участвует в обсуждении продукта напрямую, такие вопросы обычно появляются своевременно. Когда между владельцем бизнеса и исполнителем находятся несколько посредников, до него может дойти лишь упрощенная цепочка:
> бизнес: клиент должен безопасно оплачивать заказ;
> менеджер: нужен экран оплаты и история платежей;
> задача: добавить кнопку и метод POST /pay;
> результат: установить статус `paid` после успешного ответа.
Формально исполнитель реализует задачу правильно. Но позднее выясняется, что система не умеет обрабатывать повторные уведомления, расхождения между банком и локальной базой, отмену платежа или временную недоступность внешнего сервиса.
Почему архитектура страдает первой
Особенно чувствительны к потере контекста архитектурные решения. Представим сервис, в котором нужно хранить документы клиентов. Для внутренней системы на несколько десятков пользователей подойдет один подход. Но если через год ожидаются десятки тысяч клиентов, партнерский API, аудит действий, отдельные права доступа и специальные сроки хранения, архитектура должна быть иной.
Разработчик не способен учитывать планы, о которых ему никто не рассказал. Он выберет решение, оптимальное с точки зрения текущего тикета, имеющегося бюджета и сроков. Это может быть профессиональный выбор при доступной информации, но неудачный вариант для продукта в долгосрочной перспективе.
Заказчик при этом уверен, что подрядчик строит систему с учетом будущего развития. Фактический исполнитель видит только локальную задачу и дедлайн ближайшего спринта. В результате обе стороны действуют добросовестно, но решают разные задачи.
Что исчезает раньше исходного кода
При попытке сократить стоимость проекта обычно уменьшают не число строк программы. Сначала убирают работу, которую сложно показать на демо, но именно она определяет цену будущих изменений.
Аналитика
Подробное описание пользовательских сценариев заменяется перечнем экранов. Неочевидные бизнес-правила выясняются уже во время разработки или после запуска. Каждое такое уточнение приводит к переделкам, конфликтам и дополнительным расходам.
Архитектурное проектирование
Вместо фиксации ключевых решений появляется подход "начнем, а дальше разберемся". Для небольшого прототипа он может быть оправдан, но в сложной системе быстро формирует технический долг.
Тестирование
Проверяется только основной позитивный сценарий. Не рассматриваются повторные запросы, сбои интеграций, неполные данные, права доступа, восстановление после ошибок и миграции.
Передача знаний
Новая команда получает набор тикетов и доступ к репозиторию, но не понимает, почему код устроен именно так. Документация превращается в формальность, а знание остается у отдельных людей.
Документация - это не только README
Качественная документация должна отвечать не на вопрос "как запустить проект", а на вопрос "как безопасно принимать решения и менять систему". В ней желательно зафиксировать:
- назначение основных модулей;
- карту интеграций;
- источники данных и правила синхронизации;
- ограничения и известные компромиссы;
- порядок развертывания;
- процедуру отката;
- правила работы с секретами;
- структуру логирования и мониторинга;
- критические пользовательские сценарии;
- причины значимых архитектурных решений.
README на несколько страниц может быть полезен, но он не заменяет карту системы и журнал инженерных решений.
Что можно понять по репозиторию
Репозиторий часто показывает реальный процесс лучше, чем презентация подрядчика. Стоит обратить внимание на структуру коммитов, качество pull request, наличие тестов, понятность конфигурации и разделение окружений.
Тревожными признаками могут быть:
- все изменения выполняются одним огромным коммитом;
- сообщения коммитов не объясняют содержание работы;
- в коде много временных решений без комментариев;
- секреты хранятся рядом с исходниками;
- нет инструкции по локальному запуску;
- тесты существуют только формально;
- критические операции никак не логируются;
- невозможно понять, кто и почему изменил архитектуру.
Отдельно полезно проверить, может ли независимый инженер развернуть проект без участия первоначального исполнителя. Если для запуска нужны устные объяснения, личные ключи конкретного сотрудника или доступ к неописанному серверу, команда фактически контролирует не только код, но и знания о системе.
Самый опасный сценарий
Наиболее неприятная ситуация возникает, когда ответственность остается у одного подрядчика, а полномочия и знания находятся у другой команды. Заказчик требует исправить проблему у своего контрагента, тот ссылается на субподрядчика, а субподрядчик утверждает, что реализовал только переданный тикет.
В итоге никто не отвечает за продукт целиком. Каждый участник может формально доказать собственную правоту, но система все равно не выполняет бизнес-задачу.
До начала работы нужно заранее определить:
- кто утверждает архитектурные решения;
- кто общается с владельцем продукта;
- кто имеет право менять требования;
- кто отвечает за безопасность;
- кто принимает код;
- кто исправляет дефекты после релиза;
- кто владеет репозиторием, инфраструктурой и документацией;
- как заказчик узнает о привлечении новых исполнителей.
Что спросить до подписания договора
Полезно получить прямые ответы на несколько вопросов:
1. Кто конкретно будет работать над проектом?
2. Можно ли общаться с техническим руководителем и ключевыми разработчиками?
3. Какие работы выполняются силами подрядчика, а какие передаются внешним специалистам?
4. Как заказчик будет уведомлен о замене команды?
5. Кто отвечает за архитектуру и итоговое качество?
6. Где хранятся код, документация и инфраструктурные настройки?
7. Как проходит передача проекта при смене исполнителя?
8. Какие артефакты входят в результат работ?
9. Кто устраняет ошибки после релиза и в течение какого срока?
10. Как фиксируются решения, влияющие на безопасность и масштабирование?
Важно не просто получить обещания, а закрепить их в договоре и рабочих регламентах.
Как проверить проект, если разработка уже идет
Если есть подозрение, что проект фактически выполняет другая команда, не обязательно начинать с конфликта. Можно провести проверку независимости.
Попросите нового специалиста без участия текущего подрядчика:
- запустить проект локально;
- описать основные компоненты;
- показать путь критического пользовательского сценария;
- объяснить процесс релиза;
- найти точку входа конкретного запроса;
- перечислить внешние зависимости;
- назвать известные ограничения системы.
Если даже опытный инженер не может выполнить эти действия без устных подсказок, проект сильно зависит от неформальных знаний.
Полезен и технический аудит: проверка доступов, резервного копирования, журналов, миграций, обработки ошибок и настроек окружений. Такой аудит показывает не только качество кода, но и способность команды передавать систему.
Когда субподряд действительно полезен
Привлечение внешних специалистов оправдано, если оно прозрачно и управляемо. Например, основная команда может передать отдельный аудит безопасности профильной компании, а затем самостоятельно внедрить рекомендации. Или привлечь эксперта по высоконагруженным системам для конкретного этапа проектирования.
Хорошая модель предполагает единый центр ответственности, доступ исполнителей к необходимому контексту, документирование решений и сохранение всех артефактов у владельца проекта. Внешняя команда должна усиливать разработку, а не превращаться в скрытый слой, через который невозможно добраться до реального состояния системы.
Субподряд становится проблемой не тогда, когда в проекте участвуют несколько компаний. Он опасен, когда заказчик не знает, кто пишет код, исполнитель не понимает целей продукта, а ответственное лицо не обладает полномочиями управлять техническим результатом. Прозрачные роли, прямой доступ к знаниям, качественная документация и проверяемая передача проекта позволяют избежать ситуации, в которой система формально создана, но никто не способен надежно объяснить, как она работает и кто отвечает за ее будущее.
