📚 Правильное донесение информации

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

Например,
😡 Команда не понимает почему мы делаем Б, а не В.
👉 Не доносим до команды приоритеты и потребности бизнеса.

😡 Команда не понимает почему такие дедлайны у фичи.
👉 Не показываем, как образуется оценка и срок, и как на это влияет команда.

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

😡 50% команды не ознакомились с требованиями перед декомпозицей
👉 Процесс поставки требований работает не для всех, нужно скорректировать его.

😡 Команда не запланировала задачку по нагрузочному тестированию, хотя в общем чате компании писали, что нужно сделать всем
👉 Значит, общий чат не подходит для такой информации и нужно заносить задачи в команду иначе

😡 Команда постоянно пишет HRу про организацию отпусков, хотя на портале есть вся информация
👉 Возможно, нужно пересобрать базу знаний, потому что информация плохо ищется.

Еще пример.

Есть Инициатива INT-123, к ней привязана одна задача DEVTASK-100.

Задача дублирует описание в Инициативе. После создания задачи DEVTASK, описание в инициативе поправили и расширили. На грумминге разбирали то, что написано в инициативе. Разработчик, когда взялся за задачу, забыл, что надо смотреть в инициативу, и сделал как написано в задаче. Сделал меньше, чем нужно было → Заказчик недоволен и требует доделать. Разработчик расстроен.

👉 Как это можно было избежать: удалить описание в DEVTASK и написать "смотреть описание в инициативе". Так, у разработчика останется один источник знаний по задаче. Плюс, это снизит риск, что разработчик забудет о договоренности и посмотрит не туда.

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

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

#разработка