В Agile и Scrum есть почти священная заповедь: команда должна быть стабильной, долгоживущей. Люди притираются друг к другу, учатся работать вместе, растёт доверие и предсказуемость.

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

Хайди Хелфанд, автор книги "Dynamic Reteaming: The Art and Wisdom of Changing Teams", проработавшая в AppFolio, ExpertCity и других компаниях, утверждает: изменение состава команды - это не проблема, а нормальный и правильный процесс, которым можно управлять. Она собрала реальные кейсы и показала, что пересборка команд даёт результаты, которых не может дать стабильная команда.

Что это вообще такое

Изменение состава команды - не катастрофа и не повод собирать экстренный созвон. По Хелфанд, это нормальный цикл: команда рождается, растёт, зреет, перестраивается. И вместо того чтобы цепляться за стабильность любой ценой, этим циклом можно управлять.

Стабильность - не цель. Это одно из состояний. Иногда полезное, иногда уже нет.

Когда команда слишком долго сидит в одном составе, начинаются характерные симптомы. Групповое мышление - мы всегда так делали, зачем менять. 

Один человек становится единственным, кто понимает какой-то кусок системы, и если он уйдёт в отпуск - всё встанет, люди перестают расти, начинается рутина, потом выгорание.

Пересборка не отменяет стабильность. Стабильность хороша, пока работает, а когда перестала - пересобирай.

Пять паттернов пересборки

Хелфанд выделяет пять базовых способов изменить состав команды. Это строительные блоки - можно использовать по отдельности, можно комбинировать.

По одному (One by One)

Самый обычный случай. В команду пришёл новый человек. Или ушёл старый.

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

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

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

Рост и разделение (Grow and Split)

Команда разрослась. Было 5, стало 11. Координация стала дорогой, совещания - длинными, скорость просела.

Надо разделить на две команды. Каждая со своим фокусом и зоной ответственности, стандарт масштабирования.

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

Хелфанд подчёркивает: здесь критически важна коммуникация. Не "менеджмент решил", а "мы выросли, и чтобы каждый мог двигаться быстрее - нужно два фокуса вместо одного". Люди не дураки, они поймут, если объяснить

Слияние (Merging)

Обратное: несколько команд сливают в одну. Бывает при реорганизации, поглощении или когда два продукта объединяются.

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

Единственный нормальный путь - строить новые договорённости вместе. Не навязывать культуру одной команды другой, а создавать общую с нуля.

Ротация (Switching)

Люди меняются местами между командами. Разработчик из команды А идёт в команду Б, кто-то из Б - в А.

По наблюдениям Хелфанд, ротация бьёт сразу по трём мишеням. Первая - знания расползаются по компании вместе с людьми. Вторая - ломается застой: новый контекст, новые задачи, новые люди дают энергию. Третья - люди растут. Другой домен, другой стек, другая роль - такого не получишь, сидя на одном месте три года.

Изоляция (Isolation)

Из существующих команд вырезают маленькую группу под что-то новое. Новый продукт, эксперимент, прототип.

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

В AppFolio так появился продукт SecureDocs. Вытащили несколько человек, дали свободу - они сделали продукт, который в общем потоке увяз бы и умер.

Хелфанд приводит аналогию из фастфуда: Chicken McNuggets в McDonald's появились не потому, что вся компания перестроилась, а потому что маленькой группе дали пространство для эксперимента.

Зачем вообще пересобирать

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

Борьба с групповым мышлением. Команда год в одном составе - начинает мыслить одинаково. Не потому что плохие люди. Просто так работает психология. Новый человек заходит и спрашивает "а зачем вы это делаете" - и иногда хорошего ответа нет. Этот дискомфорт полезен.

Рост людей. Разработчик три года пишет один сервис - расти некуда. Новая команда, другой домен - и через полгода это другой специалист. По данным Хелфанд, люди реже увольняются, когда чувствуют, что развиваются.

Перезагрузка. Рутина выжигает. Новые задачи, новый контекст, новые коллеги - это как переезд в другой город, только без коробок.

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

