Подавляющему большинству команд разработчиков так или иначе нужно выстраивать общение с представителями бизнеса или стейкхолдерами. В этой статье мы рассмотрим два наиболее часто встречающихся паттерна такого общения, перечислим достоинства и недостатки каждого варианта, и поделимся собственным опытом.
Как правило, в организации есть выделенный человек, отвечающий за взаимодействие команды разработки с бизнесом. Для простоты в контексте этой статьи будем называть его “менеджером” (в реальной жизни он может называться по-разному — менеджер проекта, тимлид, бизнес-аналитик или как-то еще). У него есть два основных режима работы:
Роутер - выступает посредником в общении между командой разработки и бизнесом, передавая информацию туда и обратно;
Модератор - наблюдает за прямым диалогом между командой разработки и бизнесом, подключаясь при необходимости.
Эффективную работу в режиме модератора выстроить сложнее, но при правильной организации она может обеспечить более высокую пропускную способность, минимизировать задержки и недопонимания.
Каждая стратегия имеет свои достоинства и недостатки.
Роутер
В режиме роутера менеджер пропускает общение между сторонами через себя. Это может быть удобно по ряду причин, но, как водится, есть и недостатки.
Достоинства:
Проще ориентироваться. Ни разработчикам, ни стейкхолдерам не надо думать, к кому обратиться с тем или иным вопросом. Если менеджер отвечает за коммуникацию, то очевидно, что сначала к нему, а дальше уже он разберется;
Проще организовать. Коммуникация — это навык, который далеко не у всех людей хорошо развит. Некоторым бывает сложно сформулировать свою мысль, другие просто не любят общаться или же не умеют делать это конструктивно. Найти одного человека с хорошей коммуникацией проще, чем пытаться развивать навыки коммуникации у всей команды;
Надежный способ держать все под контролем. Менеджер, работающий в таком режиме, так или иначе будет в курсе почти всех деталей, что помогает ему следить, чтобы проект получился цельным и непротиворечивым и следовал согласно плану.
Недостатки:
Бутылочное горлышко. Если один человек пытается пропускать через себя рабочую коммуникацию нескольких других людей, то рано или поздно он оказывается “бутылочным горлышком”. В терминах программистов мы по сути заменяем параллельную обработку в несколько потоков на однопоточную конкурентную, и это приводит к снижению пропускной способности;
Эффект испорченного телефона. В любой коммуникации неизбежно существуют потери, два человека никогда не понимают друг друга на 100%. Если информация передается через посредника (в данном случае — менеджера), то эти потери умножаются, что порой сильно затрудняет взаимопонимание между участниками проекта;
Единая точка отказа. Когда люди привыкают к тому, что вся коммуникация ведется через менеджера, даже его кратковременное отсутствие вызывает серьезные проблемы. Подменить менеджера, который заболел или собрался в отпуск, оказывается очень сложно, потому что он один сосредотачивает у себя все информационные нити проекта;
Плохо справляется со сложностью. Когда проект большой и сложный, один человек, даже очень талантливый, в какой-то момент оказывается не в состоянии удержать все важные детали в голове и при этом еще и следить за новостями. Как результат, это усугубляет все вышеперечисленные проблемы.
Модератор
Альтернативный вариант — прямая модерируемая коммуникация между всеми участниками проекта. Все могут общаться между собой напрямую и это всячески поощряется. Менеджер при этом может присутствовать в качестве помощника или наблюдателя. Его могут попросить подключиться к любому диалогу, или же он может подключиться сам, если увидит, что нужна его помощь.
Этот вариант избавлен от недостатков режима роутера, но требует большей организационной дисциплины и усилий по внедрению.
Достоинства:
Максимальная пропускная способность. Менеджер больше не является “бутылочным горлышком” — участники проекта общаются так часто и в том объеме, как им требуется;
Минимизация искажений. Когда люди лично присутствуют при обсуждениях, они получают гораздо более полную информацию, нежели чем в пересказе, и могут сразу задавать уточняющие вопросы и получать ответы на них из первых уст;
Улучшенная отказоустойчивость. Поскольку участие менеджера больше не является непременным условием общения между разработчиками и стейкхолдерами, команда может легче пережить его временное отсутствие;
Открытость стимулирует креатив в команде. Во все времена свободный обмен знаниями способствовал прогрессу и более быстрому развитию. В данной модели люди получают информацию из большего количества источников, что способствует генерации новых идей.
Недостатки:
От всей команды ожидается умение конструктивно общаться. Повышаются требования к подбору людей в команду, увеличивается вероятность рабочих конфликтов, менеджеру добавляется роль коуча по продуктивной коммуникации, что повышает требования и к самому менеджеру;
Легко скатывается в хаос из-за приватных переговоров. Если у одного человека возникает какой-то вопрос к другому, то наиболее естественным его желанием будет написать, позвонить или же пойти поговорить с тем человеком напрямую. К сожалению, личные переговоры “1-на-1” сильно затрудняют менеджеру выполнение своей функции модератора и вносят хаос в работу всей команды. Возникает множество скрытых обсуждений и договоренностей, о которых другие участники команды не знают или же узнают слишком поздно, что регулярно приводит к переделкам, конфликтам и тормозит работу;
Требует повышенной командной дисциплины. Для эффективной работы такого варианта всем членам команды приходится прилагать дополнительные усилия. Чуть ниже я приведу примеры из опыта нашей компании, что это может означать на практике;
Может требовать преодоления социальной инерции. Для некоторых команд и людей, не привыкших работать в таком режиме, это будет означать ломание годами сложившихся привычек, и далеко не все к этому готовы.
Опыт нашей компании
Мы в ivelum очень любим режим модератора — в таком режиме работают все наши команды по умолчанию. Чтобы это работало эффективно, мы стараемся придерживаться следующих правил:
Рабочие обсуждения в личных сообщениях не приветствуются. У каждой команды есть свой выделенный канал в Slack или несколько каналов, и мы настоятельно просим вести все письменные дискуссии по проекту или там, или в таск-треккере, или в других местах, куда имеет доступ вся команда. Личные сообщения — только для сугубо личных вопросов, но не для рядовых обсуждений по работе;
Безопасная атмосфера. Люди, особенно недавно пришедшие в компанию, могут стесняться задавать свои вопросы в публичных чатах и на общих митингах, а личные чаты мы при этом не приветствуем. Чтобы разрешить эту дилемму, мы стараемся создавать максимально комфортную и безопасную рабочую атмосферу. Сарказм в отношении коллег и подтрунивание над “глупыми” вопросами строго запрещены, и это модерируется. Картинки с котиками и мемасики в умеренных количествах — приветствуются. Любые политические дискуссии разрешены только в специальном канале #politics в Slack, в который люди могут заходить и покидать его по своему желанию;
После рабочих митингов стоит писать резюме. Краткая “выжимка” — что обсуждали и что решили, опубликованная в рабочем канале проекта, очень помогает всем участникам быть в курсе событий. Это старая и избитая рекомендация, но все равно люди продолжают забывать. Кто-то в команде должен следить за дисциплиной и вежливо напоминать писать резюме после митингов;
Убрать лишние ограничения доступа. Любые рабочие материалы (таск-трекеры, репозитории с кодом, вики, рабочие документы и прочее) должны быть по умолчанию доступны всем участникам проекта. Ограничения доступа могут быть, но для них должны быть понятные причины. Если явных причин нет — значит доступно всем, кто причастен к проекту.
По опыту, адаптация нового сотрудника к нашему стилю общения обычно занимает не больше нескольких недель. Некоторые чувствуют себя уверенно прямо с первого дня, другим нужно побольше времени, и мы стараемся отнестись к этому с пониманием и максимально поддержать адаптацию.
Однако даже и у нас иногда (но правда редко) встречаются ситуации, когда менеджеру или тимлиду приходится временно включать режим роутера. Как правило, это ситуации когда команде нужно взаимодействовать с новым человеком извне, который уже привык к такому стилю общения, и попытка адаптации в его случае выглядит нецелесообразной. Еще одно достойное упоминания исключение — взаимодействие с пользователями наших продуктов. Если они докладывают нам о проблеме, или же им нужна консультация, они редко когда хотят разговаривать с множеством людей, и мы стараемся уважать это.
Резюме
Как обычно, “серебряных пуль” не существует, у каждого варианта свои плюсы и минусы. Каждая команда, проект и ситуация уникальны: то, что хорошо работает для одного случая, может не подходить другому.
Очевидно, при росте сложности проекта режим роутера становится все сложнее и сложнее поддерживать. В то же время, для работы в режиме модератора менеджеру придется больше полагаться на коммуникативные навыки своих коллег, а им, в свою очередь, быть более дисциплинированными в том, как они организуют свое общение.
В ivelum мы используем оба варианта, при этом режим модератора используется по умолчанию, а роутер применяется только в отдельных редких случаях. Надеюсь, эта статья может помочь в выборе оптимального варианта для вашей конкретной ситуации.
Комментарии (19)
alexEtse
16.09.2021 18:16Да, смесь. Как минимум одно дело, когда общение идёт внутри организации (тут в первом случае больше вреда от испорченного телефона), другое - с внешними участниками (тут уже смотря с кем, но с некоторыми такими участниками точно надо очень внимательно подбирать слова, а потому лучше пропускать такое общение через менеджера).
alexEtse
17.09.2021 00:58И как ты предлагаешь его починить, PM'а, если инфа теряется где-то в нём (ну или тормозиться на нём - ты говоришь ему, он передаёт это другому, другой что-то в ответ ему, он транслирует сказанное тебе, и так далее)? Да, иногда доходило до того, что подрядчики начинали друг с другом общаться напрямую из-за этого, видел такое.
Alente1
16.09.2021 10:33У нас используется режим "роутера" при общении с клиентом. У нас именно проект-менеджер инициирует все задачи по проекту и ведет его. Основная ответственность за проект на нем, члены команды несут ответственность только в рамках своих задач.
Интересно, при режиме "модератора" как структурируется и централизуется информация? В общем чате она не теряется? Не происходит ли того, что одно и то же у клиента спрашивают несколько раз? И как часто проводятся митинги? И что на них обычно обсуждается?
stebunovd Автор
16.09.2021 10:57Отличные вопросы :)
Чат - важное средство общения, но вовсе не единственное. Хранить детали конкретных задач в чате конечно же неудобно, они легко теряются, поэтому для задач есть таск-треккеры. Таск-треккеры, кстати, часто интегрированы с чатом, чтобы в чате был виден весь поток информации. Некоторые вещи бывает удобно оформить не в виде задачи, а в виде общедоступного документа, например в Notion, Confluence, или где-то еще.
Одни и те же вопросы могут обсуждаться по нескольку раз если результаты обсуждений не записываются. Рекомендации довольно стандартные, если что-то обсуждали и что-то решили - обновите соответствующую задачу или документ. После митингов пишите резюме. Это все я отношу к выстраиванию "дисциплины коммуникации в команде". Выстроить ее с нуля бывает сложно, и поддержание дисциплины требует усилий, но если это налажено - оно реально работает.
Как часто проводить митинги каждая команда решает сама. Плановый общекомандный митинг у нас обычно раз в неделю, обсуждаем ближайшие приоритеты. Помимо этого бывают спонтанные митинги по рабочим вопросам, когда людям нужно что-то обсудить и чат для этого не очень удобен.
ruomserg
16.09.2021 15:57+1Я не понимаю, когда разработчики тогда успевают работать? Если каждый человек любой свой вопрос пишет в общий чат группы — это ж будет постоянный трень-брень уведомлений в каналах, нет? А если разработчик не смотрит постоянно канал — тогда нет обратной связи…
stebunovd Автор
16.09.2021 19:16Уведомления настраиваются. Рекомендуемая у нас настройка - уведомления включены для упоминаний человека через @ (в том числе личные сообщения) и отключены для постов в общие каналы. Таким образом, достигается баланс - канал можно и нужно читать в асинхронном режиме, открывая его когда удобно, и вся команда по умолчанию так и делает. Однако, если вопрос срочный, то всегда можно привлечь внимание нужного человека упомянув его через @.
ruomserg
17.09.2021 06:46Я пытаюсь понять логику этого решения, но пока не могу. Итак, мы сначала заставили всех писать все вопросы в общий чат. Теперь мы отключаем уведомления из общего чата (потому что там бардак), и включаем только для «позвать через @». Теперь ситуация почти не отличается от личных сообщений, но сообщения все-равно летят в кучу общего чата. Я предполагаю, что через какое-то время разработчики будут игнорировать все, что не помечено их именем, а задающие вопросы начнут звать через "@" всех подряд, чтобы хоть кто-то ответил. После этого активные разработчики отключат и это уведомление тоже, чтобы хоть как-то работать.
Если честно, я не вижу преимуществ этой странной системы перед более традиционной — вопросы задаются лично, если заранее известно кому — или в общий чат если требуется координация нескольких человек. Если человека задалбывают однотипными вопросами — он в рабочее время и за деньги компании пишет гайд в вики, куда потом тыкает всех обратившихся.
Кроме того, я так и не понимаю — откуда разработчики берут время, чтобы разгребать простыню общего чата и выцеплять вопросы, которые не помечены их именем но на которые они знают ответ? Обычно, разработчик заканчивает одну задачу, и у него всегда есть следующая. У вас не так? Или вы выделяете прямо норму рабочего времени на разбор чата?
Еще одна моя личная гипотеза — что статью написал менеджер, который описал то — как система коммуникации работает в его (!) представлении. Если же сдернуть одеяло — выяснится, что у разрабов там своя система коммуникации, а общий чат поддерживается живым ровно настолько, чтобы менеджер не вонял по этому поводу на митингах. Надеюсь, что это не так.
P.S. У меня, также, есть теория, что разумные электронные способы коммуникации должны оставаться разумными при переносе из виртуала в реал. Так вот, вы предлагаете посадить всех разработчиков в опенспейс, и каждый раз когда кому-то надо кого-то о чем-то спросить — он не «подходит и тихонько спрашивает», а громогласно озвучивает свой вопрос, чтобы его слышали все присутствующие. И ответ ему доводят тоже по громкой связи, чтобы все в комнате на всякий случай получили эту информацию. Но это же шиза, и ровно противоположно рекомендуемым методам коммуникаций в офисе… Следовательно…stebunovd Автор
17.09.2021 09:57Аналогия с опенспейсом некорректная, потому что опенспейс - это синхронная коммуникация, а чат - асинхронная. Вот мы с вами здесь общаемся в публичном месте и это могут видеть все желающие. Разве можно сказать, что мы кричим всем этим людям на ухо?
Разумеется, мы понимаем что чтение чата занимает время, и считаем это важной частью работы. Только по опыту, это далеко не так много времени, как может показаться с непривычки. Чтение Хабра, к примеру, занимает гораздо больше времени :)
Проблема с тем "откуда взять время" она, как обычно, означает "откуда взять желание". Одни чувствуют себя в такой обстановке комфортно прям с первого дня, другим требуется адаптация, а кому-то не заходит вообще. Хочу заметить, с режимом "роутер" абсолютная такая же история - он далеко не всем по нраву.
ruomserg
17.09.2021 10:17Есть большая разница — мы общаемся в публичном месте, но публика не обязана (!) нас читать. Они могут в любой момент нажать сверху настройки и удалить тему из настроек уведомлений. А ваших разработчиков, очевидно, неким способом мотивируют подобного не делать.
В общем понятно — разработчики берут время «откуда-то» (менее вежливый вариант, видимо звучит: «проблемы негров — шерифа не волнуют». :-)
И все-таки, я так и не понял — в чем преимущество перед более традиционной системой? Дело в том, что менеджер — это не binary switch чтобы находиться в одном из выбранных режимов коммуникации. В традиционной системе — менеджер сначала организует коммуникацию (естественно, пропуская ее через себя). Потом, убедившись что коммуникация эффективна — отпускает исполнителей договариваться между собой, обеспечивая возможность быть в теме того, о чем они договариваются (технические способы разные: записи встреч, meeting minutes, разговор с человеком, и т.д.). Если в коммуникации возникла проблема (прямо ли об этом заявлено или он определил по косвенным признакам) — менеджер подключается и исправляет ситуацию (вплоть до того, что прерывает ее и забирает вопрос себе).
Ну да, для этого менеджер должен уметь и хотеть это делать. Ну да, это сложнее чем загнать всех в общий чат. Не знаю, в общем: на обывательском уровне мне предложенная система сильно не нравится. :-(stebunovd Автор
17.09.2021 10:25По моему опыту как раз наоборот - "загнать всех в общий чат" гораздо сложнее, если конечно при этом ставится цель обеспечить эффективную работу.
That said, это конечно мое частное мнение и мой опыт. У вас разумеется свой опыт, и наверное в вашем опыте вещи выглядят иначе.
ruomserg
17.09.2021 10:49Я бы сказал, что «загнать всех в общий чат» и «обеспечить эффективную работу» — это разные цели, и в большинстве случаев — противоречащие друг-другу. И люди, которые эффективно работают — в общий чат не очень хотят…
Ну а дальше, традиционное: "- А от окопа до препятствия ползите зиг-зугом! // Зиг-загом, товарищ майор! // Как я скажу — так и поползете!".
alexEtse
18.09.2021 00:43Таким образом, достигается баланс - канал можно и нужно читать в асинхронном режиме, открывая его когда удобно, и вся команда по умолчанию так и делает.
а если нескольким людям приспичило одновременно пообщаться по разным вопросам - что делаете с кашей из их переписки в общем чате?.. Не всегда комфортно в потоке вычленять сообщения из "твоего" разговора, а если один человек сразу в двух p2p диалогах - еще и запутаться можно...
stebunovd Автор
18.09.2021 01:21Все решается, было бы желание. Во-первых, далеко не всегда прямо уж такая высокая активность в чате, чтобы уже можно было запутаться. Во-вторых, в зависимости от предпочтений команды, могут использоваться треды и/или несколько каналов чата. В-третьих, не чатом единым. Если идут дискуссии по какой-то конкретной задаче или документу, их бывает удобнее вести в комментариях к соответствующей задаче или документу.
Здесь первичен принцип - что все рабочие обсуждения публичны, а уж конкретные средства можно подобрать для каждой ситуации, благо тыщи их.
alexEtse
18.09.2021 03:50Согласен, резонно. Тогда главное подобрать удобные средства коммуникации и не забыть вновь подключающихся участников обучить стратегии их использования (что для чего лучше применять и как именно).
Bro_nina
18.09.2021 23:37На старте проекта с новым заказчиком - только режим роутера. Когда пул целей и задач определён, роли присвоены, сформированы рабочие группы (с руководителями каждой) - только режим модератора. Но: коммуникации проходят через руководителей групп, контролирующих пул работ в группе.
Для сложных и больших проектов работает безотказно
anonymous
alexEtse
Ну не скажи... Дурак-начальник любую работу завалить сможет, конечно, никакая схема взаимодействия не поможет.
В первом случае радостно работает когнитивное искажение "иллюзия контроля". Ну и иногда на самом деле контроль нужен, когда речь идёт о взаимодействии с внешними участниками.
А вот во втором случае убирается испорченный телефон, но зато даже тупо для того, чтобы вникнуть в происходящее в чатах, приходится прикладывать больше усилий.