«А если мы просто возьмём больше разработчиков, уложимся к концу месяца?»

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

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

Привет, я Андрей Степанов, технический директор fuse8. Мы строим свою экспертизу на создании цифровых продуктов для бизнеса и делимся наработками через контент. В этом материале я хочу разобрать типичные ловушки, в которые команды попадают, раздувая штат; показать, какие конкретно решения реально сжимают сроки разработки цифровых продуктов и как организовать параллельную работу, не наращивая лишнюю координацию.

Миф о линейном ускорении: как это работает

Как выглядит главное заблуждение? Если больше людей будет участвовать в разработке, значит, все, что делается на проекте, можно будет распараллелить. Тогда срок разработки станет короче пропорционально количеству дополнительно привлеченных специалистов – что-то такое обычно строится в голове у тех, кто не знаком с реальным процессом разработки цифрового продукта. 

Как тогда выглядит реальный процесс? Чтобы не усложнять, можно представить себе постройку дома. Это процесс долгий и в нем есть задачи, которые действительно можно делать параллельно для сокращения сроков. Например, можно пригласить больше отделочников — стены покрасят (облицуют плиткой или обоями) быстрее: за условных два дня (вместо семи по очереди) можно будет сдать все комнаты. Но будут и процессы, которые нельзя делать одновременно. Например, не получится запараллелить заливку фундамента и разводку коммуникаций. Установку мебели вместе с укладкой пола на одной и той же площади вы тоже вряд ли организуете. И тут хоть триста специалистов зовите – быстрее дом в эксплуатацию не сдастся. 

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

• новый онбординг: опытные сотрудники отвлекаются от проектных задач, чтобы вводить новичков в контекст, на 2–4 недели скорость работы с обеих сторон падает;

• время на координацию возрастает: появляется больше созвонов, ревью, согласований, кто-то кого-то ждёт с правками или тестами;

• часть работ все еще нельзя распараллелить: архитектура, организация хранения данных, интеграции, и релизы идут по очереди — их скоростью управляют решения, а не количество рук;

• растет техдолг: новички чаще ошибаются, и нужно дополнительное время на исправление этих ошибок.

Потолок ускорения: как понять, насколько все-таки можно ускорить работу

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

Если доля параллелящейся работы — p, а людей (потоков) — N, то максимум ускорения S

S(N) = 1 / ((1 - p) + p / N)

А календарное время T с N людьми:

T(N) = T(1) * ((1 - p) + p / N)

Закон Амдаля даёт предел сокращения времени даже в идеальных условиях (без накладных расходов координации). В реальных проектах будет только хуже, не лучше.

Допустим, на нашем проекте мы можем запараллелить 70% работ (p = 0,7), а 1 разработчик у нас делает отведенную ему работу за 9 месяцев. Мы же хотим пригласить 9 разработчиков, предполагая, что они сделают все за 1 месяц. Тогда:

S(9) = 1 / ((1-0,7) + 0,7/9) ≈ 2,65

T(9) ≈ 9 мес / 2,65 ≈ 3,4 мес

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

Чтобы уложиться в 1 месяц при исходных 9 месяцах, нужно ускорение S=9. Получаем формулу 1/((1 - p)+p/9)=9  при которой p = 1. То есть для нужного результата 100% работ должны параллелиться, а в реальности так не бывает.

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

Что делать для ускорения работы вместо добавления рабочих рук

Как ни парадоксально, все меры, что будут описаны ниже, тоже потребуют времени на имплементацию. Но это инвестиция: однажды описанные правила и контрольные точки сработают не только на текущем проекте, а станут универсальным ускорителем для всей работы.

Шаг 0: сначала стоит понять, что там на самом деле тормозит

Частая история: заказчик приходит с просьбой «давайте расширим команду разработки», а выясняется, что релизы откладываются вовсе не из-за нехватки рук. Бывает, в разработку нечего отдавать: дизайн и аналитика буксуют; или, наоборот, материалов много, но они бесконечно дополняются («ещё вот это», «а давайте и это добавим»), и получается классический feature creep. Добавить людей в такой проект – только увеличить этот ворох ожидания.

Проверьте 4 вещи за полдня:

1. Есть ли что отдавать в разработку? На 2-3 недели вперед должны быть задачи с согласованным описанием и макетами. Если так не работает, то затык в дизайне или аналитике, а не в разработке.

2. Как много задач просто ждут решений? Если >50% задач висит в ожидании макета, доступа или согласования, найм новых разработчиков ничего вам не ускорит.

3. Можно ли быстро показать тестовую версию? Любой разработчик может самостоятельно настроить проект и задеплоить изменения на тестовый стенд за 10–15 минут. Если это не так, у вас тормозят среда разработки и практики DevOps.

4. Сколько длится проверка изменений? Код-ревью должно укладываться в часы; автотесты меньше часа, ручное тестирование – в один рабочий день. Если все происходит дольше, то создается узкое горлышко, которое также не исчезнет от расширения штата. 

Шаг первый: используйте готовые решения там, где это не вредит вашей уникальности

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

Можно унифицировать однотипные функции в уже написанном решении. Это тоже экономит время.

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

