Триединство проекта: Стейкхолдеры, Команда, Коммуникации

PMBOK 7-й редакции 2021 года – которая отказалась от процессов в пользу 12 принципов, 8 доменов эффективности. Фокус в ней сместился на "что" и "почему" успешного управления проектами. При этом в отличии от процессов – принципы не предписывают, а направляют мышление и поведение. Например, принцип – «Сосредоточиться на ценности» (настоящая цель – полезный результат, а не просто "выходные данные" (outputs)).

В свою же очередь PMBOK 8-й редакции – это не революция, а скорее эволюция, которая объединяет лучшее из 6-й и 7-й версий. Она гармонично сочетает гибкие принципы из 7-й версии с четкой структурой, возвращая процессный подход в обновленном, более адаптивном формате. В составе этой редакции – 6 принципов, 7 доменов, 5 областей фокусировки, 40 процессов. Сразу чувствуется что революционный подход в «семерке» – вызвал среди руководителей определённые конфликты, и нехватка описания процессов, не позволяла легко и просто перестроить мышление при работе над проектом по новой методике. Ключевое отличие в мышлении которые формируют подходы книг разных версий можно выразить следующими формулами:

– PMBOK 6: "Я выполнил план коммуникаций".

– PMBOK 7 и 8: "Через хорошо настроенное взаимодействие команда работает слаженно, а ключевые стейкхолдеры понимают прогресс, разделяют наши цели и готовы оказывать поддержку ".

Но давайте обо всем по порядку.

Изучая PMBOK версии 6 руководитель проекта сталкивается с детальными описаниями трёх процессов связанных с коммуникациями:

Планирование коммуникаций (Plan Communications)

Управление коммуникаций (Manage Communications)

Мониторинг коммуникаций (Monitor Communications)4

Давайте кратко пробежимся по тезисам, которые описываются в данном разделе:

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

В целом в PMBOK выделяют (но не ограничиваются) следующие формы коммуникаций:

– Внутренние (Internal) – сфокусированные на взаимодействии со стейкхолдерами внутри проекта и внутри организации. Хотя в привычном для нашей российской культуры виде, внутренние коммуникации подразумевают общения только между членами команды проекта, когда информация не становится доступной внешним, по отношению к команде проекта, участникам или стейкхолдерам, без разницы работают ли они в нашей компании или нет.

– Внешние (External) – сфокусированные на внешних стейкхолдерах, таких как заказчики, поставщики, другие проекты организации, правительство и общественность.

Официальные (Formal) – отчёты, официальные собрания (регулярные и по необходимости), презентации, пресс-релизы.

– Неофициальные – взаимодействия в основном с помощью email, чатов, социальные сети, вебсайты и различные дискуссии и собрания по необходимости. От себя, хотел бы подсветить, то, что в Российской действительности, в отличии от книги, все что пересылается e-mail и информация на официальном сайте Компании или доступном в сети интернет сайте проекта, признается «протоколируемой» информацией, и носит характер официальной. Чуть позже в книге мы затронем техническую сторону коммуникаций и как РП определяет какие инструменты будут признаваться официальными при общении, а какие будет нельзя использовать в качестве сущности для взятия в работу и как доказательную базу в спорных ситуациях.

Ещё в книге сказано, что коммуникации бывают – письменные (written) и голосовые (oral).

При этом, обязательно выделяется не просто вербальное общение – слова и особенности речи, но и невербальные – язык тела и жестикуляция.

Говоря про Планирование коммуникаций (Plan Communications) указывается основывается на базовых документах – План управления ресурсами и План вовлечения стейкхолдеров (Resource management plan и Stakeholder engagement plan).

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

