Почему малые команды выигрывают в скорости разработки

Три причины, которые работают без всякого AI

Когда объясняют, почему маленькая команда быстрее крупной, обычно останавливаются на одной фразе: меньше народу, значит меньше бюрократии. Верно, но слишком расплывчато, чтобы из этого следовало что-то практическое. На деле причин три, и они разного уровня.

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

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

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

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

Что меняется, когда в команде появляется агент

AI не создаёт эти три преимущества заново, он снимает потолок, в который маленькая команда раньше упиралась. Раньше маленькая команда была быстрой, но ограниченной по объёму, а крупная медленной, зато способной закрыть больше задач параллельно. Агент, который берёт на себя заметную часть рутинного объёма, сдвигает этот баланс: три человека с агентами каждый способны закрыть объём, для которого раньше реально требовалось человек десять.

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

Личный случай: Cruxly и Planio

У меня сейчас два продукта, оба фактически делаю один, и оба неплохо показывают, где это преимущество реально ощущается, а где нет. В Cruxly почти вся ценность продукта завязана на качество AI-функциональности, и агент в буквальном смысле пишет заметную часть кода, пока я формулирую задачи и ревьюю. Фичу, на которую в найме ушёл бы отдельный бэкенд-разработчик на пару недель, я закрываю сам за несколько дней, потому что весь объём чисто инженерный и хорошо специфицируемый.

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

Где преимущество перестаёт работать

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

Практический вывод из всего этого: маленькая команда с AI выигрывает не универсально, а в конкретном типе задач, где объём инженерной рутины большой, а число видов экспертизы, нужных одновременно, маленькое. Эти два параметра стоит прикинуть на старте: когда план уже забуксовал, разбираться в причинах дороже.

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