Два слоя посредников между заказчиком и реальным исполнителем иногда ломают проект сильнее, чем слабый код или срыв спринта. Именно потеря контекста, а не сам субподряд, становится точкой, где продукт начинает дорожать, замедляться и терять управляемость.
Об этом пишет Habr / Карьера в материале о том, что происходит, когда разработку незаметно передают по цепочке: заказчик выбирает одну команду, обсуждает с ней продукт, смотрит портфолио и знакомится с техлидами, а после старта заметная часть работы уезжает другим людям. Внешне все может выглядеть прилично: менеджер на связи, демо проходят, задачи закрываются. Проблема проявляется позже, когда выясняется, что ключевые решения принимали специалисты, которые не слышали исходную бизнес-логику из первых рук.
В этом разборе важен нюанс: субподряд сам по себе не объявлен злом. Если подрядчику нужен узкий DevOps, специалист по информационной безопасности или разработчик под редкий стек, внешнего эксперта можно встроить в процесс без катастрофы. Такая модель работает, пока главная команда сохраняет ответственность за результат, не прячет состав исполнителей и не теряет нить между задачей, архитектурой и бизнес-целями. Тревожный сценарий начинается там, где вместе с задачей вниз по цепочке уходят не только часы разработки, но и право задавать вопросы, принимать решения и отвечать за последствия.
На простом примере это выглядит почти буднично. Бизнес формулирует задачу так: нужен личный кабинет клиента с оплатой. Для менеджера это набор экранов: авторизация, список заказов, карточка заказа, форма оплаты, история платежей. Но для разработчика настоящая работа стартует только после этого списка. Что делать, если платеж прошел, а callback от провайдера не дошел? Можно ли безопасно нажать кнопку повторно? Где источник истины по статусу оплаты: банк, платежный шлюз или внутренняя база? Как обрабатывать возвраты, частичные списания, повторы событий, конфликт локального статуса и данных провайдера? Когда инженер участвует в обсуждении продукта или хотя бы имеет прямой доступ к владельцу, такие вопросы всплывают сразу. Когда между ним и бизнесом два посредника, до исполнителя доезжает уже не контекст, а технический пересказ в духе POST /pay + кнопка «Оплатить». Формально тикет выполнен. Практически система может рассыпаться на первом нетиповом сценарии.
Где проект теряет деньги еще до релиза
Особенно болезненно потеря контекста бьет по архитектуре. В статье приводится пример с хранением клиентских документов. Для внутреннего сервиса на несколько десятков пользователей подойдет один набор решений. Если же продукт через год должен выдерживать десятки тысяч клиентов, партнерский API, аудит действий, сложные права доступа и требования по срокам хранения, архитектурные компромиссы будут совсем другими. Проблема в том, что разработчик не умеет проектировать под неизвестное будущее. Если он видит только локальный тикет и дедлайн спринта, он выберет решение, которое быстрее и дешевле реализовать сейчас. Это может быть вполне добросовестная инженерная работа на уровне отдельной задачи и одновременно плохое решение на уровне продукта.
Из этого вытекает неприятная асимметрия ожиданий. Заказчик уверен, что подрядчик думает о системе целиком и держит в голове следующий этап роста. Фактический исполнитель может даже не знать, что этот рост запланирован. Обе стороны вроде бы действуют рационально, но оптимизируют разные вещи. Одна покупает продуктовую устойчивость, другая поставляет код под конкретный спринт. Пока проект маленький, расхождение почти незаметно. Когда появляются интеграции, платежи, миграции, разные роли пользователей и зависимость от production-данных, расхождение становится дорогим.
Еще один важный тезис материала: когда проект нужно сделать дешевле первоначальной оценки, урезают не обязательно код. Гораздо чаще режут то, что не видно на демо, но определяет стоимость любых будущих изменений. Первой под нож идет аналитика: вместо разбора сценариев команде выдают готовое описание интерфейса, а спорные бизнес-правила всплывают уже в реализации через переделки. Следом страдают архитектурные решения: отдельное проектирование заменяют подходом сначала сделаем, потом разберемся. Для маленькой системы это иногда проходит без последствий, для продукта с несколькими интеграциями и сложной логикой счет приходит позже. Затем исчезают автоматические тесты. Фича работает на демонстрации, и задача считается закрытой, хотя через несколько месяцев любая доработка превращается в ручную проверку на регресс. Последней обычно жертвуют документацией, потому что она не двигает дату первого релиза и не производит впечатления на презентации.
Почему репозиторий иногда честнее презентации
Отдельный акцент сделан на документации, причем не в бытовом смысле README на три страницы с командами для запуска. Для новой команды по-настоящему ценна информация, которую нельзя надежно восстановить из исходников. Это схема инфраструктуры, описание интеграций, модель данных для ключевых сущностей и миграций, журнал архитектурных решений с объяснением не только что сделали, но и почему сделали именно так, процесс deploy и rollback, правила работы с секретами и переменными окружения, процедуры backup/restore и список известных ограничений. Последний пункт особенно важен: зрелая команда знает не только устройство системы, но и ее опасные места, временные компромиссы и исторические связки. Если это знание не зафиксировано, оно уходит вместе с человеком.
Поэтому передача проекта новой команде без документации часто выглядит не как обычный онбординг, а как цифровая археология. Сначала нужно понять, собирается ли проект локально. Потом выяснить, какая ветка соответствует production, где лежат актуальные переменные окружения, почему состояние миграций в базе отличается от того, что в репозитории, какие внешние сервисы реально используются и у кого есть к ним доступ. Дальше начинаются вопросы, которые одним чтением кода не закрыть: почему у заказа четыре почти одинаковых статуса, зачем один и тот же расчет продублирован в трех местах, можно ли удалить поле old_status или его все еще дергает чей-то ручной скрипт раз в месяц, почему cron нельзя запускать повторно. В этот момент заказчик уже платит не за новую функциональность, а за восстановление памяти о собственной системе.
Наконец, материал предлагает смотреть не только на код, но и на историю его появления. Репозиторий много говорит о реальном процессе, даже если на созвонах все звучит убедительно. Один разработчик в истории коммитов сам по себе еще ничего не доказывает, но если заказчику продавали постоянную команду из нескольких специалистов, а год работы представлен одним аккаунтом с прямыми коммитами в main, вопрос о фактической модели работы возникает сам собой. Полезно проверить, кто и как часто коммитит, есть ли pull request и code review, запускаются ли тесты в CI, связан ли issue tracker с изменениями в коде, где фиксируются архитектурные решения, как оформляются релизы и rollback, кому принадлежат облачные аккаунты, домены и внешние сервисы. Для бизнеса это уже не технические мелочи, а способ понять, кто на самом деле контролирует продукт.
Для русскоязычного IT-рынка здесь нет сенсации, но есть неприятно точный диагноз. Аутсорс и субподряд никуда не денутся: редкая экспертиза, давление по срокам и экономике проекта только подталкивают к таким схемам. Вопрос в другом: готовы ли заказчики и подрядчики наконец считать контекст, документацию и прозрачность состава команды не факультативом, а частью самого продукта. Пока ответ на него чаще прячется не в договоре и не в демо, а в том, кто именно пишет код, принимает решения и сможет объяснить их через полгода.