​​Этап 1. Подготовка к разделению команд.

Итак, о чем точно стоит позаботиться заранее:
1. Определить потребность разделения
2. Проработать принцип разделения, предназначение команд
3. Подготовить разработчиков
4. Определить предварительный состав команд
5. Позаботиться о процессах в будущих командах

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

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

В нашем случае потребность виднелась на горизонте года, две команды были обоснованы проектом, который мы пилили, и на масштабе 12 человек ребята сами стали жаловаться на количество контекстов и коммуникаций.

Принцип разделения — от продуктового направления

У нас был проект размером в год. В нём два больших направления: «Управление профилями» и «Использование мультипрофиля».

Вот это и стало основополагающим принципом: по доменным областям ответственности. Это было достаточно очевидным решением, которое поддержали продакты.

У вас может быть другой принцип. Например, выделение платформенной core-команды, чтобы делать долгосрочные технические улучшения и ускорять работу продуктовых команд. Для выделения такой команды может понадобиться сильно договариваться с продактами.

Подготовить разработчиков
Тут нужно на 1-1 и на общих встречах спрашивать у ребят, видят ли они проблемы в текущем составе, и как можно их решить.

Команда может быть консервативной: ребята сработались и не хотят терять связь друг с другом. Тогда они сами могут предложить концепт рабочих групп.

Здесь можно подсветить, что рабочие группы могут стать слаженными «подкомандами» и разделение случится само собой. Это тоже рабочий вариант, тогда вернуться к вопросу можно будет через квартал или полгода.

Определить состав команд

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

Это очень интересное составное уравнение с кучей переменных. Получился такой лонгрид, что решил вынести его в следующий пост.

===========================

В качестве иллюстрации к посту сделал MindMap подготовки к разделению. Картинка к посту получилась шакальная, поэтому вот ссылка на исходник в Miro.