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

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

Классическая история: компания выбирает подрядчика по портфолио, отзывам и внушительному сайту. Договор подписан, звучат правильные слова про full cycle, agile и выделенную команду. Первые недели всё идёт гладко - присылают план, макеты, демо.

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

Сама модель, когда одно агентство ищет под проект стороннего исполнителя, распространена и открыто описывается участниками рынка [1]. Проблема не в факте субподряда, а в том, что клиент часто о нём не знает.

1. Каждая передача - это не просто комиссия, это потеря контекста

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

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

Каждая передача - это не только маржа посредника. Это ещё и точка, где часть смысла задачи теряется безвозвратно.

2. На чём экономят, когда продают проект дальше

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

Первыми из бюджета обычно выпадают статьи, которые не видны на демо:

• аналитика и сбор требований - «и так всё понятно из брифа»;

• архитектурное проектирование - «начнём кодить, разберёмся по ходу»;

• тестирование - «прогоним руками перед сдачей»;

• документация - «код и так читаемый».

Каждая из этих статей выглядит как необязательная роскошь ровно до тех пор, пока проект не начинает расти.

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

3. Разработка как испорченный телефон

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

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

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

4. Документация - первое, чем жертвуют

Документация не ускоряет сдачу текущего спринта, поэтому при экономии она пропадает в первую очередь: ни архитектурных решений, ни описания интеграций, ни причин, почему что-то сделано именно так, а не иначе. Отраслевые исследования причин провала IT-проектов из года в год ставят неполные требования и отсутствие нормальной документации в число ключевых факторов [2].

Пока с проектом работает тот же человек - это не создаёт проблем: всё держится у него в голове. Проблема наступает в двух случаях: команда меняется, или проект нужно передать кому-то ещё для развития.

5. Что получает следующая команда

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

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

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

6. Почему это оказывается дороже, чем звучало на старте

Сценарий, который встречается на рынке чаще, чем хотелось бы:

1. Заказчик выбирает подрядчика с именем и разумной ценой.

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

3. Проект сдаётся, работает на демо, первая версия выглядит нормально.

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

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