Pull to refresh

Comments 19

UFO just landed and posted this here

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

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

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

UFO just landed and posted this here

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

UFO just landed and posted this here

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to leave a comment.

Articles