Как известный подрядчик передаёт ваш проект вглубь цепочки субподрядчиков, почему это разработка по принципу «испорченного телефона», и во что это обходится бизнесу через год Здесь и далее «ваша команда» - это не абстрактная команда компании, а те конкретные люди, которых вам показали, с которыми вы обсуждали задачу и которых вы, по сути, заказывали.
Заказчик подписывает договор с узнаваемым брендом, а код по факту пишет субподрядчик или фрилансер в конце цепочки перепродаж. На каждом шаге экономят на аналитике, архитектуре, тестировании и документации. Это незаметно, пока проект не окажется в продакшене и не начнут появляться вопросы - незаметно ровно до первой серьёзной доработки или смены исполнителя.
Классическая история: компания выбирает подрядчика по портфолио, отзывам и внушительному сайту. Договор подписан, звучат правильные слова про full cycle, agile и выделенную команду. Первые недели всё идёт гладко - присылают план, макеты, демо.
Проблема в том, что фактическая разработка в этот момент может идти вообще не в этой компании. Проект - целиком или частично - уже передан дальше: другому подрядчику поменьше, студии без имени, а иногда напрямую фрилансеру, который взял задачу по цене, о которой заказчик никогда не узнает.
Сама модель, когда одно агентство ищет под проект стороннего исполнителя, распространена и открыто описывается участниками рынка [1]. Проблема не в факте субподряда, а в том, что клиент часто о нём не знает.
1. Каждая передача - это не просто комиссия, это потеря контекста
Когда бизнес формулирует задачу, в ней всегда больше смысла, чем в тексте технического задания. «Нам нужен личный кабинет с оплатой» на самом деле означает десятки решений: как работает возврат средств, что делать при повторном платеже, кто видит чужие заказы, как масштабируется база клиентов через год.
Человек, который изначально общался с заказчиком, эти нюансы слышал - хотя бы частично. Тот, кому задачу передали через два-три звена, видит уже не бизнес-задачу, а обрезанный пересказ пересказа: техническое задание, урезанное до списка экранов и кнопок.
Каждая передача - это не только маржа посредника. Это ещё и точка, где часть смысла задачи теряется безвозвратно.
2. На чём экономят, когда продают проект дальше
У субподряда есть простая математика: чем ниже по цепочке уходит проект, тем меньше денег остаётся на саму работу - и тем сильнее хочется закрыть задачу теми силами, которые видны заказчику: интерфейсом.
Первыми из бюджета обычно выпадают статьи, которые не видны на демо:
аналитика и сбор требований - «и так всё понятно из брифа»;
архитектурное проектирование - «начнём кодить, разберёмся по ходу»;
тестирование - «прогоним руками перед сдачей»;
документация - «код и так читаемый».
Каждая из этих статей выглядит как необязательная роскошь ровно до тех пор, пока проект не начинает расти.
Отдельно от этого страдает выбор технологий. К концу цепочки задача часто доходит без понимания, зачем вообще нужен тот или иной стек, и решение принимают не под задачу, а под исполнителя: берут то, что уже использовали на прошлых проектах, или то, что умеет конкретный человек, а не то, что подходит именно этому продукту. Такой выбор не учитывает нагрузку, будущие интеграции и рост продукта, потому что эти факторы просто не рассматривались, а это напрямую бьёт по тому, насколько легко систему можно будет дорабатывать и масштабировать дальше.
3. Разработка как испорченный телефон
Классическая игра в испорченный телефон работает по одному принципу: каждый участник передаёт следующему не то, что услышал, а то, что понял. При передаче проекта происходит то же самое, только ставки выше.
Заказчик формулирует бизнес-цель. Менеджер бренда пересказывает её в виде ТЗ. Субподрядчик читает ТЗ и достраивает пробелы своим пониманием. Разработчик в конце цепочки видит уже не задачу бизнеса, а чью-то интерпретацию интерпретации - и реализует именно её, вполне добросовестно.
Дальше начинается знакомый цикл: сдача - «это не то, что мы просили» - переделка - снова не то. Каждая такая итерация выглядит как обычный рабочий процесс, но на деле это цена утраченного контекста, а не сложности задачи.
4. Документация - первое, чем жертвуют
Документация не ускоряет сдачу текущего спринта, поэтому при экономии она пропадает в первую очередь: ни архитектурных решений, ни описания интеграций, ни причин, почему что-то сделано именно так, а не иначе. Отраслевые исследования причин провала IT-проектов из года в год ставят неполные требования и отсутствие нормальной документации в число ключевых факторов [2].
Пока с проектом работает тот же человек - это не создаёт проблем: всё держится у него в голове. Проблема наступает в двух случаях: команда меняется, или проект нужно передать кому-то ещё для развития.
5. Что получает следующая команда
Если проект нужно забрать у предыдущего исполнителя - для доработки, аудита или потому что сотрудничество закончилось, - новая команда сталкивается не с «продолжением работы», а с расследованием.
Ей приходится восстанавливать архитектурные решения по коду, потому что их никто не фиксировал. Разбираться, почему часть логики продублирована в трёх местах. Выяснять, какие поля в базе на самом деле используются, а какие остались от предыдущих версий. Проверять, есть ли вообще тесты, а если есть - можно ли им доверять.
Формально это называется «войти в проект». По факту это разработка с нуля, только на чужом, непрозрачном фундаменте - что почти всегда дороже, чем написать эту часть заново.
6. Почему это оказывается дороже, чем звучало на старте
Сценарий, который встречается на рынке чаще, чем хотелось бы:
Заказчик выбирает подрядчика с именем и разумной ценой.
Подрядчик передаёт проект дальше - частично или полностью, чтобы уложиться в бюджет и сохранить свою маржу.
Проект сдаётся, работает на демо, первая версия выглядит нормально.
Через полгода-год нужно добавить функциональность или исправить производительность - и выясняется, что документации нет, тесты формальные, а архитектура не предполагала того масштаба, который нужен сейчас.
Новая команда сначала должна разобраться в системе, прежде чем что-то менять - и это разбирательство заказчик тоже оплачивает.
По сумме выходит дороже, чем если бы изначально работала одна команда, отвечающая за результат от начала до конца.
По независимым оценкам, разработчики в среднем тратят около 42% рабочего времени на разбор технического долга и плохого кода вместо новых фич [3] - и это без учёта проектов, которые изначально писались без документации и архитектурного плана.
7. Что стоит спросить у подрядчика до подписания договора
Список вопросов, который стоит задать не для того, чтобы поймать кого-то на слове, а чтобы понять, с кем на самом деле предстоит работать:
Кто именно будет писать код - штатная команда компании или субподрядчик?
Можно ли познакомиться с людьми, которые будут вести проект, до старта работ?
Что произойдёт, если часть работ передадут другому исполнителю - предупредят ли об этом заранее?
Как устроена документация: архитектурные решения, схема данных, описание интеграций?
Что останется у заказчика, если сотрудничество прекратится - доступ к репозиторию, документация, знания?
Кто отвечает за качество, если задача фактически выполнена третьей стороной?
Если на эти вопросы отвечают уклончиво или переводят разговор обратно на список технологий - это тоже ответ.
8. Когда субподряд - это нормально
Здесь не идёт речь о том, что субподряд как явление вреден. Крупные интеграторы и агентства нередко привлекают узких специалистов на отдельные задачи - это стандартная практика, если она прозрачна.
Разница в том, прозрачна ли передача для заказчика, сохраняется ли ответственность и контроль качества у того, с кем подписан договор, и остаётся ли после привлечённого специалиста нормальная документация. Субподряд как усиление команды - это одно. Субподряд как способ выполнить обязательства чужими руками и по остаточному бюджету - совсем другое.
Вместо вывода
Перепродажа проекта вглубь цепочки экономит деньги ровно одной стороне - и только в моменте. Заказчик получает не то, за что платил: не команду, которую выбирал, а результат нескольких пересказов исходной задачи, собранный из того бюджета, что остался после каждой комиссии.
Дальше это оборачивается переделками, недокументированной системой и дорогим входом для любой команды, которая захочет продолжить проект - включая ту же компанию, если она решит вернуть разработку себе.
Поэтому мы стараемся строить работу иначе: с одной и той же командой от аналитики и архитектуры до релиза и сопровождения, без передачи задачи дальше по цепочке и с документацией, которая остаётся у заказчика в любом случае - даже если сотрудничество когда-нибудь закончится. Это не всегда самый дешёвый вариант на старте. Но именно это обычно и отличает подрядчика, которому можно передать production, от подрядчика, у которого его придётся забирать.
Источники и материалы
[1] Biz360.ru, «Разработчики для разработчиков: как устроен бизнес по модели аутсорс-продакшна»: https://biz360.ru/materials/razrabotchiki-dlyarazrabotchikov-kak-ustroen-biznes-po-modeli-autsors-prodakshna/
[2] Standish Group, CHAOS Report - обзор причин провала IT-проектов, включая неполные требования и недостаток документации: https://vc.ru/id1581393/2091456-pochemu-it-proekty-ne-uspevayut-prichiny-provalov
[3] Stripe, The Developer Coefficient (2018) - исследование о доле рабочего времени разработчиков, уходящей на технический долг и плохой код: https://stripe.com/files/reports/the-developer-coefficient.pdf