Шаг второй: фиксация контрактов в разумных пределах

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

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

Во-вторых, контракты взаимодействия команды. Еще один фактор снижения фоновой когнитивной нагрузки команды – дефинишены. «Definition of Ready» говорит, когда задачу можно брать в работу. «Definition of Done» говорит, когда задачу можно считать выполненной и закрывать. Благодаря этому мы меньше созваниваемся и реже спорим — правила заранее известны. Плюс всегда получаем понятный результат и не тратим время на лишние обсуждения.

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

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

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

Шаг третий: вертикальные срезы функциональности

«Вертикальный срез» — это маленький пользовательский сценарий, который проходит через нужные части системы и дает законченный результат. Это значит, что срез можно показать пользователю и получить конкретную обратную связь. В отличие от «слоёв» построения приложения (сначала вся логика, потом вся верстка, потом интеграции), для готовности среза не нужно ждать, пока соседний слой дозреет.

Если поделить решение на такие срезы, в рамках каждого из них можно будет флексить скоуп работ, если окажется, что время сильно поджимает, или другая фича оказалась для бизнеса более приоритетной. Подробнее о том, как этот скоуп флексить, читайте в статье про FFF. 

Чтобы превратить «мешок фич» в срезы, возьмите большой блок («оплата», «личный кабинет», «каталог») и разверните его на три–пять минимальных маршрутов. Пример с оплатой: первый срез – «оплата без сохранения карты и без промокодов, второй – «оплата с промокодом», третий – «оплата с сохранением карты», и, например, — «оплата подарочным сертификатом». Каждый срез содержит ровно столько UI, логики и интеграций, сколько нужно, чтобы закончить путь. 

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

Шаг четвертый: убираем лишнюю координацию

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

Поработать пригодится и над процессом код-ревью, если он нужен на проекте – это тоже стоит прояснить заранее. Процесс в целом должен быть максимально предсказуемым и регулярным: чек-лист критериев, понятные SLA, короткие очереди. Если дублирующиеся встречи пропадают, а ответы на типовые вопросы находятся в одном месте, вы снизили «налог координации» — это прямое ускорение без единого нового сотрудника.

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

Когда людей реально стоит добавлять, и как сделать это безопасно

Безболезненно расширить штат, тем самым увеличив скорость работы можно, когда у вас уже определены понятные правила игры и подготовлены самостоятельные (параллелящиеся) куски работы.

Для начала ответьте на вопрос: вы способны выдать новичку план на две недели вперед без оговорки вида «зависит от того, что сделают другие»?

Если да – отлично, тогда расширение команды действительно способно выиграть вам время, а не новые задержки. Но давайте подробнее.

Правила для каждого новичка

Тут оговоримся, что под «новичком» мы тут понимаем любого нового человека на проекте. Совершенно не важно, какого он грейда или специальности – правила, которые ниже, должны быть применимы к каждому новому сотруднику. 

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

Онбординг делайте коротким и предсказуемым по дням, а не «как получится». Подготовка проекта к онбордингу и удобный developer experience должны быть приоритетом. Условно, у каждого разработчика в голове должен быть собран следующий пазл:

• Я понимаю архитектуру приложения и все принципы написания кода - они понятно описаны.

• Я знаю как проверить и задеплоить изменения без ошибок, есть тестовые данные и тесты.

• Я понимаю функциональность продукта и то над чем надо  будет работать, информация понятно организована в одном месте.

• Проверка кода максимально автоматизирована - линтера, кодстайл, SAST, AI помощники настроены.

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

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

Дальнейшее расширение

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

Помимо количественного расширения, стоит всегда помнить и про качественное. Да, первое, что приходит на ум – увеличение числа рабочих рук. Но на практике замена части мидлов и джунов на сильных сеньоров на критических участках дает кратный эффект: прирост скорости в 3–4 раза именно по тем задачам, где раньше были недели согласований и переделок. 

Разница не только в опыте, но и в отношении к работе: «добросовестный исполнитель» в срочном и неопределенном проекте теряет темп — он избегает риска и ждет четких инструкций. А вот люди с майндсетом решателя проблем быстро находят опорные решения, берут ответственность, координируют соседей и двигают проект вперед, не создавая лишней суматохи.

Как понять, что перед вами именно «решатель», а не просто сильный исполнитель? Смотрите на наблюдаемые маркеры в работе и на собеседовании: 

• человек быстро формулирует план из нескольких шагов при неполных данных; 

• уточняет границы задачи и сам предлагает, что отложить, чтобы не тормозить релиз; 

• фиксирует договоренности; 

• не боится принимать обратимые решения и вовремя эскалирует необратимые; 

• держит прозрачность коммуникации, предсказуем для команды.

Мы на своих проектах убедились, что такие ребята на вес золота, поэтому стараемся растить их в команде. Подробнее об этом написал в статье про качества продуктового разработчика.

Для каждого расширения должны быть оговорены метрики успеха. Договоритесь о них, если усиление короткое, на два-три спринта. 

Для долговременных усилений обычно измеряют

• throughput  (поток выпускаемых задач), 

• lead time для изменений,

• частоту релизов,

• количество и критичность ошибок в проде.

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

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