Сергей Барамба – Триединство проекта: Стейкхолдеры, Команда, Коммуникации (страница 4)
Действительно эти два базовых документа позволят понять – с кем в первую очередь предстоит работать, чтобы дальнейшем выработать и зафиксировать подходы кому и по какому каналу связи можно передавать информацию для старта работ, как запрашивать данные для формирования отчёта, как позвать на собрание и что будет его итогом.
В разделе посвящённому Управлению коммуникациями (Manage Communications) описывается что данный процесс должен обеспечить своевременный и надлежащий сбор, создания, распределение, хранение, поиск, управление, мониторинг и окончательное распоряжение проектом на основе информации. Главная цель этого процесса заключается в том, что он обеспечивает эффективный и результативный информационный поток между командой проекта и заинтересованными сторонами.
Затрагивая процесс Мониторинга коммуникаций (Monitor Communications), в книге отмечается, что определяет, дали ли запланированные коммуникационные правила, инструменты и мероприятия желаемый эффект для проекта и вовлечённости и информированности заинтересованных сторон, результатов проекта. Процесс мониторинга коммуникаций может инициировать изменения процессов управления и/или плана коммуникаций для повышения их эффективности с помощью дополнительных действий и инструментов. Такие действия иллюстрируют непрерывный характер в процессах управления коммуникациями проектов. За основу можно брать информацию из рисков и отклонения от ключевых показателей.
Что бы принимать решения о внутри процесса «мониторинга коммуникаций» РП может использовать – экспертное мнение, информационную систему управления проектами, встречи с членами команды и стейкхолдерами.
Если же обратиться к PMBOK 7-й версии, то в первые про коммуникации мы узнает, в Stakeholder Performance Domain5, который как раз фокусируется на результате в виде эффективных и продуктивных взаимоотношений с заинтересованными сторонами и описывает что Планирование коммуникаций плотно пересекается с идентификацией, анализом, приоритизацией и вовлечением заинтересованных сторон. Речь там идёт в первую очередь о диалоге, управлении ожиданиями, активном слушании. Цель – не отправить отчет, а обеспечить поддержку и совместную работу. Важно не "что сказали", а "что поняли и как отреагировали".
В Team Performance Domain: Коммуникации – это основа командной работы. Сюда попадают ежедневные стендапы, ретроспективы, чаты, обсуждения в Jira и других инструментах совместной работы. Цель – создать открытую среду для обмена идеями, решения проблем и быстрой обратной связи.
В Delivery Performance Domain: Коммуникации – это способ демонстрации ценности и получения обратной связи. Демо-сессии, инкременты продукта, обсуждение требований с пользователями – все это формы коммуникаций, нацеленные на создание нужного результата.
Теперь самое время взглянуть на самую современную версию книги. Главная парадигма PMBOK 8 – управление коммуникациями больше не представлено как отдельный домен или область знаний. Теперь оно является неотъемлемой частью работы с заинтересованными сторонами (стейкхолдерами). И такой подход кажется логичным – коммуникации становятся средством вовлечения стейкхолдеров и достижения цели проекта. Цель – не отправить отчет или письмо, а обеспечить поддержку и совместную работу. Важно не "что сказали", а "что поняли и как отреагировали". Поэтому руководителю проекта в PMBOK 8 важно не просто "рассылать информацию", а выстраивать целенаправленное взаимодействие не только непосредственно с заказчиками, но и командой, чтобы обладать всей необходимой информацией для формирования сообщений для стейкхолдеров.
Если кратко подвести «Итого» о сравнении 6, 7 и 8 версии:
– В PMBOK 6 коммуникации выступает в первую очередь как "механическая" функция управления – отправил формальный отчёт по правильному каналу, в нем все пункты плана соблюдены, просрочки нет – все выполнено правильно, и не смотрим какой результат получен отправкой этого отчёта, кто с ним ознакомился и куда ещё передал, какие решения на основе этой информации принял.
В PMBOK 7 произошло смещение с описания процессов (что делать) на описание результатов (чего нужно достичь, и речь в основном идёт о диалоге, управлении ожиданиями, активном слушании).
В 8-й редакции коммуникации – это суть взаимодействия в первую очередь со стейкхолдерами, но которое невозможно без корректно выстроенных взаимодействий внутри команды.
Если обратиться к Agile фреймворкам на ум как правило приходят 2 книги – Scrum Guide и Kanban Guide. По начала кажется, вот тут как раз про коммуникации будет всего много, и очень подробно расписано, как гибко все настраивать и достигать целей.
Но, увы все не так просто. Если взять официальную версию Scrum Guide 2020 года6 то слово коммуникация (communication) встречается всего 5 раз. Но уже погрузившись в правила игры, разобравшись как работает механика Scrum – понимаешь, насколько важны коммуникации для решения задач проекта. Ответственность распределена между ролями (Владелец продукта, Scrum мастер, команда) и глубоко прошита в структуре фреймворка.
Владелец продукта (Product Owner) в области коммуникаций выполняет роль главного переводчика, переговорщика и рассказчика истории продукта. Его ключевые коммуникационные задачи:
– Трансляция видения продукта (про неё чуть ниже): Постоянно доносит и разъясняет его команде и стейкхолдерам, чтобы все двигались в одном направлении.
– Управление ожиданиями стейкхолдеров: Активно собирает обратную связь, объясняет приоритеты и "что будет дальше", балансируя между различными запросами.
– Создание и разъяснение артефактов: Формулирует элементы бэклога (User Stories) как "мини-договоры" о ценности, проводит их обсуждение (Backlog Refinement), делая требования понятными для команды.
– Фасилитация ключевых событий: Является центральным докладчиком на Sprint Review (Demo), представляет инкремент и ведет диалог о будущем продукта. Участвует в Sprint Planning, чтобы суметь сформировать и донести цель спринта до команды.
– Принятие решений и обратная связь: Четко и оперативно отвечает на вопросы команды, принимает финальные решения о готовности работы и приоритетах, обеспечивая непрерывный поток разработки.
Таким образом, Владелец продукта – это коммуникационный хаб между бизнесом, пользователями и командой разработки, ответственный за то, чтобы ценность продукта была понята, принята и реализована. От его знаний и умений в области коммуникаций всецело зависит результат проекта, его восприятие заказчиками, будущее продукта и показатели эффективности и доходности.
При этом важно понимать, что человек с ролью Scrum Master не управляет коммуникациями сверху, а обслуживает и улучшает коммуникационную экосистему команды, чтобы она могла сама достигать максимальной прозрачности и слаженности.
Из вышесказанного можно сделать справедливый вывод – обмен информацией становится двигателем прогресса и прироста ценности продукта, а артефакты Scrum— это источник единой правды. Назначение артефактов – сделать все процессы Scrum прозрачными и видимыми не только для тех, кто выполняет работу, но и для тех, кто принимает решения.
Обязательно кратко надо затронуть такой артефакт как Product Vision (Видение продукта) – это критически важная сущность в Scrum, хотя в Scrum Guide он прямо не упоминается. Он действует как стратегический фундамент, на котором строится вся работа команды по фреймворку Scrum.
Является кратким, вдохновляющим и долгосрочным описанием будущего состояния продукта, его главной цели и ценности, которую он принесет пользователям и бизнесу. Это ответ на вопросы:
Видение продукта помогает принимать стратегические решения и расставить приоритеты в Product Backlog. А ещё мотивирует и объединяет команду: Дает членам команды чёткое понимание глобальной цели, за которую они каждый день борются приходя на работу. Владелец продукта формирует этот артефакт совместно с ключевыми бизнес-стейкхолдерами, инвесторами или лидерами, и так же несет ответственность за его ясность и актуальность.
На мой взгляд в коммуникациях в SCRUM самым важным артефактом является инкремент – это материализованное, неоспоримое сообщение, которое команда отправляет миру. В отличие от слов, презентаций, или отчетов о "проценте готовности", инкремент – это самый честный и прозрачный канал связи.
Порой, одна функция (например, какая-нибудь новая кнопка в работе программного обеспечения) инкремента ИТ продукта может нести сразу несколько сообщений:
– Владельцу продукта и бизнесу: Важная гипотеза уже проверена и реализована в рабочем коде.
– Команде: Все части продукта слаженно работают вместе и продукт не «упал», не выявили скрытых багов.
– Стейкхолдерам: Команда выполнила серьёзный пласт работы и можно планировать следующие шаги.
– Пользователям: что новая функция протестирована на определённом круге версий устройств и операционных системах, что можно её брать и безбоязненно использовать – извлекать ценность.
В целом основные коммуникации внутри SCRUM – это личностные общения, как правило в голос, без сложных переписок и формальностей, до тех пор пока это не требует регламент или требования контракта.