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

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 3 месяца
Сообщений: 27286

news_bot ^® написал(а)
14-Июл-2020 19:30

Цитировать

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

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

Если есть какая-то альтернатива Slack, для которой были бы справедливы все 6 пунктов выше, пожалуйста, подскажите в комментах. А еще для такой альтернативы подскажите, какие у нее есть крутые и часто используемые в вашей команде фичи.
Какие установить правила коммуникации в команде и зачем?
1. Не общаться в ЛС
Общение в ЛС оставляем только для двух случаев:

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

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

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

2. Тегать тех, к кому идет обращение
Любое сообщение должно иметь адресата. Одного или нескольких.
При обращении к кому-то следует тегать его.
При обращении к нескольким людям — тегать каждого, а не всех в канале.
Зачем это правило нужно?
Это правило нужно, чтобы:

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

3. Реагировать на сообщения
Ни одно отправленное кем-то(не автоматически) сообщение не должно быть проигнорировано адресатами этого сообщения. Адресат при получении сообщения должен дать ответную реакцию. Если адресатов несколько — отреагировать должен каждый.
Для того, чтобы не писать фразы “ok”, “понял” и тд, в Slack есть удобная фича — reactions. Члены нашей команды обычно ставят реакцию :eyes:. Руководитель пользуется реакцией :eye:.
Зачем это правило нужно?
Это правило нужно, чтобы отправитель знал, что его сообщение “не потерялось”.
4. Пользоваться threads
В Slack есть такая фича, как threads — возможность создать “ветвь диалога” и вести диалог в ней, а не в основном потоке сообщений.
Эта фича хорошо подходит для обсуждения одного вопроса.
Зачем это правило нужно?
Это правило нужно, чтобы не устраивать бардак в основном потоке сообщений, тем самым повышая структурированность информации и удобство навигации по ней.
5. Протоколировать диалоги, которые прошли вне Slack
Если какой-то диалог прошел, скажем, на созвоне, то нужно по итогам созвона вкинуть протокол — набор тезисов, которые отражают итоги разговора.
Зачем это правило нужно?
Это правило нужно, чтобы:

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

Протоколы должны иметь адресатов и получать реакции!
В адресатов следует ставить не всех, а тех, кого тема данного диалога касается.
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 командах следующие проблемы:

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

Как настроить мессенджер?
Для того, чтобы каналы были удобно упорядочены, мы пользуемся системой префиксов.
Поскольку наша команда занимается разными проектами, мы для каждого проекта придумываем префикс и используем его в названиях каналов.
Например, у нас есть 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-команды.

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

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

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

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

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

Для каждого из них мы сделали отдельный sentry-канал.
А чтобы frontend разработчики не дергались, когда случается ошибка на backend, и наоборот, разбили эти каналы еще и на группы frontend/backend.
Получится:

gf_info_sentry_back_dev
gf_info_sentry_back_test
gf_info_sentry_back_release
gf_info_sentry_back_prod
gf_info_sentry_front_dev
gf_info_sentry_front_test
gf_info_sentry_front_release
gf_info_sentry_front_prod

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

gf_info_sentry_back_dev-cluster
gf_info_sentry_back_prod-cluster
gf_info_sentry_front_dev-cluster
gf_info_sentry_front_prod-cluster

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

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

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

===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_upravlenie_proektami (Управление проектами), #_upravlenie_razrabotkoj (Управление разработкой), #_kommunikatsija_v_komande (коммуникация в команде), #_projectmanagement, #_upravlenie_komandoj (управление командой), #_kommunikatsija (коммуникация), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_razrabotkoj (
Управление разработкой
)

Профиль ЛС

Ответить на тему

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

Текущее время: 16-Май 03:42
Часовой пояс: UTC + 5