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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– В Зелёные коммуникации, если все получилось по плану.

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

Мастерство РП проявляется в нахождении «подходящих» положений внутри документов или топ-менеджеров, толковании в свою пользу и эксплуатация в интересах проекта.

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

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

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

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

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

В процессе диалога во время «красных» коммуникаций на ваш вопрос вместо ответа получаете обратно ряд других вопросов.

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

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

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

Возможные переходы: Зелёный, если удалось преодолеть коммуникационные барьеры и изменить субъективное мнение о себе и проекте.

Коммуникации между членами команды и через сервисно-процессные отношения.

Работая над проектом, у РП есть возможность применять только два подхода к взаимодействию для постановки и контроля задач и получения результата:

– Делегирование и контроль

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

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

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

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

Как я писал ранее6 внутри команды проекта возможны активности двух типов:

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

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

В процессно-сервисных в среде исполнителей выделяют следующие роли:

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

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

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

Рис.1.3. Процессно- сервисные отношения

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

Поэтому в таких отношениях выделяют две управляющие роли «Менеджер процесса» и «Владелец процесса»

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

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

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

– состав уполномоченных для создания новой задачи;

– сроки выполнения;

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

– канал связи, по которому должна поступать задача;

– цепочка согласования.

Как правило, РП, для ускорения достижения целей и упрощения работы, согласовывает упрощённый формат и более приоритетную обработку. Вот несколько примеров:

– Разрешение брать на исполнение задачу по оплате счета только по устному согласованию ГД переданному РП через email, не дожидаясь визы в специальной системе;

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

– Выдавать оборудование со склада членам команды в день формирования запроса, а не на следующий рабочий день;

– при контроле посещаемости не учитывать приход и уход с работы из системы СКУД для членов команды проекта.

Для того что бы легитимизировать7 новые правила работы с функциональным подразделением, необходимо что бы владелец процесса внёс необходимые изменения в уже налаженные процессы. Как правило процесс изменения в документах и инструкциях имеет регламентированный способ внесения предложения, рассмотрения и публикации новой версии. Надо иметь в виду, что для РП должно быть не важно, как это произойдёт – будет написанная новая версия регламента или будет достаточно e-mail в котором будет указано что все заявки от команды принимать в особом формате. Главное, чтобы в следующий раз, когда он или член команды проекта обратиться к специалистам с новой задачей, то она будет обработана в рамках новых параметров. Важно помнить, что изменения условий должны касаться только обращений со стороны членов команды проекта, а не всей компании в целом.

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

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

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

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

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

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

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

В 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 года10 то слово коммуникация (communication) встречается всего 5 раз. Но уже погрузившись в правила игры, разобравшись как работает механика Scrum – понимаешь, насколько важны коммуникации для решения задач проекта. Ответственность распределена между ролями (Владелец продукта, Scrum мастер, команда) и глубоко прошита в структуре фреймворка.