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

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

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

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

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

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

Роутер

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

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

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

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

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

Недостатки:

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

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

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

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

Модератор

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

Комментарии (19)


  1. anonymous
    00.00.0000 00:00


    1. alexEtse
      16.09.2021 02:08

      Ну не скажи... Дурак-начальник любую работу завалить сможет, конечно, никакая схема взаимодействия не поможет.

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

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


  1. anonymous
    00.00.0000 00:00


  1. alexEtse
    16.09.2021 18:16

    Да, смесь. Как минимум одно дело, когда общение идёт внутри организации (тут в первом случае больше вреда от испорченного телефона), другое - с внешними участниками (тут уже смотря с кем, но с некоторыми такими участниками точно надо очень внимательно подбирать слова, а потому лучше пропускать такое общение через менеджера).


  1. anonymous
    00.00.0000 00:00


  1. alexEtse
    17.09.2021 00:58

    И как ты предлагаешь его починить, PM'а, если инфа теряется где-то в нём (ну или тормозиться на нём - ты говоришь ему, он передаёт это другому, другой что-то в ответ ему, он транслирует сказанное тебе, и так далее)? Да, иногда доходило до того, что подрядчики начинали друг с другом общаться напрямую из-за этого, видел такое.


  1. Alente1
    16.09.2021 10:33

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

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


    1. stebunovd Автор
      16.09.2021 10:57

      Отличные вопросы :)

      Чат - важное средство общения, но вовсе не единственное. Хранить детали конкретных задач в чате конечно же неудобно, они легко теряются, поэтому для задач есть таск-треккеры. Таск-треккеры, кстати, часто интегрированы с чатом, чтобы в чате был виден весь поток информации. Некоторые вещи бывает удобно оформить не в виде задачи, а в виде общедоступного документа, например в Notion, Confluence, или где-то еще.

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

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


  1. ruomserg
    16.09.2021 15:57
    +1

    Я не понимаю, когда разработчики тогда успевают работать? Если каждый человек любой свой вопрос пишет в общий чат группы — это ж будет постоянный трень-брень уведомлений в каналах, нет? А если разработчик не смотрит постоянно канал — тогда нет обратной связи…


    1. stebunovd Автор
      16.09.2021 19:16

      Уведомления настраиваются. Рекомендуемая у нас настройка - уведомления включены для упоминаний человека через @ (в том числе личные сообщения) и отключены для постов в общие каналы. Таким образом, достигается баланс - канал можно и нужно читать в асинхронном режиме, открывая его когда удобно, и вся команда по умолчанию так и делает. Однако, если вопрос срочный, то всегда можно привлечь внимание нужного человека упомянув его через @.


      1. ruomserg
        17.09.2021 06:46

        Я пытаюсь понять логику этого решения, но пока не могу. Итак, мы сначала заставили всех писать все вопросы в общий чат. Теперь мы отключаем уведомления из общего чата (потому что там бардак), и включаем только для «позвать через @». Теперь ситуация почти не отличается от личных сообщений, но сообщения все-равно летят в кучу общего чата. Я предполагаю, что через какое-то время разработчики будут игнорировать все, что не помечено их именем, а задающие вопросы начнут звать через "@" всех подряд, чтобы хоть кто-то ответил. После этого активные разработчики отключат и это уведомление тоже, чтобы хоть как-то работать.

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

        Кроме того, я так и не понимаю — откуда разработчики берут время, чтобы разгребать простыню общего чата и выцеплять вопросы, которые не помечены их именем но на которые они знают ответ? Обычно, разработчик заканчивает одну задачу, и у него всегда есть следующая. У вас не так? Или вы выделяете прямо норму рабочего времени на разбор чата?

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

        P.S. У меня, также, есть теория, что разумные электронные способы коммуникации должны оставаться разумными при переносе из виртуала в реал. Так вот, вы предлагаете посадить всех разработчиков в опенспейс, и каждый раз когда кому-то надо кого-то о чем-то спросить — он не «подходит и тихонько спрашивает», а громогласно озвучивает свой вопрос, чтобы его слышали все присутствующие. И ответ ему доводят тоже по громкой связи, чтобы все в комнате на всякий случай получили эту информацию. Но это же шиза, и ровно противоположно рекомендуемым методам коммуникаций в офисе… Следовательно…


        1. stebunovd Автор
          17.09.2021 09:57

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

          Разумеется, мы понимаем что чтение чата занимает время, и считаем это важной частью работы. Только по опыту, это далеко не так много времени, как может показаться с непривычки. Чтение Хабра, к примеру, занимает гораздо больше времени :)

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


          1. ruomserg
            17.09.2021 10:17

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

            В общем понятно — разработчики берут время «откуда-то» (менее вежливый вариант, видимо звучит: «проблемы негров — шерифа не волнуют». :-)

            И все-таки, я так и не понял — в чем преимущество перед более традиционной системой? Дело в том, что менеджер — это не binary switch чтобы находиться в одном из выбранных режимов коммуникации. В традиционной системе — менеджер сначала организует коммуникацию (естественно, пропуская ее через себя). Потом, убедившись что коммуникация эффективна — отпускает исполнителей договариваться между собой, обеспечивая возможность быть в теме того, о чем они договариваются (технические способы разные: записи встреч, meeting minutes, разговор с человеком, и т.д.). Если в коммуникации возникла проблема (прямо ли об этом заявлено или он определил по косвенным признакам) — менеджер подключается и исправляет ситуацию (вплоть до того, что прерывает ее и забирает вопрос себе).

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


            1. stebunovd Автор
              17.09.2021 10:25

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

              That said, это конечно мое частное мнение и мой опыт. У вас разумеется свой опыт, и наверное в вашем опыте вещи выглядят иначе.


              1. ruomserg
                17.09.2021 10:49

                Я бы сказал, что «загнать всех в общий чат» и «обеспечить эффективную работу» — это разные цели, и в большинстве случаев — противоречащие друг-другу. И люди, которые эффективно работают — в общий чат не очень хотят…

                Ну а дальше, традиционное: "- А от окопа до препятствия ползите зиг-зугом! // Зиг-загом, товарищ майор! // Как я скажу — так и поползете!".


      1. alexEtse
        18.09.2021 00:43

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

        а если нескольким людям приспичило одновременно пообщаться по разным вопросам - что делаете с кашей из их переписки в общем чате?.. Не всегда комфортно в потоке вычленять сообщения из "твоего" разговора, а если один человек сразу в двух p2p диалогах - еще и запутаться можно...


        1. stebunovd Автор
          18.09.2021 01:21

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

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


          1. alexEtse
            18.09.2021 03:50

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


  1. Bro_nina
    18.09.2021 23:37

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

    Для сложных и больших проектов работает безотказно