Привет, Хабр! 

Меня зовут Александр Субботин, я руководитель отдела разработки Content AI.

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

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

С чего все начиналось

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

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

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

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

Иллюзии равноправия

Плоские команды только на первый взгляд кажутся равноправными. Даже если структура на бумаге остается плоской, нередко внутри существуют неформальные лидеры (CTO, Teamlead, PM, Head of Dev, лидер круга и пр.), которые по сути, выполняют управленческие функции, помогают организовывать работу и принимать решения.

Так случилось и у нас. Вдвоем с директором по продуктам мы, как «фигаро», бегали между командами, подстраховывая ребят в обсуждениях, выполняя помимо своих основных обязанностей еще и роль тимлида. 

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

Новая модель: три роли лидера

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

Поэтому я стал искать другие модели распределения менеджерских ролей в команде. В одном из постов в интернете наткнулся на описание трехролевой модели управления разработкой от компании Dodo Engineering. Вместо одной роли скрам-мастера или тимлида они ввели три: process lead, tech lead и people lead. Первый отвечал за процессы и достижение целей (например, помочь записать рекап встречи или выделить плюсы и минусы каждой точки зрения, провести голосование и пр.), второй — за техническое лидерство, а третий — за поддержание мотивационного духа в команде. 

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

Как выбирали лидеров

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

Сначала информировал команды о проблемах, объясняя, как они повлияют на достижение результатов. Затем общался с каждым членом команды один на один, спрашивал мнение о коллегах: кто мог бы взять на себя одну из трех ролей. По итогам one-to-one встреч готовил шорт-лист кандидатов, беседовал с каждым кандидатом лично, предлагая ему занять ту или иную менеджерскую позицию. Если человек отказывался от управленческих функций, я не настаивал. 

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

Если никто из разработки не был готов стать лидером, смотрел на смежные подразделения. Так в одной из команд, было всего два разработчика. Сначала я пытался убедить их разделить между собой менеджерские роли. Через полтора месяца стало ясно, что следить за процессами и мотивацией им неинтересно. Они предпочитали сосредоточиться на кодировании и улучшении продукта. После обсуждения решили, что роль process lead возьмет на себя тестировщик, который сам проявил заинтересованность. Такая рокировка улучшила динамику работы в команде, и обсуждения стали проходить легче.

«Что думает команда»?

Сергей Юдин, TechLead Tech Team Content AI — «В нашей команде я выполняю все три управленческие роли одновременно. Однако в группах с несколькими сильными лидерами обязанности process lead могут передаваться от одного разработчика к другому каждые две недели. Благодаря такому коллективному тимлидству удается избежать ненужных конфликтов и подчеркнуть авторитетность сотрудников. Самой сложной для меня стало освоение роли people lead. Считаю, что на этой позиции тимлиду необходимо  овладеть искусством убеждения и умением находить компромиссы. Даже самые мотивированные сотрудники иногда склонны к прокрастинации. Давление на них редко дает положительные результаты. Для меня стало вызовом научиться мотивировать людей без использования жестких методов управления».

Почему не сработали альтернативные подходы к распределению ролей

Многие  компании для решения похожих проблем  нанимают PM, скрам-мастеров или agile-коучей. Мы решили не идти по этому пути. Исходили из того, что если нанимать middle-специалиста, то ему сложно будет влиться в команды и фасилитировать технические обсуждения. На практике такие специалисты извне часто сталкиваются с трудностями, так как не понимают доменной области и задают много вопросов для восстановления контекста, что может только мешать работе команды. Причем для части обсуждений критически полезно, чтобы фасилитатор обладал всеми hard skills, позволяющими эффективно вести встречу. Считаем, что технические менеджеры сегодня скорее полезны в больших командах для улучшения кросс-командного взаимодействия или в крупных компаниях для поддержания стандартов взаимодействия и договоренностей.

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

Другие вызовы жизни по новым правилам

После перехода на иерархическую модель командное взаимодействие упростилось, но передо мной появились новые вызовы: обучение process lead навыкам фасилитации и распределение задач по разработке. 

Навыки фасилитации. Самое энергозатратное в обучении тимлидов для меня – это обучить навыкам фасилитации обсуждений. Модель ведения встречи фасилитатором очень зависит от контекста: важности проблемы, позиции сторон, насколько надо углублять и анализировать разные варианты и тд. 

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

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

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

Результаты и выводы

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

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

«Что думает команда»?

Максим Гуш, TechLead Engine Team Content AI — «Переход на новую структуру ролей действительно улучшил рабочую атмосферу. Когда несколько человек в команде работают над процессами и следят за их соблюдением, все идет гораздо эффективнее. Появилась возможность немного отдохнуть от организационной работы и вернуться к кодингу. Это снизило выгорание и эмоциональную нагрузку. Появился обмен опытом: наблюдая, как другие process lead вели спринты, стал замечать узкие места в своей работе.»

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

Послесловие…

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