[Перевод] Менеджер вашей команды — роутер или модератор?15.09.2021 23:47

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

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

• Роутер — выступает посредником в общении между командой разработки и бизнесом, передавая информацию туда и обратно;

• Модератор — наблюдает за прямым диалогом между командой разработки и бизнесом, подключаясь при необходимости.

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

Каждая стратегия имеет свои достоинства и недостатки.

Роутер

В режиме роутера менеджер пропускает общение между сторонами через себя. Это может быть удобно по ряду причин, но, как водится, есть и недостатки.

Достоинства:

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

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

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

Недостатки:

• Бутылочное горлышко. Если один человек пытается пропускать через себя рабочую коммуникацию нескольких других людей, то рано или поздно он оказывается «бутылочным горлышком». В терминах программистов мы по сути заменяем параллельную обработку в несколько потоков на однопоточную конкурентную, и это приводит к снижению пропускной способности;

• Эффект испорченного телефона. В любой коммуникации неизбежно существуют потери, два человека никогда не понимают друг друга на 100%. Если информация передается через посредника (в данном случае — менеджера), то эти потери умножаются, что порой сильно затрудняет взаимопонимание между участниками проекта;

• Единая точка отказа. Когда люди привыкают к тому, что вся коммуникация ведется через менеджера, даже его кратковременное отсутствие вызывает серьезные проблемы. Подменить менеджера, который заболел или собрался в отпуск, оказывается очень сложно, потому что он один сосредотачивает у себя все информационные нити проекта;

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

Модератор

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

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

Достоинства:

• Максимальная пропускная способность. Менеджер больше не является «бутылочным горлышком» — участники проекта общаются так часто и в том объеме, как им требуется;

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

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

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

Недостатки:

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

• Легко скатывается в хаос из-за приватных переговоров. Если у одного человека возникает какой-то вопрос к другому, то наиболее естественным его желанием будет написать, позвонить или же пойти поговорить с тем человеком напрямую. К сожалению, личные переговоры »1-на-1» сильно затрудняют менеджеру выполнение своей функции модератора и вносят хаос в работу всей команды. Возникает множество скрытых обсуждений и договоренностей, о которых другие участники команды не знают или же узнают слишком поздно, что регулярно приводит к переделкам, конфликтам и тормозит работу;

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

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

Опыт нашей компании

Мы в ivelum очень любим режим модератора — в таком режиме работают все наши команды по умолчанию. Чтобы это работало эффективно, мы стараемся придерживаться следующих правил:

1. Рабочие обсуждения в личных сообщениях не приветствуются. У каждой команды есть свой выделенный канал в Slack или несколько каналов, и мы настоятельно просим вести все письменные дискуссии по проекту или там, или в таск-треккере, или в других местах, куда имеет доступ вся команда. Личные сообщения — только для сугубо личных вопросов, но не для рядовых обсуждений по работе;

2. Безопасная атмосфера. Люди, особенно недавно пришедшие в компанию, могут стесняться задавать свои вопросы в публичных чатах и на общих митингах, а личные чаты мы при этом не приветствуем. Чтобы разрешить эту дилемму, мы стараемся создавать максимально комфортную и безопасную рабочую атмосферу. Сарказм в отношении коллег и подтрунивание над «глупыми» вопросами строго запрещены, и это модерируется. Картинки с котиками и мемасики в умеренных количествах — приветствуются. Любые политические дискуссии разрешены только в специальном канале #politics в Slack, в который люди могут заходить и покидать его по своему желанию;

3. После рабочих митингов стоит писать резюме. Краткая «выжимка» — что обсуждали и что решили, опубликованная в рабочем канале проекта, очень помогает всем участникам быть в курсе событий. Это старая и избитая рекомендация, но все равно люди продолжают забывать. Кто-то в команде должен следить за дисциплиной и вежливо напоминать писать резюме после митингов;

4. Убрать лишние ограничения доступа. Любые рабочие материалы (таск-трекеры, репозитории с кодом, вики, рабочие документы и прочее) должны быть по умолчанию доступны всем участникам проекта. Ограничения доступа могут быть, но для них должны быть понятные причины. Если явных причин нет — значит доступно всем, кто причастен к проекту.

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

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

Резюме

Как обычно, «серебряных пуль» не существует, у каждого варианта свои плюсы и минусы. Каждая команда, проект и ситуация уникальны: то, что хорошо работает для одного случая, может не подходить другому.

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

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