Сергей Барамба
Мастерство коммуникаций: Принципы, интерфейсы и секреты эффективности

Введение

Дорогой читатель, спасибо за выбор этой книги.

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

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

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

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

Приятного чтения, ваш Сергей Барамба.

Словарь терминов и сокращений приведённых в книге

РП– руководитель проекта

Стейкхолдер – заинтересованная сторона проекта

Канал связи – конкретный инструмент, который используется для передачи информации. Например, Email или телефонный звонок.

PMBOK – Project Management Body of Knowledge

SCRUM– гибкая методология совместной командной работы, широко используемая в разработке программного обеспечения и других отраслях для адаптивного решения комплексных проблем

Kanban – это agile-методика, которая визуализирует работу, ограничивает объем незавершенной работы и поддерживает непрерывное улучшение за счет прозрачности рабочих процессов.

Тикетная система – информационная система в которую вносятся заявки и обращения пользователей необходимая для фиксации информации по поддержке проекта.

Аналоговый документ или Твердая копия – бумажная форма документа.

Life-hack – хитрость или полезный совет, помогающий эффективно решить ту или иную проблему

Скрипт – это заранее подготовленный, структурированный текстовый шаблон для типовой ситуации.

Глава 1. Определение коммуникаций. Основные документы для управления коммуникациями.

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

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

На мой взгляд литературу можно поделить на 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)²

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

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

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

В 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 года⁴ то слово коммуникация (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 GUIDE⁵ от мая 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       (Стратегический обзор) – Переоценка и корректировка стратегии на основе обратной связи от рынка и операционной деятельности.

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

Место руководителя в вопросе управления коммуникациями – его права, полномочия и обязанности

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

У руководителя проекта в области коммуникаций 4 базовых роли – «Техническая», «Юридическая», «Финансовая» и «Организационная»

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

В техническую роль входят следующие важные задачи:

– Проектирование коммуникационной архитектуры:

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

Поэтому он должен:

– определить оптимальные каналы связи (точное название мессенджеров, которые будут использоваться, будет ли участвовать в процессах электронная почта, в какой конкретно системе управления проектами будет работать команда, в какой среде будeт проходить видеоконференции) с учётом специфики задач и распределённости команды;

– определить, описать и задать для команды и стейкхолдеров правила маршрутизации информации: кто, кому, в каком формате и в какие сроки передаёт данные;

– должен разработать схему интеграции инструментов (например, синхронизация тикетной системы с календарём и уведомлениями).

– Формирование правил ведения дискуссий, форматы описания задач, фиксации исполнения и подтверждения заказчиком.

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

– Стандартизация форматов и процессов: РП должен заранее позаботиться и создать шаблоны документов, отчётов, протоколов встреч. Он описывает и должен строго следить что соблюдаются правила оформления сообщений (обязательные поля, теги, приоритеты). И конечно, устанавливает периодичность и формат статусов (ежедневные митапы, еженедельные сводки).

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

– Техническая поддержка команды и инструментов: РП не просто должен организовать обучение по работе с инструментами (инструкции, вебинары, ответы на вопросы), но постоянно разрешать запросы и инциденты: восстановление доступа, настройка уведомлений, устранение конфликтов ПО;

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

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

Ключевые задачи:

– Нормативное регулирование коммуникаций: РП должен определить перечень юридически значимых видов коммуникаций (официальные письма, протоколы, акты, уведомления). Так же он закрепляет в проектной документации (устав, план коммуникаций) правила оформления, подписания и хранения корреспонденции;

– Контроль документооборота: РП назначает ответственных за подписание и отправку официальных документов, и обеспечивает соблюдение порядка согласования (визирования) корреспонденции. Ещё в задачи документооборота входит организация архивного хранение переписок и документов с учётом сроков исковой давности и требований к доказательной базе.

– Соблюдение требований конфиденциальности: РП должен обеспечить внедрение и исполнение процедуры подписания NDA и соглашений о конфиденциальности. Конечно нельзя забывать, что РП должен определить правила и инструменты передачи чувствительной информации (шифрованная почта, защищённые каналы).

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

– Обучение команды правовым аспектам: РП должен озаботиться в вопросе проведения инструктажей по правилам деловой переписки и публичным выступлениям. Если этого не сделать, есть риск, путаницы и решения задач обмена информации удобным, но неправильным способом или с использованием неправильных получателей информации. В этих инструктажах РП надо обязательно включать разъяснения последствия нарушений (штрафы, репутационные риски, судебные иски), что бы коллеги понимали стоимость ошибок.

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

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

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

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

В большинстве проектов в обязанности руководителя проекта в области управления коммуникациями сводятся к следующему:

– Разработка и внедрение плана коммуникаций: определение основных направлений и целей коммуникационной политики компании, формирование документа.

– Обеспечение прозрачности и открытости: создание условий для свободного обмена информацией между всеми участниками проекта.

– Контроль исполнения: мониторинг выполнения требований плана коммуникаций и оценка их эффективности.

– Управление информационными потоками: оптимизация информационных потоков внутри команды проекта, предотвращение информационной перегрузки сотрудников.

– Координация с внешними стейкхолдерами: поддержание и развитие связей с партнёрами, клиентами и другими заинтересованными сторонами.

– Обеспечение соблюдения законодательства, например требований об обработке персональных данных.

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

Одна из важных задач в организационной роли управления коммуникациями – определить, какие инструменты будут использоваться:

– для общения командой;

– для общения один на один;

– для оповещений;

– для предоставления отчетов;

– для хранения информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– оптимизировать количество интерфейсов;

– использовать интегрированные решения, объединяющие несколько коммуникационных каналов в одном окне или приложении;

– провести обучение участников проекта.

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

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

Далее по тексту будут использоваться термины Сторона «А» – руководитель проекта и Сторона «B» – любой другой участник общения.

Теперь поговорим о цвете коммуникаций. Это понятие достаточно относительное, и связано с количеством энергии, которую затрачивается для создания, последующей передачи сообщения и получение «результата» от такой передачи. В целом я выделяю 4 типа коммуникаций: Зелёные, Жёлтые, Синие и Красные (рис.1.2).

Рис.1.2 Цвет коммуникаций

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

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

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

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

Начальные коммуникации имеют «Жёлтую» окраску и явно прослеживаются, когда стиль взаимодействия со Стороной “B” ещё не сложился и пробуются различные каналы связи и варианты тональности общения чтобы выработать определённый стиль. Тут возможны ошибки с обеих сторон, возможные перегибы на местах.

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

Возможные переходы:

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

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

Вернуться

2

A Guide to the Project Management Body of Knowledge (PMBOK® GUIDE)

Sixth Edition, 2017 Project Management Institute

Вернуться

3

Stakeholder Performance Domain (Область результатов, связанная с заинтересованными сторонами) – это одна из восьми Областей результатов (Performance Domains), которые представляют собой группы связанных видов деятельности, критически важных для эффективного выполнения работы в проекте. Если просто, то это не процесс, а сфера внимания, в которой проектная команда должна демонстрировать высокие результаты на протяжении всего жизненного цикла проекта.

Вернуться

4

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf, English (November 2020) – Official Current Version      Ken Schwaber & Jeff Sutherland

Вернуться

5

https://kanbanguides.org/the-kanban-guide/2025.5/pdf/kanban-guide.v2025.5.en.pdf

Вернуться

6

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

Вернуться

7

Ильф и Петров, 12 Стульев, Глава XII. Знойная женщина – мечта поэта.

Вернуться

8

Keep satisfied – Поддержание состояния удовлетворённости.

Вернуться

9

Face-to-Face – анг, лицом к лицу

Вернуться