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

Активные и пассивные коммуникации.

Одним из важных принципов управления проектами является то, что РП должен использовать все доступные ему ресурсы для достижения целей проекта. На фазе инициации и потом последующего планирования для большинства проекта РП должен заполнить отдельный документ «План коммуникаций» проекта. В каждой компании форма данного документа разнится, но в целом стандартные поля табличной части «Средство коммуникации», «Получатели», «Отправитель» и «Частота» - включает по подсознании необходимость описать в документе только активные события – совещание, рассылку отчёта или договора, проведение собрания. Такие «Активные» коммуникации работают только в момент обмена информацией между «Отправителем» и «Получателем». При исполнении плана на этих «активностях» и концентрируется РП, совершенно забывая о возможности использовать ещё и «Пассивные» коммуникации для донесения сообщений до членов команды проекта, стейкхолдеров и других вовлечённых и не очень сторон.

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

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

Примерами пассивных коммуникаций могут быть:

-Распечатка, на которой описан алгоритм действий по созданию важного документа и его согласования (например, создание авансового отчёта после командировки и получения денежных средств)

-Стенгазета с новостями проекта

-Бумажная дорожная карта продукта

-Правила и договоренности о принципах работы внутри команды, так называемый «Устав команды»

-Распечатка со словами благодарности конкретному сотруднику от коллег или заказчиков, прикреплённая на стену рядом с рабочим местом этого сотрудника.

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

-Инструкция как на МФУ отсканировать и отправить себе на почту документ повешенная на стену рядом с ним.

-Размещённая на оборудовании карточка о том, что данное устройство не работает и как воспользоваться альтернативным способом.

- Стенд с грамотами и призами.

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

Грамотное использование комбинации «активных» и «пассивных» коммуникаций позволяет РП контролировать насыщенность информационного поля и с меньшими затратами энергии достигать необходимых результатов.

Фреймы «Нападение» и «Защита»

Мне кажется уместным будет затронуть определённую тональность коммуникаций, и я выделяют два типа – «Обвинительные» и «Оборонительно -доказательные».

Обвинительные – это акт агрессии со стороны автора, нападение. И самое важное и главное, то, что выступая первым, для него сбор доказательной базы или фактов не обязателен. Можно в диалоге использовать широкоформатные значения в формуле – «Всегда», «Постоянно», «Проблема точно на вашей стороне», «Такие вопросы в вашей зоне ответственности». Главное выступить первым, можно, а иногда даже нужно использовать "полемику"1.

Оборонительно-доказательные – тут уже нападение невозможно, потому что вступаешь в диалог вторым. Глупо играть в "Сам дурак".2 В такие моменты участник диалога оказывается загнан в определённый фрейм нападением, и чтобы корректно из него выйти, приходится играть по правилам, заданным нападающей стороной. Сначала надо подготовить взвешенный ответ, дополнить его всеми необходимыми фактами, подтверждающими или опровергающими обозначенную ранее претензию. Такие коммуникации выражаются огромным количество энергии, которая требуется на сбор доказательной базы (собрать таблицу, внести значения, опросить коллег, чтобы доказать, что задача решается корректно, все параметры учтены, и результат будет достигнут в срок).

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

Чтобы выйти с минимальными потерями из состояния Оборонительно-доказательного диалога, важно строго отвечать на суть претензии, не давать нападающей стороне никакой излишней информации, которую можно будет снова использовать для дополнительного нападения, а значит новой работы. Поэтому лучше всего выбирать стратегию «Keep satisfied»3. В Главе 3 в разделе «Коммуникации в моменты претензий к команде проекта» мы детально обсудим алгоритмы поведения и варианты ответов.

О «черной» и «белой» магии

Все рекомендации из личного опыта со можно разделить на «белую» и «чёрную» магию.

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

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

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

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

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

Сборники заклинаний белой магии написаны пачками и о них рассказывается на любом курсе по проектному управлению. Приёмы чёрной магии как правило передаются из уст в уста руководителями проектов или обретаются на собственном опыте. Не все рецепты, из тех, что приносят результат одному руководителю, подойдут его соседу. В других главах я поделюсь с вами несколькими рецептами заклинаний и ритуалов «чёрной» магии в управлении коммуникациями, стейкхолдерами и командой.

Продукт, Проект, Доработка: что есть что и как не перепутать

В ИТ-сфере эти три термина часто путают. А путать их опасно — потому что для каждого нужны разные подходы, разные команды и разные бюджеты.

Разработка продукта — это путь от идеи до финальной версии, готовой к использованию.

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

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

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

Доработка («сопровождение», «эксплуатация», «сопровод») — это поддержка и развитие уже существующего продукта. Сопровод — это не проект. Это операционная деятельность. Она повторяющаяся, циклическая, предсказуемая. В сопровождении вы не создаёте ничего принципиально нового — вы чините, обновляете, оптимизируете.

В ИТ-компаниях есть два подхода к сопровождению. Одни делают его проектом (закрывают этап, подписывают акты и переходят к следующему). Другие — процессом (поддержка идёт непрерывно). Какой подход выбрать — зависит от стратегии компании.

Почему это важно для руководителя проекта.

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

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

Что пишут про коммуникации книги по управлению проектами

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

На мой взгляд литературу можно поделить на 2 стопки, как и существующие подходы к управлению проектами – традиционную и Agile.

В традиционных методах управления проектами детально описывается в библии для руководителей – PMBOK. На мой взгляд сейчас существует 2 актуальных версии –«шестая» или «седьмая». PMBOK 8 - вышедшая в ноябре 2025, на момент написания книги, ещё не поступила в магазины и не доступна широкой общественности.

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

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.