Менеджер вашей команды — роутер или модератор?

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

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

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

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

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

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

Роутер

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

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

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

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

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

Недостатки:

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

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

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

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

Модератор

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
А как менеджер работает в вашей команде?
100% В режиме «роутера» 1
0% В режиме «модератора» 0
0% Свой вариант (напишите в комментариях) 0
Проголосовал 1 пользователь. Воздержались 0 пользователей.
Источник: https://habr.com/ru/post/578168/

Интересные статьи

Интересные статьи

Ожидание окончено. Вышла официальная версия 1Password для Linux. Поддержка Linux, несомненно, была наиболее востребованной возможностью 1Password. Все мы, те, кто работает над 1Passwor...
Вертикальный рост для разработчика не всегда дается легко. В этой статье я поделюсь своей историей и проблемами, с которыми я столкнулась, размышлениями о причинах этих проблем и о том, к...
Управление продуктом, проектом или командой – состоит не только из судьбоносных стратегических решений. Есть ещё и регулярный менеджмент.Это та необходимая рутина, без ко...
Вам приходилось сталкиваться с ситуацией, когда сайт или портал Битрикс24 недоступен, потому что на диске неожиданно закончилось место? Да, последний бэкап съел все место на диске в самый неподходящий...
Как широко известно, с 1 января 2017 года наступает три важных события в жизни интернет-магазинов.