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

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

Кому будет полезна данная статья?

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

Чем пользоваться и почему?

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

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

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

1. Удобство в организации групповых чатов(каналов)
2. Наличие threads — возможности создавать диалоговые ветви
3. Разграничение рабочих диалогов и нерабочих. Работа — в Slack. Прочее — в телеграмме/ватсапе/wherever
4. Наличие Reactions
5. Наличие Reminders
6. Возможность интеграции Slack с множеством инструментов

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

Какие установить правила коммуникации в команде и зачем?

1. Не общаться в ЛС

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

• Обсуждения чего-то, требующего приватности.
• Мемасиков/шуточек и прочего флуда.

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

Зачем это правило нужно?

Это правило нужно, чтобы:

1. Можно было отлавливать ситуации, когда кто-то отклонился от курса и начал делать что-то не то.
2. Можно было отлавливать ситуации, когда кто-то начал делать что-то не так.
3. Не случалось ситуаций, когда двое о чем-то договорились, а кто-то третий от этого пострадал.
4. Руководителям можно было следить за слаженностью работы команды.
5. Руководителям можно было отслеживать возникновение конфликтов, обид и возникновение прочего негатива.

2. Тегать тех, к кому идет обращение

Любое сообщение должно иметь адресата. Одного или нескольких.

При обращении к кому-то следует тегать его.

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

Зачем это правило нужно?

Это правило нужно, чтобы:

1. На сообщения в групповых чатах/тредах отвлекались не все участники чата, а только те, кого тегнули.
2. Вероятность того, что у адресата всплывет нотификация, была максимальной. Например, в Slack нотификации иногда теряются.

3. Реагировать на сообщения

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

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

Зачем это правило нужно?

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

4. Пользоваться threads

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

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

Зачем это правило нужно?

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

5. Протоколировать диалоги, которые прошли вне Slack

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

Зачем это правило нужно?

Это правило нужно, чтобы:

1. Лишний раз убедиться в том, что участники диалога верно друг друга поняли
2. Не забывалось, о чем договорились
3. Были в курсе происходящего не принимавшие в диалоге, но заинтересованные в теме диалога лица
4. Можно было ссылаться на итоги разговора
5. … и те же самые доводы из первого пункта про общие каналы связи

Протоколы должны иметь адресатов и получать реакции!

В адресатов следует ставить не всех, а тех, кого тема данного диалога касается.

6. Инициировать кол/встречу, если проблема не решается за 15 минут активной переписки

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

А по итогу созвона — заслать всем протокол.

7. Проводить daily meetings письменно

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

• Что делал вчера?
• Что буду делать сегодня?
• Какие проблемы есть у меня на пути?

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

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

• Что я сделал?
  1. API метод /hello
  2. API метод /howareyou
• Что я буду делать?
  1. API метод /bye
• Вопросы:
  1. Алиса, как думаешь, сколько времени у тебя займет твоя задача?
• Проблемы:
  1. Не проходит деплой. Help!

Обсуждая вопросы/проблемы, не забываем про правило номер 6 — если вопрос/проблема не решается за 15, выносим ее на кол.

В большинстве своем наши daily занимают у каждого минут 15 времени с учетом времени на подготовку к митингу.

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

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

8. Bonus: В inhouse командах обсуждать в текстовом формате все, что касается продуктов и процесса их создания

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

• требования
• дизайн
• реализация
• процессы работы
• предложения и проблемы

На практике не всегда такое возможно на 100%.

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

Зачем это нужно?

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

1. Всегда: руководители думают, что “держат руку на пульсе”, а на деле практически не видят, как идут дела у команды. Все то, что можно отлавливать при общении в групповых чатах, в живом формате практически недоступно
2. Часто: в курилке принимаются решения, которые потом не транслируются всем заинтересованным лицам
3. Порой: обсуждение рабочих вопросов сопровождается разговорами “ни о чем” в большом количестве

Как настроить мессенджер?

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

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

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

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

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

1. Продуктовые

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

Префикс: prdct_

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

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

• gf_prdct_platform
• gf_prdct_backoffice

2. Информационные

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

Префикс: info_

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

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

3. Командные

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

Префикс: team_

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

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

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

4. Временные

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

Префикс: tmp_

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

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

Базовый сетап информационных каналов

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

1. gf_info_general — для всего, что касается организационной части: объявлений, фиксации договоренностей и процессов. Обычно адресуется всем и требует от каждого реакции .
2. gf_info_daily — здесь каждый отписывает свои daily сообщения
3. gf_info_changelog — каждыи раз, когда меняются требования/макеты/wireframes/api или любые другие вводные, от которых кто-то или что-то зависит, в этом канале пишется Change Report в произвольном формате и тегаются заинтересованные лица, которые, в свою очередь, должны отреагировать
4. gf_info_jira — сюда приходят уведомления из JIRA
5. gf_info_confluence — сюда приходят уведомления из Confluence
6. gf_info_deploy — сюда приходят уведомления об автоматических деплоях. В сообщениях о деплоях мы указываем:
   — Instance — ссылка на стендRepository — имя репозитория
   — Branch — имя ветки
   — Pipeline — ссылка на пайплайн в gitlab
   — Job — ссылка на джобу в gitlab
   — Triggered by — ссылка на аккаунт в Slack того, кто сделал пуш в ветку
   — Commit — короткий хэш коммита
7. gf_info_sentry — сюда падают ошибки из Sentry
8. team_backend — для всех backend разработчиков
9. team_dlt — для всех DLT разработчиков
10. team_frontend — для всех frontend разработчиков
11. team_qa — для всех QA

Advanced настройка уведомлений из JIRA

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

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

1. gf_info_jira_comments — для уведомлений о комментариях в JIRA
2. gf_info_jira_qa — для уведомлений для QA о появлении готовых для тестирования задач. В этом канале есть только QA и менеджер
3. gf_info_jira_qa_verdict — для уведомлений о переводе тикетов из статуса “TEST” в “DONE” или “REWORK”

Advanced настройка уведомлений из Sentry

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

• Dev стенд — стенд для разработчиков
• Test стенд — стенд для тестировщиков
• Release стенд — стенд для прогонов релиз-кандидатов
• Production стенд — production-стенд

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

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

Получится:

1. gf_info_sentry_back_dev
2. gf_info_sentry_back_test
3. gf_info_sentry_back_release
4. gf_info_sentry_back_prod
5. gf_info_sentry_front_dev
6. gf_info_sentry_front_test
7. gf_info_sentry_front_release
8. gf_info_sentry_front_prod

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

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

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

1. gf_info_sentry_back_dev-cluster
2. gf_info_sentry_back_prod-cluster
3. gf_info_sentry_front_dev-cluster
4. gf_info_sentry_front_prod-cluster

Пример организации каналов

Вопросы к аудитории

1. Какие бы правила коммуникации вы добавили к тем, что я перечислил?
2. Что еще полезного можно настроить/использовать в мессенджере на уровне всей команды?