Минусы

Скорость просядет. Любая смена состава - это заново притирка, вход в контекст, выстраивание отношений. 4-8 недель команда будет медленнее. Это нужно закладывать.

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

Людям тревожно. Не все любят перемены. Для кого-то новая команда - стресс. А если ещё и не объяснили зачем - стресс в квадрате. Люди додумывают, что их перетасовывают, потому что руководство недовольно, или какое-нибудь скрытое сокращение.

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

Хаос при бездумном подходе. Пересборка без плана и без коммуникации - не инструмент, а бардак.

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

Пусть люди решают сами

Из всех способов провести пересборку, один стоит выделить. Самовыбор (self-selection) - подход, при котором люди сами выбирают, в какую команду идти. Не руководство назначает и не HR рисует стрелочки.

Самый зрелый пример - Redgate Software. Они проводят самовыбор каждый год, уже больше пяти лет подряд. 25-35% инженеров добровольно меняют команду, остальные остаются.

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

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

Подходящие моменты для самовыбора:

• Ежегодное или полугодовое планирование

• Масштабирование - команды делятся

• Реорганизация под новые цели

• Необходимость размешать знания между командами

• Создание новой команды под эксперимент

Оптимальная частота - раз в 6-12 месяцев. Чаще - слишком много стресса, реже - эффект теряется.

Как провести самовыбор

За 3-6 недель

Договорённость с руководством. Технический директор, продуктовые лидеры, тимлиды - все в курсе и понимают зачем.

Карта будущих команд. Какие продукты, какие потоки ценности в следующем периоде. Для каждой команды - короткое описание: миссия, ключевые задачи, примеры из бэклога, нужные навыки.

Рамки.

• Размер команды: 5-9 человек

• Обязательные навыки: "минимум 2 опытных бэкенда" или "нужен человек с опытом пользовательских исследований"

• Географические ограничения для распределённых команд

Материалы. Постеры или доски для каждой команды. Карточки участников - каждый пишет: что умею, что хочу изучить, чему могу научить. Хелфанд называет это "ярмарка навыков" - помогает людям увидеть друг друга заново.

В день события

Открытие (30-45 минут). Стратегия компании, развитие людей, распространение знаний. План дня. Чек-ин: как люди себя чувствуют. Тревога - нормальная реакция, прятать её не надо.

Презентация команд. Лидер каждой будущей команды за 5-10 минут рассказывает: миссия, задачи, нужные навыки. Участники задают вопросы.

Раунды самовыбора. Люди подходят к доскам и записываются.

После первого раунда - пауза и оценка:

• Хватает ли навыков в каждой команде

• Нет ли перекосов по численности

• Есть ли критические дыры

Лидеры озвучивают проблемы, но без давления на конкретных людей. "В команде Б пока нет никого с опытом инфраструктуры" - нормально. "Вася, иди в команду Б" - уже не самовыбор.

Обычно 2-3 раунда - и картина стабилизируется.

Завершение. Фиксация состава. Короткая ретроспектива. И обязательно - отметить событие. Люди прошли через эмоционально непростой процесс. Пицца, торт, пиво - для закрепления позитивного настроя.

После

Ввод в новые команды. К каждому новичку - напарник. Совместная работа в первые недели. Ретроспектива "история команды" - чтобы новички поняли контекст, а не изобретали велосипеды.

Внимание к тем, кто не попал в желаемую команду.

Проверка через 1-2 месяца. Здоровье команд, ретроспективы, разговоры один на один.

Примеры

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

Pirate Ship Software. Рост с 20 до 30 разработчиков. Переход от 3 перегруженных команд к 6 сфокусированным.

Redgate Software. Самовыбор каждый год, больше пяти лет подряд. 25-35% меняют команду. Проводили и полностью удалённо - через Miro и видеозвонки.

Spotify. Ротация внутри подразделений. Не чистый самовыбор, но принцип тот же.

Если Вам понравилась данная статья, то приглашаю в свой Telegram канал "На Дерево". Делюсь разными мыслями, идеями и инсайтами из мира IT.