Комментарии 19
Ну не скажи... Дурак-начальник любую работу завалить сможет, конечно, никакая схема взаимодействия не поможет.
В первом случае радостно работает когнитивное искажение "иллюзия контроля". Ну и иногда на самом деле контроль нужен, когда речь идёт о взаимодействии с внешними участниками.
А вот во втором случае убирается испорченный телефон, но зато даже тупо для того, чтобы вникнуть в происходящее в чатах, приходится прикладывать больше усилий.
Да, смесь. Как минимум одно дело, когда общение идёт внутри организации (тут в первом случае больше вреда от испорченного телефона), другое - с внешними участниками (тут уже смотря с кем, но с некоторыми такими участниками точно надо очень внимательно подбирать слова, а потому лучше пропускать такое общение через менеджера).
И как ты предлагаешь его починить, PM'а, если инфа теряется где-то в нём (ну или тормозиться на нём - ты говоришь ему, он передаёт это другому, другой что-то в ответ ему, он транслирует сказанное тебе, и так далее)? Да, иногда доходило до того, что подрядчики начинали друг с другом общаться напрямую из-за этого, видел такое.
У нас используется режим "роутера" при общении с клиентом. У нас именно проект-менеджер инициирует все задачи по проекту и ведет его. Основная ответственность за проект на нем, члены команды несут ответственность только в рамках своих задач.
Интересно, при режиме "модератора" как структурируется и централизуется информация? В общем чате она не теряется? Не происходит ли того, что одно и то же у клиента спрашивают несколько раз? И как часто проводятся митинги? И что на них обычно обсуждается?
Отличные вопросы :)
Чат - важное средство общения, но вовсе не единственное. Хранить детали конкретных задач в чате конечно же неудобно, они легко теряются, поэтому для задач есть таск-треккеры. Таск-треккеры, кстати, часто интегрированы с чатом, чтобы в чате был виден весь поток информации. Некоторые вещи бывает удобно оформить не в виде задачи, а в виде общедоступного документа, например в Notion, Confluence, или где-то еще.
Одни и те же вопросы могут обсуждаться по нескольку раз если результаты обсуждений не записываются. Рекомендации довольно стандартные, если что-то обсуждали и что-то решили - обновите соответствующую задачу или документ. После митингов пишите резюме. Это все я отношу к выстраиванию "дисциплины коммуникации в команде". Выстроить ее с нуля бывает сложно, и поддержание дисциплины требует усилий, но если это налажено - оно реально работает.
Как часто проводить митинги каждая команда решает сама. Плановый общекомандный митинг у нас обычно раз в неделю, обсуждаем ближайшие приоритеты. Помимо этого бывают спонтанные митинги по рабочим вопросам, когда людям нужно что-то обсудить и чат для этого не очень удобен.
Уведомления настраиваются. Рекомендуемая у нас настройка - уведомления включены для упоминаний человека через @ (в том числе личные сообщения) и отключены для постов в общие каналы. Таким образом, достигается баланс - канал можно и нужно читать в асинхронном режиме, открывая его когда удобно, и вся команда по умолчанию так и делает. Однако, если вопрос срочный, то всегда можно привлечь внимание нужного человека упомянув его через @.
Если честно, я не вижу преимуществ этой странной системы перед более традиционной — вопросы задаются лично, если заранее известно кому — или в общий чат если требуется координация нескольких человек. Если человека задалбывают однотипными вопросами — он в рабочее время и за деньги компании пишет гайд в вики, куда потом тыкает всех обратившихся.
Кроме того, я так и не понимаю — откуда разработчики берут время, чтобы разгребать простыню общего чата и выцеплять вопросы, которые не помечены их именем но на которые они знают ответ? Обычно, разработчик заканчивает одну задачу, и у него всегда есть следующая. У вас не так? Или вы выделяете прямо норму рабочего времени на разбор чата?
Еще одна моя личная гипотеза — что статью написал менеджер, который описал то — как система коммуникации работает в его (!) представлении. Если же сдернуть одеяло — выяснится, что у разрабов там своя система коммуникации, а общий чат поддерживается живым ровно настолько, чтобы менеджер не вонял по этому поводу на митингах. Надеюсь, что это не так.
P.S. У меня, также, есть теория, что разумные электронные способы коммуникации должны оставаться разумными при переносе из виртуала в реал. Так вот, вы предлагаете посадить всех разработчиков в опенспейс, и каждый раз когда кому-то надо кого-то о чем-то спросить — он не «подходит и тихонько спрашивает», а громогласно озвучивает свой вопрос, чтобы его слышали все присутствующие. И ответ ему доводят тоже по громкой связи, чтобы все в комнате на всякий случай получили эту информацию. Но это же шиза, и ровно противоположно рекомендуемым методам коммуникаций в офисе… Следовательно…
Аналогия с опенспейсом некорректная, потому что опенспейс - это синхронная коммуникация, а чат - асинхронная. Вот мы с вами здесь общаемся в публичном месте и это могут видеть все желающие. Разве можно сказать, что мы кричим всем этим людям на ухо?
Разумеется, мы понимаем что чтение чата занимает время, и считаем это важной частью работы. Только по опыту, это далеко не так много времени, как может показаться с непривычки. Чтение Хабра, к примеру, занимает гораздо больше времени :)
Проблема с тем "откуда взять время" она, как обычно, означает "откуда взять желание". Одни чувствуют себя в такой обстановке комфортно прям с первого дня, другим требуется адаптация, а кому-то не заходит вообще. Хочу заметить, с режимом "роутер" абсолютная такая же история - он далеко не всем по нраву.
В общем понятно — разработчики берут время «откуда-то» (менее вежливый вариант, видимо звучит: «проблемы негров — шерифа не волнуют». :-)
И все-таки, я так и не понял — в чем преимущество перед более традиционной системой? Дело в том, что менеджер — это не binary switch чтобы находиться в одном из выбранных режимов коммуникации. В традиционной системе — менеджер сначала организует коммуникацию (естественно, пропуская ее через себя). Потом, убедившись что коммуникация эффективна — отпускает исполнителей договариваться между собой, обеспечивая возможность быть в теме того, о чем они договариваются (технические способы разные: записи встреч, meeting minutes, разговор с человеком, и т.д.). Если в коммуникации возникла проблема (прямо ли об этом заявлено или он определил по косвенным признакам) — менеджер подключается и исправляет ситуацию (вплоть до того, что прерывает ее и забирает вопрос себе).
Ну да, для этого менеджер должен уметь и хотеть это делать. Ну да, это сложнее чем загнать всех в общий чат. Не знаю, в общем: на обывательском уровне мне предложенная система сильно не нравится. :-(
По моему опыту как раз наоборот - "загнать всех в общий чат" гораздо сложнее, если конечно при этом ставится цель обеспечить эффективную работу.
That said, это конечно мое частное мнение и мой опыт. У вас разумеется свой опыт, и наверное в вашем опыте вещи выглядят иначе.
Ну а дальше, традиционное: "- А от окопа до препятствия ползите зиг-зугом! // Зиг-загом, товарищ майор! // Как я скажу — так и поползете!".
Таким образом, достигается баланс - канал можно и нужно читать в асинхронном режиме, открывая его когда удобно, и вся команда по умолчанию так и делает.
а если нескольким людям приспичило одновременно пообщаться по разным вопросам - что делаете с кашей из их переписки в общем чате?.. Не всегда комфортно в потоке вычленять сообщения из "твоего" разговора, а если один человек сразу в двух p2p диалогах - еще и запутаться можно...
Все решается, было бы желание. Во-первых, далеко не всегда прямо уж такая высокая активность в чате, чтобы уже можно было запутаться. Во-вторых, в зависимости от предпочтений команды, могут использоваться треды и/или несколько каналов чата. В-третьих, не чатом единым. Если идут дискуссии по какой-то конкретной задаче или документу, их бывает удобнее вести в комментариях к соответствующей задаче или документу.
Здесь первичен принцип - что все рабочие обсуждения публичны, а уж конкретные средства можно подобрать для каждой ситуации, благо тыщи их.
На старте проекта с новым заказчиком - только режим роутера. Когда пул целей и задач определён, роли присвоены, сформированы рабочие группы (с руководителями каждой) - только режим модератора. Но: коммуникации проходят через руководителей групп, контролирующих пул работ в группе.
Для сложных и больших проектов работает безотказно
Менеджер вашей команды — роутер или модератор?