Проблемы коммуникации составляют большинство всех проблем в управлении проектами. Как именно мы общаемся, это важно, и оказывает самое прямое влияние на нашу работу. В этом посте обсудим одну из самых эффективных стратегий выстраивания общения в команде: открытые коммуникации.
Что такое “открытые коммуникации”
Мы в ivelum с годами выработали определенную культуру общения, которая опирается на открытые коммуникации, подход частично заимствованный из опен-сорса. Почти все рабочие вопросы мы стараемся обсуждать публично, на виду у всей команды. Это происходит в общих чатах, в таск-треккере, а также на открытых видео-митингах, к которым может подключиться любой желающий.
Общение по рабочим вопросам в личке у нас не приветствуется. Это, конечно, не значит, что мы никогда не используем личные сообщения. Однако личка – она только для особых ситуаций, и в большинстве рабочих обсуждений ничего такого особого нет.
Мы не единственная компания, кто так работает, но все же это не очень распространенный подход. В большинстве организаций обсуждения происходят более традиционно: если у вас вопрос к одному человеку, то вы и задаете его этому человеку, а не в общем канале всей команды. Мы же делаем наоборот. Многие из новых ребят, которые к нам приходят, говорят, что то, как мы общаемся, заметно отличается от того, как у них это было на прошлой работе. Мы соответственно объясняем, почему у нас так, и стараемся помочь с адаптацией.
Зачем?
Мотивация очень простая: это радикально ускоряет и упрощает проектную работу, и эффект получается столь велик, что ради него есть смысл действовать не совсем общепринятым способом.
Минимизация отвлечений
На первый взгляд, может показаться, что когда все общение публичное – это очень шумно и отвлекает. В реальности, вопреки интуиции, получается ровно наоборот, и это связано с тем, как работают чаты. В Slack, который мы используем, и во многих других чатах (Discord, MS Teams, Mattermost, и т.д.) настройка по умолчанию следующая:
Уведомления показываются при сообщениях в личку;
Уведомления не показываются на сообщения в общий канал.
То есть, когда вы пишете человеку в личку, вы его отвлекаете от того, что он сейчас делает, а в общий канал – не отвлекаете (если только не упоминаете его явно через @).
По опыту, большинство рабочих вопросов не являются настолько срочными, чтобы немедленно все бросить и начать отвечать. Вполне можно общаться асинхронно – вы пишете, когда вам удобно, а ваш адресат почитает и ответит, когда ему удобно. Для программистов это особенно важно. Любые отвлечения во время написания кода выбивают из потока, и потом приходится долго и мучительно возвращаться обратно.
Это не “лишний шум”
Можно, конечно, сказать, что уменьшение отвлечений – это хорошо, но зачем люди будут пролистывать кучу сообщений, которые адресованы не им, кажется, это лишняя информация? Вовсе нет и даже совсем наоборот! Публичное общение дает серьезные преимущества:
Простой способ держать команду в курсе. Когда другим видно, о чем вы общаетесь, они могут сами понять, над чем вы работаете, и примерно на какой стадии. То есть вам придется реже отвечать на вопрос: “ну как там дела”, потому что ваши дела и так на виду - это и экономия времени, и быстрое распространение информации в команде, все знают, что происходит;
Быстрый поиск решений и обучение. Далеко не вся информация передается путем задавания вопросов и получения ответов. Иногда мы сами не знаем, чего не знаем, поэтому даже понятия не имеем, какой вопрос нужно задать. Наблюдая за тем, как другие люди работают, можно почерпнуть что-то новое для себя, что мы сами никогда бы не догадались спросить или загуглить. И в другую сторону - можно поделиться собственным опытом, видя как коллеги пытаются решить какой-то вопрос.
Также стоит отметить, что грамотная организация каналов чата практически сводит на нет риск переизбытка информации. Каждый канал посвящен какому-то конкретному проекту или команде, и люди подписываются только на те каналы, которые им интересны.
Почему не все так делают?
Даже те команды, которые согласны с преимуществами открытого общения, порой не спешат внедрить его на практике.
Одним из препятствий является обычное человеческое стеснение. Многие не привыкли к такому стилю общения и не чувствуют себя в нем комфортно. Они могут думать, что задают какой-то тривиальный вопрос, и не хотят привлекать к нему слишком много внимания. Лучшее, что мы можем поделать в таких ситуациях - всегда сохранять дружелюбие и позитив. Никакого сарказма и ни в коем случае не считать какие-либо вопросы “глупыми”. Доброжелательная атмосфера критически важна для обучения, ну а постоянное обучение - залог успешного развития всей команды.
Другая распространенная проблема – чрезмерная секретность. Открытые коммуникации могут восприниматься, как риск для утечек информации, и иногда такой риск действительно существует. Однако, возводя искусственные барьеры в общении, компании не только борются с этими рисками, но и наносят серьезный урон собственной продуктивности. Даже одна из наиболее “секретных” компаний мира – Apple – сейчас меняет свои подходы, потому что они сильно затрудняют работу.
В заключение
Есть вещи, которые наиболее продуктивные команды делают не так, как другие. Разумеется, открытое общение не является серебрянной пулей, которая магически решит все проблемы в команде, но это определенно серьезное преимущество.
Многочисленные исследования показывают, что в той или иной форме проблемы коммуникации стоят за большинством причин, по которым проваливаются IT-проекты. Одна из наиболее полезных вещей, которую менеджер или тимлид может сделать для своей команды – это налаживать продуктивное общение, в первую очередь, конечно, подавая личный пример.
Комментарии (34)
ReadOnlySadUser
09.09.2022 19:06+23Работал я в месте, где придерживались такого же подхода. Правда почти всё общение было через email, но мне так даже удобнее. Соответственно, все переписки внутри команды, рассылались на всю команду, уведомления приходили только когда ты явно стоишь как адресат.
Из плюсов - когда к тебе приходят с вопросом ты можешь просмотреть всю историю проблемы, какие пути решения уже пытались предпринять и вот это вот всё.
Из минусов - спам. Много спама. Особенно когда со временем попадаешь в листы рассылки к другим командам в процессе решения каких-то интеграционных проблем. Поэтому все письма в которых я не стоял как прямой адресат сразу фильтром улетали в помойку, я их даже не открывал. За два года работы в этом месте, ни разу ничего серьезного не пропустил.В общем,
Простой способ держать команду в курсе.
это, на мой взгляд, выдавать желаемое за действительное. В реальности команда в большинстве случаев игнорирует весь этот поток мыслей.
sshikov
09.09.2022 19:19+1>игнорирует весь этот поток мыслей
Ну, на самом деле можно легко оценить, до какого предела это мастшабируется. Скажем, у меня достаточно типичная картина, когда писем в сутки порядка 100. И это я еще не учитываю роботов типа битбакета или там дженкинса, или прочие стандартные отчеты, каковые мне приходят по 10 штук в сутки.
Прикиньте, 8 часов рабочего времени, 480 минут, одно письмо в 5 минут, примерно. И минимум что мне нужно сделать — это прочитать, и понять, что я могу это игнорировать. А поскольку я PO, то мне потенциально может быть дело до любой темы, поэтому читать приходится все, заголовками ограничиться не удается. Даже если читать и принимать решение быстро, все равно порядка 100 минут на 100 писем не выглядит чем-то уж очень преувеличенным. Как вам нравится потеря 20-25 процентов рабочего времени? Мне совсем не нравится. Я это пытаюсь оптимизировать всеми силами, но в целом это зло.Особенно когда со временем попадаешь в листы рассылки к другим командам в процессе решения каких-то интеграционных проблем.
А у меня интеграционный проект по сути. Поэтому за несколько лет работы я уже во всех подобных листах числюсь. При этом размер вашей команды вообще уже роли не играет, потому что вот людей вот из этих прочих команд — их в разы больше.
Никогда по собственной воле не буду подобное внедрять. Разработчикам и пр. специализациям, кому нужна сосредоточенность — противопоказано категорически.
DmitryMurinov
09.09.2022 19:43+1"Даже если читать и принимать решение быстро, все равно порядка 100 минут на 100 писем не выглядит чем-то уж очень преувеличенным. Как вам нравится потеря 20-25 процентов рабочего времени?" - немного странно слышать от PO, что чтение рабочей почты является потерей времени. ИМХО, это одна из основных обязанностей в рамках коммуникаций внутри и снаружи команды, позволяющая держать руку на пульсе событий и сильно увеличивающая эффективность команды, за счёт фильтрации потока входящей почты и значительно более редкого вытаскивания линейного персонала из контекста.
sshikov
09.09.2022 20:03>немного странно слышать от PO
Дело в том, что я еще и разработчик. У нас нехватка людей. Нет, не потеря конечно, но от работы, требующейся от меня же — отвлекает сильно.
>за счёт фильтрации потока входящей почты
Так именно этим я и занимаюсь. Просто автор предлагает этот поток направить на всю команду, чтобы все были в курсе — я же наоборот, пытаюсь избавить остальных от ненужных переписок, донося до них окончательные выводы, когда они будут доступны.
Я вообще не жаловался, если вы вдруг меня так поняли — я просто показал, какого масштаба это бывает, даже при небольшой команде, и почему — потому что интеграция и у маленькой команды может быть со многими другими, а этих других — полно.
stebunovd Автор
09.09.2022 19:22+2Электропочта все-таки отличается от чата, потому что для прочтения каждого письма нужно сделать клик. В чате все сообщения идут подряд и мы их просто скроллим. Разница вроде и небольшая, но привычки в использовании меняет очень сильно. Я порой тоже попадаю в копию длинных переписок в электропочте и это реально боль. Но в чате другая история, там не так.
DmitryMurinov
09.09.2022 19:47+1В чате команды при таком подходе очень удобен Slack, и приучивание себя и окружающих обсуждать вопросы в ветках внутри верхних сообщений. Фильтровать и листать сильно меньше. Особенно если спросивший ставит галку на верхнем сообщении, когда вопрос закрыт.
Интересно, есть ли бесплатные инструменты с аналогичным фцнкционалом и не режущие историю.
stebunovd Автор
09.09.2022 19:58Discord - сам не пользовался пока, но слышал хорошие отзывы. MS Teams - пользовался, чат (на мой вкус) сильно проигрывает слеку. Зато у MS Teams на удивление неплохие видео-митинги
sshikov
09.09.2022 20:03+5Зато в чате ничего вообще не найти, если это было скажем полчаса назад. Во всяком случае в телеграмм чатах именно так и происходит.
stebunovd Автор
09.09.2022 20:44+3В телеграм-чатах - да, полностью согласен. В Slack ситуация получше обстоит. Способ организации каналов, треды, то как работает поиск, как сообщения отмечаются прочитанными, закладки - в целом, ситуация заметно лучше по сравнению с телеграммой, на мой взгляд.
Тем не менее, даже со всякими улучшениями формат чата плохо подходит для использования его в качестве вики, документации, таск-треккера или чего-то подобного - для этого есть свои специализированные инструменты. Например, инструкцию по развертыванию проекта лучше все же хранить в Readme в репозитории проекта, ну а в чат можно скинуть ссылку если кто спросит.sshikov
09.09.2022 23:05+2И оно может быть разложено по папкам? В почте, в отличие от того же телеграма, я могу общий поток разложить по папкам, применяя правила. Причем мои правила, у коллег могут быть другие.
stebunovd Автор
10.09.2022 00:25Прямого аналога папкам и индивидуальным правилам для фильтрации сообщений в слеке нет, это все-таки другой формат общения. Что тут есть:
Каналы у всех одинаковы, но каждый пользователь сам выбирает в какие каналы подключаться, может сгруппировать их у себя удобным ему образом, и настроить режим оповещений индивидуально для каждого канала;
Также есть довольно богатые глобальные настройки оповещений, в которых можно настроить свой список ключевых слов, расписание, оповещать ли об ответах в тредах и другое;
В каждом канале сообщения можно добавлять в закладки, как персональные (Saved items) так и глобальные для всех (Pin to channel);
Сообщения можно помечать обратно как непрочитанные, чтобы вернуться к ним позже;
Можно отправлять сообщения самому себе. Например, пересылать самому себе какие-то сообщения чтобы вести там архив, или просто писать какие-то заметки для себя.
hbn3
09.09.2022 22:00+1Поэтому все письма в которых я не стоял как прямой адресат сразу фильтром улетали в помойку, я их даже не открывал.
Проблема в то что как изначально TO и CC сформированны, то такими они и остаются, очень мало кто их переделавает под текущую реальность. Плюс не очень многие правильно понимают как следует ими пользоваться. По крайней мере у нас. Есть те кто нового адреста всегда просто в TO добавляет. Многие не указывают хотя бы имя того к кому они обращаются, получается игра — угадайка.
Если ты попробуешь что-то сказать по этому поводу — то ты токсик.В реальности команда в большинстве случаев игнорирует весь этот поток мыслей.
Полностью согласен, так и оно есть, если все эти потоки читать на работу времени не остаётся.
Всё это открытое общение, в большинстве случаев от того, что никто ничего не знает и не понимает. А кто знает и понимает — сидят потихоньку, надеясь чтобы им не вручили эту задачу/проблему.
В общем мечта эффективного менеджера, налив три ведра пустой воды показать свою значимость и надуть щёки в «reply all» на 50 человек. Из которых 40 вообще не при делах, 8 паразитирующие особи и двое что-то, как-то знают, но не отсвечивают. Так всё и длится, пока случайно явно не обратятся к одному из тех двоих с прямым вопросом.
domix32
10.09.2022 10:55+1Хорошо если общие чаты как в слаке по топику вглубь уходить могут, а когда весь этот поток мыслей даже на 5-6 человек льётся то тут прям много проблем возникает ибо читать несколько сотен сообщений которые шли в параллель с касающейся тебя темой такое себе.
AlexeyALV
09.09.2022 20:50+1Соглашусь с основными посылами статьи. Я пропагандирую предложения и вопросы по сути задач писать прямо в Jira в комменты, а обсуждения в общий чат по проекту. Сейчас, правда, безопасность не разрешает чаты - так что в почту с копией на всех причастных.
aktuba
09.09.2022 21:00+2Многочисленные исследования показывают, что в той или иной форме проблемы коммуникации стоят за большинством причин, по которым проваливаются IT-проекты.
Поделитесь ссылками plz.
stebunovd Автор
10.09.2022 00:10-1Вот, например, статья на Forbes с отсылками к нескольким исследованиям и опросам - от PwC, IBM, PMI, HBR.
aktuba
10.09.2022 00:25+3Видимо у меня совсем плохо с английским, но в приведённой ссылке я не нашёл подтверждение утверждению «в той или иной форме проблемы коммуникации стоят за большинством причин, по которым проваливаются IT-проекты». Можете мне помочь?
stebunovd Автор
10.09.2022 00:45-4В этой фразе "проблемы коммуникации" понимаются в более широком смысле, нежели чем какие-то ситуационные сложности с перепиской или звонками. Здесь имеются в виду любые виды проблем, когда одному человеку не удается грамотно, вовремя и достаточно убедительно донести свою мысль другому, например:
Постановка целей - когда менеджмент не может ясно донести команде зачем все это делается;
Работа с требованиями - когда их составитель провел недостаточно хорошую работу по выяснению нужд пользователей;
Оценка рисков - когда команду разработки вообще не спрашивали насколько это сложно сделать, или же ей не удалось убедительно донести свою мысль;
Оценка текущего состояния проекта - когда менеджмент плохо представляет себе реальное положение дел;
Командное взаимодействие - когда люди не могут конструктивно решить возникшие между ними разногласия;
... и т.д.
Если вы взглянете на "проблемы коммуникации" именно в таком, более широком смысле, то да, окажется что они скрываются за большинством проблем проектов.
aktuba
10.09.2022 01:48+3Вы искусственно свели почти все возможные проблемы в «коммуникации», что не верно (по мне). Таким же образом сюда можно добавить:
проблемы с железом (оно не рассказало заранее, когда выйдет из строя)
проблемы с софтом (недостаточно информирует пользователя о будущих багах)
рыночная неопределенность или риски (не уведомили о возможных проблемах в рамках 100 лет)
Мне было бы интересно узнать про исследование коммуникаций в изначальном толковании этого термина: как объём общения в рамках компании/команды, открытость или закрытость общения, способы общения и пр влияют на развитие компании или команды. Поэтому и попросил поделиться ссылками на «многочисленные исследования», т.к. сам такие исследования не встречал и не слышал о них.
Если же подходить к этому с вашей точки зрения - ничего важнее просто нет и в корне любой проблемы именно недостаточное общение. С чем я абсолютно не согласен, т.к. в реальности встречал подобное и было очень больно в итоге.
stebunovd Автор
10.09.2022 08:34-1Каждый, разумеется, вкладывает в этот термин что-то свое. Мне близко определение из википедии, которое по запросу "Коммуникация (психология)" перенаправляет на статью Общение:
сложный многоплановый процесс установления и развития контактов между людьми (межличностное общение) и группами (межгрупповое общение), порождаемый потребностями совместной деятельности...
aktuba
10.09.2022 18:06Снова софистика ((
Ок, давайте в вашем ключе пойдём. Правильно ли я понял, что есть исследования (и вы ими поделитесь), на основании которых можно утверждать:
увеличение количества контактов и объёма общения (я же правильно понял формулировку «процесс установления и развитие контактов»?) повышают вероятность успеха it-проекта
объём и открытость общения снижает вероятность любых проблем в it-проектах
stebunovd Автор
10.09.2022 19:00-1нет :) Боюсь, не получится объяснить в рамках комментария, слишком обширная тема. Может как-нибудь соберусь статью накатать на эту тему. А может вы свою накатаете, и разобьете эти предрассудки в пух и прах
nikolas78
10.09.2022 21:34Ой, да ладно! Взять большую проблему, придумать простенькое решение и продавать его — профит.
мы все так делаем
PereslavlFoto
09.09.2022 21:21-3Обсуждать рабочие вопросы публично — означает публиковать недостатки каждого сотрудника. В этом режиме нельзя скрыть своего незнания, нельзя применять «общеизвестные неписаные правила».
Наблюдая за тем, как другие люди работают, можно почерпнуть у них то, чем они вовсе не хотят делиться. Почерпнуть то, что отнимет у них монополию на знания, а значит, и отнимет средства для манипулирования коллегами.
Когда другим видно, о чём вы общаетесь — тогда каждый будет вмешиваться в вашу работу, каждая проблема разойдётся тысячей сплетен, и каждый найдёт, в чём упрекнуть вас.
Firz
09.09.2022 22:15+8Что-то прям какое-то змеиное гнездо описываете, я бы наоборот сказал что хорошо когда больше людей узнает что именно я не знаю, выше шанс что кто-то да подскажет где и как это лучше изучить.
PereslavlFoto
10.09.2022 20:37Практические наблюдения описываю. — Вот лежит на столе у человека книжка. Но подойти, развернуть её и прочитать нельзя, потому что это только его книжка, а не общая. Сфотографировать тоже нельзя, потому что нарушится монополия доступа.
Вы скажете: «Но ведь можно попросить разрешение». Попросить можно, получить нельзя.
akakoychenko
10.09.2022 01:07+4Не убедили. С одной стороны, считаю, что 99% сообщений в личке в slack практически в любой нормально работающей компании не являются секретными, и тот факт, что их не могут видеть все, препятствует накоплению базы знаний. Поэтому, наверное, открытая публикация всех переписок в личке для всех сотрудников компании с мощными возможностями по полнотекстовому поиску, возможно, сделала бы жизнь лучше.
Но вот сама идея, что вопросы пишутся всем и никому сразу, и вся команда видит выделенные болдом чаты, не понимая, это вопрос им или нет, пока не залезут вовнутрь, мне кажется омерзительной. Хорошие инженеры часто перфекционисты, и непрочитанный чат будет мозолить глаз и отвлекать внимание, хотя разговор идёт вообще о том, где человек бесполезен. Нельзя так бросаться вниманием...
Frank59
10.09.2022 08:37хорошие инженеры обычно умеют в таймменеджмент и отсекать не важные каналы получения информации(например мьютить каналы в слаке, которые не требует внимания). по другому продуктивно работать в большой компании попросту не получится.
>вопросы пишутся всем и никому сразу
не знаю как у автора, но обычно есть роль дежурного по команде для обработки входящих запросов. он берет на себе все такие запросы в течение какого-то периода времени, при этом вся остальная команда может полностью сфокусироваться на основных историях. при этом внешним людям не нужно думать о том, кто конкретно в команде сейчас дежурит, запрос идет именно команде целиком
akakoychenko
10.09.2022 18:41+1но обычно есть роль дежурного по команде для обработки входящих запросов
это не обычно, это очень печально, если в такой роли появляется смысл, ибо задача команды разработки не в том, чтобы сидеть на потоке входящих запросов, а в том, чтобы, непосредственно, разрабатывать. Коммуникация же, которая возникает при нормальной командной работе, носит такой характер, что от дежурного будет толку 0, ибо только 1 человек может ответить быстро и эффективно (к примеру, тестировщик уточняет у девелопера нюансы того, что он делал; девелопер, желая написать сервис по образу и подобию существующего спрашивает совета у его автора, и подобные узкоспециализированные запросы внутри команды). Ваша же ситуация, из моего опыта, применима в трех случаях:
1) в компании отвратительные процессы и плохая документация, - дев команде приходится делать работу продактов, проджектов, аналитиков, и прочих людей, работа которых подразумевает частые коммуникации и не требует вхождения в поток на несколько часов.
2) в компании отвратительная архитектура, - продукты или модули нескольких команд настолько связаны, что одной команде невозможно сделать сколь значимое изменение без риска сломать что-то у соседней команды
2) это дев команда, которую посадили на саппорт продуктов, которые более не развиваются
Все три случая, увы, печальны
Frank59
10.09.2022 08:27+1Хорошая статья, спасибо. У нас в команде похожий подход к коммуникации
В раздел Это не “лишний шум” я бы еще добавил возможность кроссчекинга - возможность проверить и дополнить/поправить что-то, что написал один из членов команды.
И как результат, когда вся команда имеет общий контекст и каждый член команды может эффективно отвечать на входящие запросы - такой подход очень сильно снижает bus factor в команде
nikolas78
10.09.2022 14:14Идеальным вариантом было бы решение, когда есть 3 типа чатов: личные чаты, общий и «куча». В «кучу» сыпятся автоматом переписка из всех личных чатов. Общий чат — это информация важная для всех. Уведомления (которые видны вне мессенджера) приходят только для новых сообщений из личных чатов и из общего. В «кучу» каждый заходит по желанию. В самом мессенджере должно быть видно количество новых сообщений для каждого канала.
aigoncharov
А какой у вас размер команды?
stebunovd Автор
У нас их несколько. Размеры команд мы стараемся держать небольшим, в идеале не более 5-6 человек. Если команда разрастается, значит разбиваем на две, выделяя каждой свою область ответственности, свой канал в чате, проект в таск-треккере, итд.
Среди наших клиентов есть организации в которых несколько сотен человек, но и там такой же подход - все делятся на относительно небольшие команды.