​​Как подобрать состав команд при разделении

Продолжаем цикл лонгридов про разделение команд. Первый пост тут.

В идеальном мире продуктовые разработчики самоорганизуются на две идеальные команды.
Но мы не в идеальном мире, и есть риск что составы получатся не оптимальные.

Здесь нужна помощь человека который соберет все-все-все контексты с ребят и предложит оптимальный вариант.

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

Давайте попробуем систематизировать

Нужно с помощью разработчиков ответить на ряд вопросов.
Это не исчерпывающий список, буду рад предложениям в комментах.

📌 — Какие навыки нужны команде, кто из разработчиков что умеет и в каком направлении хочет развиваться
Здесь поможет упражнение StarMap. Можно пройти его вместе с командой, а можно самому. Если проходить вместе, то рассчитывайте часа на 4 минимум. Дорого, зато у ребят появится командный артефакт, о котором они могут заботиться, и который может быть частью их самоидентификации. Если составлять индивидуально, вам всё равно придётся собирать информацию на 1-1, и суммарно времени потратите не меньше.

📌 — Кто какую роль занимает в команде сейчас и какую может занять в новой команде
Здесь можно идти по интуиции и личному впечатлению от ребят. А если есть желание системно подойти к вопросу — посоветую хороший сборник статей: Работа в команде — модели, теории, алгоритмы
В этом сборнике советую обратить внимание на профиль управления командой Маргерисона-Макканна. Чем-то похоже на модель Белбина, но расширяет её.

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

📌 — Кто с кем хочет работать
Здесь стоит учесть персональные связи участников. Не стоит разлучать ментора и менти. И наоборот: возможно, есть личная несовместимость между двумя разработчиками, и они не хотят друг с другом работать.

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

Приведу упрощенный пример нашего уравнения
Disclaimer: все имена вымышленные.

Вася — душа команды, уже взял на себя фича-драйвинг объемной фичи А, которая пойдёт в разработку в команду А.

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

Петя — ментор Антона, супер-эксперт. Задачи команды А для него будут скучноваты.

Костя — хороший интегратор, он фича-драйвер фичи Б, которая входит в скоуп команды Б. Фича Б — супер сложная и на ней нужен Петя.

Антон хочет работать с Васей и не хочет работать с Костей.

Допустим, есть еще несколько мидлов, которым не принципиально, с кем работать.

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

P.S. У нас было 12 разработчиков и 3-4 вот таких коллизий как у Антона. По итогу все решили, и спустя год ребята не хотят менять состав 🙂