В 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.
ссылка на оригинал статьи https://habr.com/ru/articles/1028714/