О чем подумать при разделении команды
(Из ленты Чудес не бывает или я ошибаюсь?)
 |
| Митоз |
Если продукт или набор сервисов, которым занимается команда, успешно развивается, задач становится все больше, размер команды растет, рано или поздно вы приходите к мысли о трансформировании команды в несколько команд.
Иногда это происходит «органически» — в продукте есть свободно отделяемая часть, которую можно передать новой команде. Иногда все сложнее — продукт разделить тяжело и само разделение драйвится тем, что просто людей становится много (или нужно больше) и текущие процессы становятся неэффективными, а результат работы сложно прогнозируемым.
Я наблюдал 3 варианта «рождения» новой дополнительной команды для существующих задач (речь здесь и дальше не про запуск нового продукта, а про дополнительный импульс в развитии существующего):
— команда формируется с нуля. Самый сложный вариант, который скорее всего подойдет, когда процесс работы уже заточен под «многокомандность» и новая команда — это лишь еще одна шестеренка в настроенной машине успешно перемалывающей бэклог задач.
— команда формируется с нуля. Самый сложный вариант, который скорее всего подойдет, когда процесс работы уже заточен под «многокомандность» и новая команда — это лишь еще одна шестеренка в настроенной машине успешно перемалывающей бэклог задач.
— команда формируется на базе какого-то человека из «старой» команды.
— N новых команд получаются в результате разделения «старой».
Мне, чаще всего, приходилось заниматься третьим вариантом, поэтому ниже немного вопросов/тезисов, про которые надо подумать при разделении команд:
Если делиться, то как? Это все влияет на новые процессы работы и их формат
— функционально (у каждой команды свой кусок функциональности, свой бэклог и код).
— кроссфункционально (беклог остается общим, команды работают над одной кодовой базой).
Как делить людей (кого в какую команду)?
По желанию, «насильно», будет ли возможность перехода между новыми командами. У меня в опыте были все эти варианты. Каких ролей не хватает в новых командах и какой план по закрытию потребности в них.
Код, скорее всего, сейчас общий, что дальше?
— остаемся в одном репозитории: кто в итоге «владелец кода» и какие правила работы с ним?
— если репу/репы нужно таки разделять репу/репы, то как, сколько может занять?
Тот же вопрос по тест-кейсы и прочие артефакты разработки.
Что с каналами коммуникаций?
Обычно у команды есть один канал для внешних запросов и нужно в первую очередь подумать, как он будет функционировать дальше, будут ли создаваться новые каналы для новых команд, как про это узнают все заинтересованные.
Кто ответственен за внешние запросы в команду/команды и обработку мониторинговых алертов, если разделение кода/сервисов не произошло?
Какая из команд, в каком порядке, за что именно отвечает?
К чему нужно быть готовым?
— шторминг команд. Даже если люди давно работали в одной старой команде, есть большая вероятность, что новую все равно поштормит.
— персональная неудовлетворенность некоторых членов команд.
Советы от КО:
— Обратиться за опытом к коллегам. Скорее всего кто-то из коллег или знакомых уже огребал от разделений сталкивался с этим вопросом и готов поделиться с вами своими опытом и попоболями.
— Концепт топологии команды на команды/группы . Кстати, возможно, ваш вариант не отдельные команды, а рабочие группы в рамках одной команды.
— Посмотреть Why Your Software Team CAN’T Scale.