В разделе посвящённому Управлению коммуникациями (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 – это личностные общения, как правило в голос, без сложных переписок и формальностей, до тех пор пока это не требует регламент или требования контракта.

При этом вербальные коммуникации сосредоточены в первую очередь на диалогах во время событий:

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

–Daily Scrum: Краткий устный синхрон команды (формат 3-х вопросов – лишь пример).

–Постоянное обсуждение: Неформальные обсуждения между Владельцем продукта и Командой о бэклоге.

Важное правило – Все общение должно быть направленным на самую важную цель (фокус на ценность) и основанным на фактах (прозрачные артефакты), а не на предположениях.

Теперь перейдём к другому популярному фреймворку – KANBAN. Фундаментальной книгой по данному подходу к управлению проектами является THE KANBAN GUIDE7 от мая 2025 года. Что интересно, но слово коммуникации (communication) в данной книге встречается 0 (ноль) раз. Хоть коммуникации не описаны как отдельная практика, они являются естественным следствием применения метода, и это мы увидим ниже.

Вместо предписанных встреч Kanban встраивает коммуникацию в саму систему работы, делая её более асинхронной и визуальной. Это достигается через три основные практики, которые прямо или косвенно формируют коммуникацию:

Визуализация рабочего процесса (Kanban board): Доска служит единым источником правды, заменяя статусные встречи. Прогресс, ответственные и блокировки видны всем моментально.

Сделать политики явными: Чёткие правила (критерии "готово", лимиты WIP) создают общее понимание, уменьшая необходимость в согласованиях и уточнениях.

Управление потоком и обратные связи: Лимиты незавершённой работы (WIP) и метрики потока (например, время цикла) выступают как невербальные сигналы, указывающие на проблемы, которые нужно обсудить.

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

В отличие от Scrum где типов встреч не так много, в канбан их аж 7:

1.Ежедневно – Daily Standup / Kanban Meeting (Ежедневный стендап) –      Короткая синхронизация команды для устранения блокеров и поддержания потока работ.

2. Еженедельно – Replenishment Meeting (Встреча пополнения) - Отбор новых задач из бэклога для выполнения с учетом приоритетов и доступной мощности команды.

3. По мере необходимости Delivery Planning Meeting (Встреча по планированию поставки)      – Координация сроков поставки, синхронизация зависимостей и планирование релизов.

4. Раз в две недели – Service Delivery Review (Обзор предоставления услуги)– Оценка удовлетворенности клиентов и соответствия работы их ожиданиям и целям организации.

5. Ежемесячно – Risk Review (Обзор рисков)       – Выявление и смягчение потенциальных рисков, угрожающих срокам, качеству или стабильности потока.

6. Ежемесячно или раз в два месяца – Operations Review (Операционный обзор) – Анализ и улучшение взаимодействия между командами и сервисами для глобальной оптимизации потока.

7. Ежеквартально – Strategy Review       (Стратегический обзор) – Переоценка и корректировка стратегии на основе обратной связи от рынка и операционной деятельности.

Все они создают систему обратной связи для управления потоком работы и её постоянного улучшения.

Интерфейсы коммуникаций и их цвет.

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

Некоторые из таких интерфейсов уже есть в Компании и РП только остаётся придерживаться правил использования, а другие предстоит найти и эффективно использовать внутри проекта.

В основном интерфейсы коммуникации в проектах делятся на внутренние и внешние.

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

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

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

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

Управление коммуникациями тесно связано с процессом управления конфликтами, потому что разрешение конфликта происходит с использованием одного из интерфейсов.

Помимо направлений обмена информации относительно команды (внешние и внутренние) интерфейсы можно типизировать следующим образом:

1. Аналоговые:

1.1 Face-to-Face8 встречи – старая как мир, привычная встреча или совещание.

1.2 Твёрдая копия – бумажный документ играющий важное значение для проекта.

1.3 Доски, флипчарты, стенды – любые инструменты на которых нанесена информация и используется для реализации проекта.

2. Электронные:

2.1 Инструменты совместной работы – в них члены команды и внешние участники могут одновременно работать над документами и данными – примерами таких инструментов могут облачные редакторы документов и таблиц.

2.2 Точка входа в команду – это клиентские порталы, форумы для пользователей, Тикетная система.

2.3 Хранилище знаний и информации – это база знаний куда вносит информацию все члены команды и где аккумулируются различные данные о проекте.

2.4 Инструменты мгновенного обмена информацией – привычные в работе мессенджеры, чаты.

2.5 Программные решения для обеспечения видеоконференции (ВКС)

2.6 Система управления проектом – место, где находится расписание проекта, доступные ресурсы, члены команды видят свои задачи и отмечают прогресс по их выполнению.

2.7 Поддерживающие и регламентирующие системы – например, финансовая система Компании, где обязаны работать все сотрудники или тикетная система другого отдела компании, через которую возможно общение и постановка задач. Сюда же входят «общесправочные» системы (например, правовые) и новомодные «чат-боты с искусственными интеллектом».

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

Рис. 1.1 Решаемые задачи коммуникационными интерфейсами

В поле «Решаемая задача» РП указывает конкретные задачи, с которыми могут столкнуться члены команды в рамках проекта. Такими задачами могут быть:

– Фиксация и обработка обращений пользователей и клиентов

– Ведение внутренней документации и сохранение накопленных знаний

– Согласование различных документов среди сотрудников

– Постановка и отслеживание проектных задач членам командами

– Работа с электронной почтой, календарем, контактами

– Проведение видеоконференций

– Получение информации о требованиях действующего законодательства

– Ведение финансовой информации, учет перемещения оборудования на складах

– Сетевое хранение файлов и документов

В поле «Ссылка на ресурс» может быть приведено не только указание на расположение дистрибутива, но и инструкции по работе с ним.

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

Например, для инструмента «Фиксация и обработка обращений пользователей и клиентов» критериями эффективной работы могут быть:

– Все обращения клиентов о продукте проекта фиксируются в данном инструменте.

– В инструменте доступно достаточное количество лицензий для пользования системой необходимому количеству специалистов.

– Члены команды ознакомлены с Памяткой по эффективной работе в тикетной системе расположенной по ссылке

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

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

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

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

4. Сложности в отслеживании и анализе коммуникации. С увеличением количества интерфейсов усложняется отслеживание и анализ коммуникации в проекте. Это может затруднить выявление проблем, оценку эффективности коммуникации и внесение необходимых корректировок.