Хотим сделать вот эти вот фичи, очень надо. Давайте наймём х2 разработчиков или пускай вот эта соседняя команда вам поможет.

Увы, но команды и продукт таким образом не масштабируются.

📈 При добавлении новых людей в команду увеличивается число каналов коммуникации между ними. Чем больше каналов, тем сложнее координация работы. А усложнение координации приводит к постепенному замедлению команды.

Именно этим обусловлено правило “двух пицц” в Amazon при формировании команды.

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

🤷‍♂️ При этом команды моментально потеряют видение целостной картинки продукта, т.к. правки одной команды не будут известны другой.

🏆 Основной фактор повышения эффективности работы команды — это сокращение временны́х издержек. В первую очередь времени простоя и ожидания, когда инженер или задача просто чего-то ждут.

Например, время релиза фичи на тестовый стенд, или время нахождения задачи в статусе Ready for Code Review, или время работы автотестов в CI, или др.

🏎️ Сокращая такие издержки, мы напрямую влияем на уменьшение Cycle Time. Благодаря этому задачи завершаются быстрее, и мы можем увидеть результат раньше.

🔥 Ведь этого мы и жаждем, когда говорим про "сделать быстрее" - получить результаты раньше.

Ещё больше практик для ускорения разработки в моей статье на Zen Hills: https://zenhills.ru/articles/speedup-engineering/setka

#найм #тимлид #руководитель #процессы