О чем подумать при разделении команды

Митоз клетки команды

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

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

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

- команда формируется на базе какого-то человека из "старой" команды. 

- N новых команд получаются в результате разделения "старой".

Мне, чаще всего, приходилось заниматься третьим вариантом, поэтому ниже немного вопросов/тезисов, про которые надо подумать при разделении команд:

Если делиться, то как? Это все влияет на новые процессы работы и их формат

- функционально (у каждой команды свой кусок функциональности, свой бэклог и код).

- кроссфункционально (беклог остается общим, команды работают над одной кодовой базой). 

Как делить людей (кого в какую команду)? 

По желанию, "насильно", будет ли возможность перехода между новыми командами. У меня в опыте были все эти варианты. Каких ролей не хватает в новых командах и какой план по закрытию потребности в них.

Код, скорее всего, сейчас общий, что дальше?

- остаемся в одном репозитории: кто в итоге "владелец кода" и какие правила работы с ним?

- если репу/репы нужно таки разделять репу/репы, то как, сколько может занять?

Тот же вопрос по тест-кейсы и прочие артефакты разработки.

Что с каналами коммуникаций? 

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

Кто ответственен за внешние запросы в команду/команды и обработку мониторинговых алертов, если разделение кода/сервисов не произошло?

Какая из команд, в каком порядке, за что именно отвечает?

К чему нужно быть готовым?

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

- персональная неудовлетворенность некоторых членов команд.

Советы от КО:

- Обратиться за опытом к коллегам. Скорее всего кто-то из коллег или знакомых уже огребал от разделений сталкивался с этим вопросом и готов поделиться с вами своими опытом и попоболями.

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

- Посмотреть Why Your Software Team CAN’T Scale.

- Учесть, что уже есть применяемые многими процессы для организации совместной работы команд (Nexus, LeSS). Возможно не нужно придумывать свои "велосипеды".

- в комментах в тви подкинули интересную концепцию по этой теме: "Dynamic Reteaming". По описанию очень укладывается в обсуждаемый тут вопрос.