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

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

О проведении этого опыта, его результатах и наших дальнейших планах по трансформации команд, читайте под катом.

Привет, Хабр! Меня зовут Анна Петухова, я лид одной из команд автоматизированного тестирования в МойОфис. Ниже я подробно расскажу, как мы пришли к созданию успешной системы деления команд.

Сразу уточню, что под командой я понимаю прежде всего группу сотрудников, объединённых общей целью либо конкретной экспертизой. В тестировании МойОфис мы не делимся по продуктовым направлениям, в этом смысле все команды остаются «универсальными бойцами», но в деятельности каждой команды присутствует определённая уникальность (например, есть такие направления, как рефакторинг, разработка внутренних инструментов, тесная работа с командой ручного тестирования и другие). И хотя речь далее пойдет об опыте конкретной технической группы, изложенные принципы и рекомендации могут быть полезны для команд различных специализаций.

Хронология

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

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

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

Модель команды по Такману

При трансформациях мы ориентировались на модель команды по Такману. Основная идея, которую вкладывал Брюс Такман в концепт модели команды еще в 1965 году, заключалась вот в чём: становление команды делится на четыре этапа:

• Формирование (Forming)

• Конфликты/Шторм (Storming)

• Нормализация (Norming)

• Производительность (Performing)

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

В контексте деления наши цели были следующие: максимально сократить этап шторма, быстро перейти к нормализации и в короткие сроки улучшить показатели производительности.

Как собрать команду

Итак, у нас есть одна большая команда, которая нуждается в разделении. Мы выделили несколько основных этапов трансформации, которые кажутся нам фундаментальными при старте новой команды. Безусловно, их можно декомпозировать на более мелкие шаги и/или адаптировать каждый шаг под конкретные условия.

Этапы трансформации:

1. Определение направления работы новой команды (может быть продуктовым или техническим).

   • Например, основным направлением одной из наших команд стал рефакторинг устаревших частей фреймворка;

   • Направлением ещё одной команды стала миграция с одного инструмента взаимодействия с приложением на другой.

2. Определение цели появления команды.

   • Пример цели: увеличение тестового покрытия.

3. Определение границ ответственности.

   • Помимо общей области ответственности, такой как автоматизация тест-кейсов, у каждой команды могут быть свои границы — например, затрагивающие взаимодействие с командой ручного тестирования

4. Определение процессов работы (внутренних и внешних).

   • Под внутренними процессами понимается набор регулярных встреч, планирование, процесс внутренней оценки задач, ход ретроспективы;

   • Под внешними — процесс межкомандного взаимодействия, верхнеуровнего планирования и взаимодействие с другими подразделениями вне автоматизации тестирования.

Ответив на все вопросы о целях, процессах, ответственности, мы впоследствии уже значительно сокращаем так называемый этап шторма.

После определения перечисленных четырёх пунктов, можно переходить к диалогу с членами команды.

Этапы диалога с командой

1. Проводим встречу 1-to-1 с каждым сотрудником большой команды. В разговоре стоит сделать акцент на возможные направления развития, без озвучивания конкретных планов по разделению. На данном этапе не стоит задавать односложных вопросов в духе «хочешь ли ты в новую команду?». Лучше сфокусироваться на зонах роста сотрудников. Также отмечу, что такие разговоры правильнее проводить не в формате переписки в мессенджере, а голосом. Если есть возможность встретиться лично, этим не стоит пренебрегать.

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

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

Принципы формирования состава команды

При формировании команд мы старались придерживаться принципов, которые сформулировал доктор Мередит Белбин.

М.Белбин выделяет в команде три ролевых направления и девять отдельных ролей.

Схематично их можно изобразить следующим образом.

Для нас важно, чтобы в команде оказался хотя бы один человек из каждого направления:

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

• Инженер, нацеленный на идеи, теоретические аспекты работы.

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

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

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

2. Стоит сохранять уже налаженные горизонтальные связи. Речь, к примеру, об условных «заместителях» в конкретных предметных областях. Скажем, за CI в команде обычно отвечает один инженер, но исторически он делит эту экспертизу с ещё одним инженером. Для продолжения эффективной коммуникации, этих сотрудников не стоит разделять.

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

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

5. Ментор и новичок не должны быть разделены в разные команды. (Пункт, разумеется, актуален для тех компаний, где менторство реализуется в принципе. У нас ментор назначается для каждого новичка на период онбординга, но и в дальнейшем он может оказывать поддержку своему подопечному.)

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

Правила проведения 1-to-1 на тему разделения команд

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

Если текущий руководитель объективно осознает высокую ценность инженера в новой команде, а инженер сомневается в верности принятого решения, есть несколько приемов, как аргументировать перевод сотрудника в другую команду:

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

2. Открытость и честность очень важны при разговоре на тему разделения. Важно не утаивать от сотрудника истиной мотивации. Если ценность инженера — в его опыте на проекте, понимании процессов, знании фреймворка, то это нужно подчеркнуть в разговоре.

3. Важно отметить, что все изменения происходят только для того, чтобы повысить общую производительность. Митингов станет меньше, синки будут короче, планирование станет более точным. Одни сплошные плюсы. А если итерация деления уже не первая и в прошлых итерациях эти улучшения действительно были заметны, будет здорово показать члену команды на живом примере повышение общей производительности.

4. Конечно, необходимо выслушать опасения сотрудника по поводу разделения в принципе (если таковые имеются) и по поводу конкретного перевода в другую команду. Понимание каждым членом команды происходящего только поспособствует более быстрой адаптации в новой команде.

5. Сфокусируйте внимание инженера на будущих задачах, на том, чем ему предстоит заниматься, чтобы сформировать понимание в контексте предназначения новой команды, её ценности.

6. Проводите такие встречи в максимально свободное от других созвонов время. Лучше выбрать середину спринта, когда дедлайны ещё далеко, каждый инженер занят своими задачами и готов воспринимать новую столь важную информацию.

Планы

Все принципы, описанные выше, мы использовали при первом делении команд. Впоследствии разделились еще несколько раз; сейчас на проекте работает четыре команды автоматизации. Мы не планируем останавливаться, команда растёт, и нас точно ждет ещё не одна трансформация: с текущими темпами найма нам нужно делиться ориентировочно раз в три месяца.

Результаты

Процесс деления команды оказался непростым: в нём задействовано множество людей, каждый со своим видением итогового результата, и не всегда их мнения совпадают. Но благодаря осознанному подходу, при разделении мы все же достигли определённых целей. Нам удалось минимизировать время на адаптацию новых команд, а также повысить производительность — причем буквально через спринт после разделения (то есть порядка двух недель ушло на адаптацию и этап шторма). При численном увеличении команды в четыре раза, для инженеров количество встреч не увеличилось. Время ежедневных синков было равно 20 минутам, когда отдел автоматизации насчитывал пять человек, — и та же продолжительность сохранилась при отделе автоматизации в 20 человек.

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

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

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

Надеюсь, изложенный выше опыт поможет быстро и продуктивно расти и вашим командам!