Кто владеет информацией - тот владеет миром. Как организовать коммуникацию и распространение информации на проекте?

Грамотно выстроенная коммуникация и хорошо организованное распространение информации на проекте - самые важные условия для слаженной работы команды. Думаю, во всех командах, вне зависимости от того, remote они или нет, сталкивались с проблемами вида “А почему мне не сказали”, “Но мы же договаривались о другом” или “Блин, я не увидел”. К сожалению, нельзя полностью избежать возникновения таких ситуаций. Но можно свести вероятность их возникновения к минимуму. В этой статье я расскажу о том, какими правилами коммуникации и настройками мессенджера мы эти проблемы решили.

Статья будет полезна для руководителей и участников небольших проектных команд размером 5-10-15 человек.

Для коммуникации и распространения информации лично мы пользуемся Slack.

Большую часть написанного ниже так или иначе можно организовать и в других мессенджерах.

Причины, по которым мы пользуемся Slack:

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

Общение в ЛС оставляем только для двух случаев:

Для всего остального используем общие каналы связи.
Сейчас я расскажу, для чего это нужно. О том, как организовать общие каналы связи таким образом, чтобы не было месива и бардака, я расскажу чуть позже.

Зачем это правило нужно?
Это правило нужно, чтобы:

Любое сообщение должно иметь адресата. Одного или нескольких.
При обращении к кому-то следует тегать его.
При обращении к нескольким людям - тегать каждого, а не всех в канале.

Зачем это правило нужно?
Это правило нужно, чтобы:

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

Для того, чтобы не писать фразы “ok”, “понял” и тд, в Slack есть удобная фича - reactions.Члены нашей команды обычно ставят реакцию :eyes: - 👀. Руководитель пользуется реакцией :eye: - 👁.

Зачем это правило нужно?
Это правило нужно, чтобы отправитель знал, что его сообщение “не потерялось”.

В Slack есть такая фича, как threads - возможность создать “ветвь диалога” и вести диалог в ней, а не в основном потоке сообщений.

Эта фича хорошо подходит для обсуждения одного вопроса.

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

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

Зачем это правило нужно?
Это правило нужно, чтобы:

Протоколы должны иметь адресатов и получать реакции!
В адресатов следует ставить не всех, а тех, кого тема данного диалога касается.

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

Daily meeting - это групповая встреча, на которой каждый член команды должен ответить на несколько злободневных вопросов и обсудить актуальные вопросы/проблемы с целью синхронизации команды. Пример комплекта вопросов для daily meetings:

Мы daily meetings проводим с 11:30 до 11:35 в выделенном для этого групповом чате. Руководитель пишет последним - в 11:36. Все, кто отписался после него, считаются опоздавшими. С опоздавшими следует проводить воспитательную работу. Каждый должен под сообщением каждого проставлять реакцию 👀. Эта реакция - подтверждение того, что каждый ознакомился с каждым daily-сообщением.

Шаблон нашего daily-сообщения:

Обсуждая вопросы/проблемы, не забываем про правило номер 6 - если вопрос/проблема не решается за 15, выносим ее на кол.
В большинстве своем наши daily занимают у каждого минут 15 времени.

Зачем это правило нужно?
Это правило нужно, чтобы эффективно расходовать рабочее время команды. И терпение.

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

Мой личный опыт показывает, что жизнь становится лучше, когда письменно обсуждаются:

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

Зачем это нужно?
Для того, чтобы решить в inhouse командах следующие проблемы:

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

Поскольку наша команда занимается разными проектами, мы для каждого проекта придумываем префикс и используем его в названиях каналов.
Например, у нас есть 2 проекта - GoldFixing и Aurrency. Для этих проектов мы используем следующие префиксы: gf - для GoldFixing и aurm для Aurrency. Тогда все каналы, связанные с GoldFixing, будут начинаться с префикса gf_ и иметь вид gf_somechannel. Аналогично с Aurrency - каналы будут иметь вид aurm_somechannel.

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

Каналы можно поделить на 4 категории:

Это каналы, которые посвящены продуктам, которые создаются в рамках проекта.

Префикс: prdct_

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

Таким образом, если в рамках проекта GoldFixing создается два продукта - платформа и бекофис, то для них мы заводим вот такие каналы:

Каналы из данной категории предназначаются не для общения, а для распространения информации.

Префикс: info_

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

Таким образом, если в проекте GoldFixing мы пользуемся JIRA, то у нас будет канал gf_info_jira.

Это каналы, которые посвящены командам, образованным на основе их профессий.

Префикс: team_

В каналах этой категории обсуждаются те вопросы, которые привязаны к какой-то профессиональной дисциплине(frontend/backend/etc) и не касаются других дисциплин.

Например, если в проекте GoldFixing есть несколько frontend-разработчиков, то у нас будет канал gf_team_frontend.

Если одни и те же люди занимаются несколькими проектами, то можно опустить префикс проекта и назвать канал просто - team_frontend.

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

Префикс: tmp_

Например, если в проекте GoldFixing нужно обсудить покупку чашек с логотипом проекта, то мы делаем канал gf_tmp_brand-cups.

Если нужно обсудить что-то, не привязанное к конкретному проекту, то опускаем префикс проекта.

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

Если в один канал сыпать уведомления о всем происходящем в JIRA, канал превратится в месиво из сообщений.

Для этого мы провели тонкую настройку уведомлений и сделали не один, а несколько каналов для JIRA:

У нас на каждом проекте есть несколько инстансов(стендов) проекта:

Для каждого из них мы сделали отдельный sentry-канал.

А чтобы frontend разработчики не дергались, когда случается ошибка на backend, и наоборот, разбили эти каналы еще и на группы frontend/backend.

Получится:

Таким образом, фронты не дергаются из-за ошибок на бекенде, и наоборот.

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

В силу того, что production инстанс проекта располагается на одном кластере, а все остальные инстансы на другом, мы думаем о том, чтобы сгруппировать каналы по кластерам и получить: