В 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.