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

Введение

Дорогой читатель,

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

Многолетняя практика и обучение других показали мне одну простую, но часто игнорируемую истину: успех проекта определяется не столько диаграммами Ганта или техническим гением, сколько людьми и тем, как они взаимодействуют.

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

Стейкхолдеры. Мы часто сводим работу с ними к формальному заполнению матрицы в уставе, которая потом благополучно забывается. В суматохе оперативных задач на них "не хватает времени". А ближе к сдаче мы с удивлением спрашиваем: "Почему заказчик недоволен?" Работа становится реактивной, эмоциональной и порождает риски. Первая часть книги — это ответ на вопрос: как превратить хаотичное "тушение пожаров" в системную стратегию взаимодействия со всеми, от кого зависит твой проект.

Команда. Даже имея блестящий план по стейкхолдерам, ты ничего не сделаешь без слаженной команды. Но как превратить группу специалистов в единый организм, где есть доверие, ответственность и общая цель? Как не просто "ставить задачи", а вести команду к результату, преодолевая внутренние барьеры? Вторая часть книги — это практика создания и ведения команды, которая не просто исполняет, а достигает.

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

Раньше я разбирал эти проблемы по отдельности — в трёх разных книгах: "От барьеров к результатам…", "Проектная команда под контролем…" и "Мастерство коммуникаций…". Они и сегодня остаются на платформе, каждая из них по-прежнему эффективно закрывает конкретную, точечную потребность. Однако постоянные вопросы от читателей и коллег о том, как связать эти практики воедино, показали главное: необходима целостная система. Так и родилась идея этого сборника — не просто объединить тексты, а переработать и соединить их в единую методологию, где всё работает на общий результат. Жизнь проекта не делится на изолированные блоки. Когда вам нужно не просто "прокачать навык", а получить работающий механизм, где работа с командой напрямую вытекает из стратегии для стейкхолдеров, а та, в свою очередь, построена на мощном коммуникационном фундаменте, — эта книга станет вашей инструкцией.

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

За 15 лет управления проектами я перепробовал десятки подходов, проанализировал успехи и провалы — свои и чужие. Я изучил горы литературы, которая часто говорит что делать, но умалчивает как — в конкретной, сложной, "человеческой" ситуации. Моя задача — дать тебе не просто теорию, а практическую систему: чёткие алгоритмы, приёмы и принципы, которые можно применить здесь и сейчас в твоём текущем проекте.

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

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

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

Раздел 1. Фундамент: Мастерство коммуникаций

Введение к разделу

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

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

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

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

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

Главная ловушка, которую вы должны видеть с первого дня

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

В профессиональной среде это называется разрывом между Output и Outcome.

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

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

Я приведу реальный пример с одного из моих проектов. ERP-система на базе 1С. Топ-менеджеры жаловались, что массовое согласование заявок идёт слишком медленно — 10-15 секунд на пачку. Команда провела исследование, оптимизировала код, диски, процессы. И добилась впечатляющего результата: скорость выросла в три раза. Пачка заявок теперь согласовывалась за 3-4 секунды.

Мы получили блестящий Output. Отчёт был красивый, цифры убедительные. Мы были уверены, что заказчик будет счастлив.

Но когда мы спросили у топ-менеджеров: "Ну как, стало быстрее?", они ответили: "Нет. Ничего не изменилось. Всё так же медленно". Мы не получили ожидаемого Outcome. Мы не попали в его ожидания. Он ждал не трёхкратного, а десятикратного ускорения. Чтобы система работала "мгновенно", а не просто "быстрее, чем было".

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

Откуда берётся такая ловушка? Мы часто анализируем только то, что видим, и общаемся только с теми, кто к нам пришёл. Это называется "ошибка выживших". Как в истории с американскими бомбардировщиками во Второй мировой войне. Военные изучали повреждения на вернувшихся самолётах, чтобы решить, какие части бронировать. Они смотрели на пробоины и думали: "Здесь нужно усилить защиту". Но один математик сказал: "Вы анализируете самолёты, которые выжили. Тех, что не вернулись, нет в вашей выборке. Укреплять нужно те места, где на вернувшихся самолётах нет повреждений. Потому что самолёты, получившие попадания в эти места, не долетели обратно".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Признаки хорошего хозяина: Чего ждут от руководителя проекта

В PMBOK есть важный принцип: "Будьте прилежным, уважительным и заботливым управляющим" (Stewardship). Что это значит на практике? Каким должен быть руководитель проекта, чтобы его можно было назвать "хорошим хозяином" проекта?

Я не придумывал этот список за своим столом. Он родился в живых обсуждениях — на тренингах, в рабочих группах, на ретроспективах с командами проектов. Я просто задавал один и тот же вопрос разным людям: "Представьте идеального руководителя проекта -хозяина. Каким вы его видите? Что он делает? Как он выглядит?"

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

Признак первый. Точно знает границы своей зоны ответственности.

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

Признак второй. Точно знает, что есть в его хозяйстве.

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

Признак третий. Знает, что происходит в его хозяйстве.

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

Я спросил: "А как заказчик узнаёт, что всё в порядке, если вы не даёте ему отчётов?" Он замолчал. Потом признался: "Я не даю ему отчётов. Я думал, он доверяет мне на слово".

Ошибка была очевидна. Заказчик не "дёргал" его — он искал информацию. РП создал информационный вакуум, и заказчик пытался его заполнить любыми способами.

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

Признак четвёртый. Не проходит мимо проблемы.

Однажды на ретроспективе команда рассказала мне историю. В их проекте уже полгода висела задача по обновлению драйверов на старом принтере. Она была с низким приоритетом, её никто не брал. А руководитель проекта проходил мимо этого принтера каждый день, видел табличку "Не работает" — и ничего не делал.

Команда не понимала: "Если ему всё равно, почему мы должны волноваться?"

Если хороший хозяин видит проблему — например, валяющийся кабель, который может кого-то задеть, — он или сразу убирает её, или вносит в план и приводит всё в порядок. Он не говорит: "Это не моя зона ответственности". Он говорит: "Это проблема, и её нужно решить". Даже если не он будет её решать — он убедится, что она попала в чей-то план.

Признак пятый. Имеет план.

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

Я не спрашиваю про идеальный план. Я спрашиваю: "У вас есть документ, по которому вы работаете? Вы его открываете? Вы знаете, что там написано?"

Хороший хозяин имеет план. В идеале — оцифрованный. Планы развития активов, регламентного обслуживания, закупок. Он следит за выполнением графика и своевременно корректирует его. План для него — не просто документ, а рабочий инструмент.

Признак шестой. Рационален.

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

"Мы потратили несколько миллионов на то, что нам не понадобилось", — сказал он. "И самое смешное, что руководитель проекта знал про это. Он просто не хотел спорить с командой".

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

Признак седьмой. Свои действия направляет на благо.

На тренинге я спросил группу: "Почему вы подчиняетесь своему руководителю?" Большинство ответило: "Потому что он начальник". И только один человек сказал: "Потому что я верю, что его решения ведут к цели".

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

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

Признак восьмой. Принципиален и проактивен.

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

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

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

Хороший хозяин не ждёт, пока проблема "придёт сама". Он предвидит риски и предотвращает их. Он не говорит: "Мы это потом сделаем". Он говорит: "Давайте сделаем это сейчас, пока не поздно".

Почему это важно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы выйти с минимальными потерями из состояния Оборонительно-доказательного диалога, важно строго отвечать на суть претензии, не давать нападающей стороне никакой излишней информации, которую можно будет снова использовать для дополнительного нападения, а значит новой работы. Поэтому лучше всего выбирать стратегию «Keep satisfied»³. В Главе 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)⁴

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Решаемые задачи коммуникационными интерфейсами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратная связь: подход COIN, типизация, векторы, направленность

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

В книге «Проектная команда под контролем: Как достигать результатов вместе» я уже описывал детально типизацию подходов по обратной связи - и её можно поделить на 3 различных типа - "Стрела", "Маятник с гвоздём", "Петля обратной связи"⁹.

Обещав, кому-то предоставить обратную связь вы можете сделать это двумя способами – сообщением и результатом, который станет виден «Стороне B», словно зелёная ракета, запущенная в небо, как только ты достиг вершины на той стороне. Это обратная связь без общения. Единственное условие, что форму такого сигнала надо оговорить заранее. При такой форме обратной связи отсутствует "Стороны А" и источником сигнала является не человек, а система (какой-либо тест + изменение какого-либо артефакта), что делает обратную связь абсолютно беспристрастной и авторитетной.

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

Формат обратной связи

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

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

Рис. 1.3. Формы обратной связи

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

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

- информирование о старте фазы проекта, к которому приступила команда проекта;

- о получении информации без обязательств - «принято».

- сообщение проведения регламентных работ в пятницу в 15.00. Мы не ждём что нам что-то пришлют в ответ.

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

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

«Маятник с гвоздем» – Это обычная задача из учебника физики за 9 класс, в которой на пути маятника на подвесе, движущегося вдоль стены вбит гвоздь и часть колебаний протекает вдвое быстрее из-за укорочения нити после контакта с гвоздем. На самом деле это задача двух маятников, которые движутся просто с разной амплитудой и скоростью, что как нельзя лучше характеризует данную форму обратной связи. Кстати, и затихает данный маятник быстрее. Такой обмен подразумевает предоставление нам ответа на выдачу нами обратной связи. Сначала мы проводим выдачу существенного объема предварительно и тщательно подготовленной информации (большое плечо маятника). При этом мы предполагаем возврат к нам обратно в одно-два предложения, без сильных затрат от стейкхолдера (короткое плечо маятника). Таким образом достигается уменьшение периода работы маятника.

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

Формами второго, малого, маятника от стейкхолдера могут быть:

- предоставление санкции на какие-либо действия: «Согласовано, действуйте»;

- подтверждение что зафиксированное в документе правильно нами было понято и можно использовать в рамках проекта - «да, с моих слов зафиксировано верно»;

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

- оценка выполненных нами качества расчётов и выкладок.

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

Последняя форма обратной связи – «Петля» же подразумевает полноценный, относительно равный обмен информацией между участниками. Это очень тесное взаимодействие, при этом как правило на равных. Поэтому, как правило возможно, между рядовыми членами команды и стейкхолдерами А и B уровней. Если сложились хорошо отношения между руководителем проекта и заинтересованной стороной С-уровня – очень важно провести время в полноценном обмене информацией.

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

Обратная связь по

COIN

Что бы лучше научиться давать обратную через сообщения, письменные или вербальные, хорошей практикой является применение предоставления обратной связи по COIN. Модель COIN — это акроним, последовательно описывающий четыре ключевых этапа предоставления обратной связи: Контекст (Context), Наблюдение (Observation), Влияние (Impact), Следующие шаги (Next steps).

С- Контекст: Цель — обозначить тему и ситуацию. Например, начать с фразы «Я хотел бы обсудить с тобой нашу вчерашнюю встречу с начальником отдела продаж, чтобы вместе разобрать детали".

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

О - Наблюдение

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

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

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

I - Влияние

На этом этапе мы строим взаимосвязь между действием и его последствиями. Здесь необходимо провести объяснение, почему упомянутое наблюдение важно и какое влияние — позитивное или негативное —оказало на проект, команду, бизнес-результат или атмосферу.

N- Следующие шаги

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

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

Меня спрашивают, если давать обратную связь по COIN как лучше этапы распределить по времени, на все по равно, или на какой-то лучше потратить больше.

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

Например, для члена команды который целеустремлен, нетерпелив, прагматичен, ценит эффективность и контроль можно сократить введение и оперируя цифрами сделать уклон на влияние и решение:

Контекст: Сразу к сути.

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

Влияние: Акцент на влияние на цель, KPI, скорость, бюджет.

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

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

Контекст: Диалог лучше начать с позитива, приведя конкретный пример, демонстрирующий ценность человека для команды и проекта, а потом подойти к теме.

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

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

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

COIN прекрасно работает «сверху вниз» и «снизу вверх»:

Сверху вниз (от руководителя к сотруднику): Использует COIN для постановки задач, корректировки поведения, оценки результата. Основный упор демонстрация и закрепление власти, и формирование ощущения партнерства.

Снизу вверх (от сотрудника к руководителю или системе): Это очень важный вектор способствующий улучшению процессов. Главное, поделиться с сотрудниками о том как COIN работает, как правильно давать обратную связь по этой методике и создать у членов команды ощущение безопасности и того, что РП прислушается к их мнению. Тогда сотрудник, используя упор на «Наблюдение и «Влияние», может предоставить РП важную информации о неэффективности инструмента или управленческом решении.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взаимосвязь между эффективными коммуникациями и критериями успеха проекта

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

Какая же роль коммуникаций и взаимосвязи? Все просто - ясное и своевременное общение способствует правильному пониманию целей, требований и ожиданий всеми участниками.

С моей точки зрения коммуникаций в области критериев успеха делятся на 4 этапа:

Этап 1: Формирование и согласование целей

Этап 2: Демонстрация успеха

Этап 3: Финальное подтверждение

Этап 4: Опционально. «Послепроектная поддержка».

Давайте их разберём поподробнее.

Этап 1: Формирование и согласование целей

Это самый важный этап, где закладывается основа всего. Коммуникация здесь — это не разовая презентация, а интенсивный диалог. Задача — перевести размытые пожелания ("сделать удобный интерфейс") в измеримые критерии ("90% тестовой группы выполняет ключевой сценарий менее чем за 3 клика"). Успех этого этапа — это не просто подписанный документ, а общее понимание у команды и стейкхолдеров, что именно и почему будет считаться победой. Здесь ключевые вопросы - "как мы это измерим?" и "что случится, если мы этого достигнем?". Только когда ответы на эти вопросы ясны и приняты всеми, проект получает чёткую карту для движения вперёд.

Этап 2: Демонстрация успеха в процессе проекта

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

Этап 3: Финальное подтверждение

Момент истины, когда происходит формальное закрытие проекта или этапа. Коммуникация здесь — это церемониальный акт, который ставит точку. Вы представляете итоговый отчёт, где ключевые показатели (KPI) напрямую сопоставляются с целями из Этапа 1. Это презентация не проделанной работы, а достигнутого результата. Фраза "Мы выполнили все 100 задач" слабее, чем "Мы достигли всех трёх согласованных целей проекта, что подтверждается вот этими итоговыми данными". Это превращает закрытие проекта из бюрократического акта в подтверждение успеха.

Этап 4: Опционально. "Послепроектная поддержка"

Часто упускаемый из виду, но критически важный для долгосрочного доверия этап. Его суть — показать, что успех проекта — не сиюминутная победа, а устойчивый результат. Коммуникация здесь сводится к периодическим (раз в квартал) лаконичным дайджестам: "Спустя 6 месяцев после запуска, ключевые показатели, заложенные в проект (NPS, время выполнения операции), стабильно держатся на целевом уровне. Проект продолжает приносить ценность". Это закрепляет вашу репутацию как команды, которая не просто сдаёт "коробку с кодом", а создаёт рабочие решения.

Формирование схемы коммуникаций и её анализ

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

Шаг 1. Выписать все инструменты общения, которые используются в проекте. Определите ключевые и вспомогательные.

Само по себе упражнение видится не сложным, достаточно просто перечислить все развёрнутые системы в Компании, в которых ведётся активная работа командой, почтовые клиенты и мессенджеры. Главное не забыть указать облачные сервисы, файловый сервер, базу знаний и список мессенджеров, которые РП уже видел в общении внутри команды или с заказчиком. Так же внутри одной системы могут быть сразу несколько инструментов для совместной работы, и их надо разделить. Например, Битрикс24 для новых задач, и Битрикс24 - Чат для общения, у вас должно в списке получиться две строки.

Шаг2. Укажите доступность в данном инструменте информации – могут ли не члены команды видеть или создавать сообщения?

Данная информация потребуется для последовательности анализа и оптимизации на следующих шагах.

Шаг 3. Укажите имена членов команды, которые точно в них работают

Данная информация потребуется для анализа участников работающих и анализа и оптимизации на следующих шагах.

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

Например, новые задачи для команды проекта создаются в Битрикс24 и внутренней тикетной системе. Просто исторически в Компании так сложилось, что можно, и там, и там, и нигде не описаны правила.

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

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

Например, такие:

В тикетной системе, следует создавать задачи, для их выполнения членами команды проекта, такие как:

- В продукте фиксируется сбой работы

- Продукт работает не так, как ожидается

- Требуется помощь в настройке продукта на локальном рабочем месте

- Предоставления доступа к другим разделам продукта

- Настройки смартфонов или домашних ПК для работы с продуктом

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

Это могут быть:

- добавление нового функционала в продукт

-обсуждением проблем или поиск нового технического решения;

-изменения текущих процессов;

-заполнение и создание документации

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

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

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

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

Шаг 4. Продумайте каким образом можно «регламентировать» работу в ключевых системах.

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

Шаг 6. Проведите анализ используемых лицензий для программных продуктов и проведите оптимизацию.

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

Формирование устойчивого и единого словаря, залог успешного проекта

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

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

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

Повышение эффективности: Чёткое понимание терминов способствует более быстрому и точному обмену информацией, что ускоряет процесс принятия решений.

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

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

Данный словарь мог бы иметь следующие разделы:

Общепринятые термины – описание основных терминов, описание прав и обязанностей ролей

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

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

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

Рис.1.4. Пример единого словаря проекта

Какие плюсы это принесет для работы над проектом в долгосрочной перспективе:

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

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

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

Растрата энергии на «пустые» коммуникации

Каждый из вас сталкивался с ситуациями, где пустые обсуждения мешали работе и забирали на это драгоценные ресурсы. И по итогу инвестиции в такое взаимодействие понимаешь, что ROI¹⁴ от него имеет серьёзное отрицательное значение и вы сработали в убыток.

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

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

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

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

Вот несколько простых правил, которые помогут не вкладываться в то, что не принесёт прибыли:

- Четко обозначайте свою цель в начале любого взаимодействия: "

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

- Не принимайте участие во встречах и избегайте отправлять ценных сотрудников на собраниях типа "просто обсудить", "высказать мнение". Вместо внедряйте "правило -, задайте до встречи конкретные вопросы или позовите на собрание для решения конкретных вопросов". Задавайте вопрос: "Какой конкретный результат мы хотим получить из этого разговора?".

- Разделяйте "обмен мнениями" и "принятие решения". Обсуждения можно сделать онлайн (в чате, документе). Второе требует встречи с участием ЛПР¹⁶ и лучше избегать совещаний, которые превращаются в мозговой штурм.

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

- Вместо @All только тем, кому это нужно. Прежде чем отправить массовый email или созвать встречу, спросите себя: "Точно ли нужно обсуждение через почту? Кто действительно сможет это выполнить? Кому действительно нужна эта информация, чтобы сделать свою работу?". Вместо этого используйте точечные, адресные каналы.

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

Глава 2. Первые шаги при выстраивании коммуникаций

Азбука коммуникаций: Говорим на одном языке без заумных терминов.

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

Рис. 1.5 Треугольник «Коммуникации-Время-Усилия»

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

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

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

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

При этом хотел бы обратить внимание, на то, что не в полном объёме «словарик» должен быть доступен всем участникам. Из детства мне запомнилось выражение, которое произносит Аббат Фариа, в фильме 1988 года "Узник замка Иф" – "Иногда надо понижать уровень изложения, учитывая аудиторию". А значит, перед РП возникает серьёзная задача, обеспечить взаимодействие таким образом, чтобы каждом из слоёв иерархии формировался свой собственный понятийный аппарат о продукте в целом и целях и показателях проекта. Важно придерживаться формулы: Технические детали — с разработчиками, бизнес-выгоды — со спонсором, простые инструкции — с исполнителями. Например, для топ-менеджеров, стараться общаться таким языком, убирая сложные технические термины, и порой заменяя сложные интеграции на упрощённые рисунки и схемы, без особенно тяжёлых для восприятия подробностей.

Рис. 1.6. Общее эмоционально-когнитивное поле

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

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

Постепенно общение становится экономичнее: уже не нужно долго объяснять контекст или подбирать слова — достаточно намёка, жеста или короткой фразы.

Чтобы ускорить этот процесс, полезно:

- задавать открытые вопросы о личном опыте и ценностях, и отмечать совпадения ("О, я тоже …. ");

- делиться собственными примерами из жизни;

- придумывать совместные формулы, где слово или фраза заменяет собой череду предложений;

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

Приоритезация при выстраивании систему коммуникаций

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

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

В пользу такого подхода, хотел бы привести такие доводы:

- Основные потребители информации о проекте, те от кого зависит итоговая оценка, финансирование и принятие решение о продолжении проекта – топ-менеджеры.

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

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

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

Анализ состава команды и выстраивание векторов коммуникации между командой и другими участниками и внутри команды.

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

Можно выделить Внутренние и Внешние векторы.

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

О чем стоит задуматься:

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

- Где и как зафиксировать «Явные договоренности», доступные любому члену команды, обязательные для исполнения всеми, включая РП.

- Каким образом обеспечить обмен опытом и передачу умений и компетенций между коллегами.

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

- Куда складировать информацию и когда и при каких обстоятельствах её извлекать её оттуда и использовать при работе.

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

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

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

Первичные, вторичные и последующие коммуникации.

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

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

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

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

Цель: Ознакомление сторон с проектом, выявление требований и ожиданий, установление доверия.

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

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

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

Эти коммуникации помогают поддерживать связь между участниками проекта на протяжении всего его жизненного цикла.

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

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

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

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

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

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

Когда писать в чат, а когда собирать совещание. Плюсы и минусы каналов.

Порой мы тратим кучу времени, не понимая, как лучше донести мысль: написать в чат или собрать всех на встречу. В проектном управлении это особенно заметно — один неверный выбор канала съедает время и нервы: часовой созвон из-за мелочи или трёхдневная переписка вместо получасового обсуждения.

Основное правило простое: чат — для обмена информацией, совещание — для ведения диалога.

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

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

Когда хватит чата

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

- нужен быстрый ответ на конкретный вопрос и ответ знает кто-то из членов команды, но точный источник информации не известен ("Кто заблокировал на редактирование Exсel файл?");

- надо проинформировать команду о малом изменении ("начало работ на продуктовом сервере сдвинулись на час");

- требуется собрать мнения в виде голосования по узкому вопросу ("Какой формат отчёта удобнее?") с предложенными примерами.

Помните о 3х основных минусах чатов

- легко пропустить важное сообщение среди потока, поэтому если надо «апните¹⁸» сообщение которое «похоронилось» под грудой других сообщений.

- сложные темы превращаются в долгие переписки без результата;

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

Собрания пригодятся

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

Совещание необходимо, когда:

- требуется согласовать видение («Как будем решать проблему производительности продукта?»);

- нужно принять коллективное решение («Какой формат обучения работе с продуктом выбрать?»);

- возникает конфликт интересов с другими подразделениями («Чьи задачи сейчас важнее - отдела продаж или финансового отдела?»);

- предстоит обсудить сложный процесс («Как подключить продукт к системе мониторинга компании?»)

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

Поэтому, прежде чем создавать встречу в календаре, спросите себя: "Мне нужно, чтобы люди обсудили что-то и приняли решение, или просто узнали новую информацию?" Если второе — смело пишите в чат.

И ещё один ориентир: если переписка в чате тянется дольше 5–7 сообщений и не приближается к решению — пора сказать: "Давайте созвонимся, так будет быстрее".

Это сэкономит время всем.

Стандартные коммуникации и коммуникации в кризисе, разница, инструменты, установки.

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

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

Кризисные коммуникации — это не просто "более интенсивные" стандартные, а качественно иной подход, требующий отдельной проработки.

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

Для формирования подхода к кризисным коммуникациям лучше отталкиваться от ментальных установок:

Факты вместо слухов - Сообщается только проверенная информация.

Принцип одного окна. Все внешние коммуникации идут только через уполномоченное лицо.

Нам сейчас нужны решения, а не на поиск виноватых.

Чтобы заранее вооружить команду инструментами для работы в условиях неопределённости, РП полезно заранее сформировать "Памятку поведения в кризис".

Необходимо

Прекратить общение через паразит¹⁹ные каналы связи;

Использовать только официальные каналы связи;

Не делиться опасениями, мнениями, рисками вне команды;

Строго следовать распоряжениям своего руководителя;

Докладывать только своему руководителю по определённому им каналу связи;

Начать вести журнал своих действий (например, запись экрана);

Запрещается

Отвечать на любые претензии или провокации;

Реагировать на прямые распоряжение руководителей других подразделений и поддаваться давлению с их стороны;

Нарушать распоряжение о "радиомолчании";

Отвечать на телефонные звонки;

Включать во внутреннее общение внешних получателей;

Без распоряжения выносить наружу какую-либо информацию;

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

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

Briefback и Backbrief

В кризисные моменты хорошей практикой которая должна стать привычкой для РП можно смело рекомендовать применять «Briefback» и «Backbrief».

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

При этом, хоть термины схожие – в них есть небольшая разница

Briefback— процедура, при которой получатель инструкций кратко пересказывает услышанное отправителю. Цель: убедиться, что смысл воспринят верно, это быстрая "проверка на входе" (понял/не понял).

Backbrief — более структурированная практика, получатель не просто должен пересказать, а ещё и представляет своё понимание задачи и план действий по её выполнению, дополняет действиями и деталями, которые не были названы постановщиком задачи. Цель: убедиться, что в зоне «свободного плавания» сотрудник будет действовать корректно, в рамках поставленной цели и ограничений, это глубокая "проверка на выход" (не только понял, но и знает, как делать).

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

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

Такая практика - это очень эффективный инструмент борьбы с неопределённостью. Лучше не экономить 3-5 минут, но получить обратную связь как понята исполнителем задача.

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

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

Особенности направленности дополнительных видов взаимодействия

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

- Постановка задачи для исполнителя – как правило, это хорошо регламентированный процесс объяснения «что надо сделать», в том числе я уже писал про это в книге про управление командой²⁰. На что стоит обратить внимание – для обычных штатных обязанностей человека, лучше постановку задач делать через штатные тикетные системы. При этом РП должен выбирать что-то одно – или личная встреча или только создана задача в систему.

Плохой практикой работы РП является создавать задачу в информационной системе, все детально в ней расписать, а потом позвать исполнителя на встречу и все что написано в задаче рассказать ещё раз, уже голосом. Получается, что РП дважды выполняет работу, сначала через клавиатуру, потом через Face-To-Face встречу, повышая себестоимость управления. Для фиксации в виде задачи в системе, можно использовать такой подход – РП устно даёт распоряжение, а последней фразой просит зафиксировать что было сказано устно в задаче. Таким образом появляется доп. контроль, что задача понята, получается такой разнесённый во времени BackBrief.

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

Какие способы и инструменты помогут:

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

Создание положительного микроклимата и мотивации в команде за счёт оценки стейкхолдерами их работы.

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

Глава 3. Управление внешними и внутренними коммуникациями

Ценность молчания или 8 фраз которые не должен произносить РП.

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

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

«Легко»

Оно кажется безобидным, часто произносится с благими намерениями — чтобы успокоить, мотивировать, показать оптимизм. На деле же это семантическая мина, которая детонирует на трёх уровнях: уничтожает ценность труда команды, размывает авторитет самого РП и искажает восприятие продукта всеми участниками. Если посмотреть с другой стороны, то в в мире управления самая дорогая валюта — это не бюджет, а невосполнимые ресурсы команды: фокус, интеллектуальная энергия и время. Каждая задача оплачивается именно этой валютой. И когда руководитель характеризует задачу как "легкую", он, по сути, объявляет эти инвестиции мелкими, не стоящими уважения или даже упоминания.

Когда РП говорит "это легко сделать", он совершает акт семантического вандализма по отношению к работе специалистов.

Механика: Слово "легко" стирает сложность, творчество, экспертизу и часы анализа, которые стоят за решением. Оно превращает работу инженера, дизайнера, аналитика в нечто тривиальное, не требующее особых усилий.

Реакция команды: "Если то, что мы делаем — "легко", значит, и мы сами как специалисты ничего не стоим. Нашу экспертизу не уважают". Это прямая дорога к демотивации и выгоранию. Зачем выкладываться, если результат всё равно назовут "простым"?

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

Управленческая коммуникация должна легитимизировать затраты, а не маскировать их. Цель — дать людям осознать у себя в голове: "Я вижу, что это потребует ваших ресурсов, и я уважаю эту инвестицию".

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

Признание сложности + Уважение к ресурсам + Фокус на решении.

Пример трансформации:

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

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

Вот краткая шпаргалка, которая вам поможет адекватно описывать затраты:

Рис. 1.7. Замена слова "легко" на повышающие ценность фразы

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

Как обычно, немножко «чёрной магии». Использование осознанной противоположности слову «Легко» - умение сразу, без анализа, в лоб просителю сказать: "Это сложная, комплексная задача, требующая тщательной работы, и мы можем это сделать". И если от первого слова надо просто избавиться, то второе — это уже не просто слово, а инструмент. Инструмент, которым нужно уметь пользоваться с умом.

Зачем это нужно? Представь, что вы не просто описываете задачу, а настраиваете её "громкость" и "цену" для окружающих. Иногда нужно тихо и быстро сделать работу, а иногда — наоборот, сделать так, чтобы её важность и сложность ощущали все: и команда, и заказчик, и начальство. Ты делаешь сложность видимой.

Зачем может полезно сознательно подчёркивать сложность?

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

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

Чтобы защитить команду и дать ей время. Заложив в самом начале, что задача нетривиальная, вы сразу создаете правильные ожидания. Тебе поверят, что на это нужно не два дня, а две недели. Это "воздух" для манёвра, защита от авралов и возможность сделать работу качественно, а не костылями.

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

Важное предостережение: Не переиграть. Если вы начнёте описывать как "сложнейшую" каждую вторую задачу, вы очень быстро:

- Потеряете доверие. Вас раскусят, и ваши слова перестанут иметь вес.

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

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

"Я тебе помогу это сделать"

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

Разумеется, сотрудник всегда должен знать, что руководитель проекта всегда готов прийти ему на помощь, но он должен прийти к нему с просьбой о ней и показать где и в чем он "уперся". Таким образом, мы избегаем ситуации, когда в надежде на обещанную помощь, сотрудник вместо того, чтобы делать сам, выждав порой непростительное время, является к руководителю со словами "У меня ничего не получается". Как правило все сводится к тому, что руководитель, понимая, что в приемлемые сроки руками и головой подчиненного задачу выполнить уже не удается, приходится делать все самому. Ну, а такая ситуация, совершенно не приемлема с точки зрения регулярного менеджмента, чтобы РП что-либо делал за подчиненных. Он своими действиями должен приводить обратную связь от подчиненных к нему по поставленным задачам к "менеджерским форматам": вовремя оповестить, суть излагать четко по делу, указать, где и какие ресурсы уже были исследованы в поисках решения, какие результаты были получены.

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

"Прошу...".

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

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

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

"Мне приказали..."

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

Одной из печатных форм такой неосмысленной передачи задач можно встретить такую тему у сообщения электронной почты – FWDRE: FwdRe: RE "Уже не важно какая тема". Скорее всего руководитель даже не удосужился прочитать, пересылаемую информацию и спешит избавиться от назойливого письма передав задачу, в искренней надежде что подчиненные из множества идущих ниже сообщений соберут воедино правильную картинку.

Однажды в одном из психологических тестов для руководителей я встретил такой "кейс".

"Генеральный директор мимолетом вам сообщил что все сотрудники вашего подразделения должны завтра прийти на работу во всем зеленом. Объяснить причину своего решения у него не было времени и уточнить ее уже не представляется возможным. Ваша задача донести информацию до сведения сотрудников вашего подразделения. Какую речь вы произнесете перед ними?".

Вот та ситуация, где можно выбрать между передачей "непонятного распоряжения" руководства вниз подчиненным "As Is" или ставить задачу от себя. В первом варианте на неудобные вопросы "почему-зачем-откуда такая идея", придется придумывать и возможно даже от себя согласиться с бредовостью данной идеи, которая посетила и вас во время встречи с руководителем, если такая ситуация и вправду произошла. С управленческой точки зрения второй вариант требует больше силы и уверенности в себе для руководителя. Вполне приемлемым в данной ситуации будет такой вариант обращения: "Коллеги, завтра всем без исключения требуется прийти в зеленой одежде. На возникшие в ваших головах ключевые вопросы хочу сразу ответить. На вопрос "Зачем? –– Я так захотел и это всё. А на второй вопрос, "А что будет если не выполнить распоряжение?" - я бы вам крайне не рекомендовал проверять это. Остальные вопросы считаю не существенными и не будет на них отвечать".

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

"Это всe виноваты мои подчиненные"

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

Хуже нет для менеджера всю ответственность валить на сотрудников ниже рангом. Не стоит останавливаться на мысли, что руководитель проекта несет персональную ответственность за действия вверенных ему членов команды проекта, должен контролировать результаты их действия, и никогда не валить на них, даже в половину слова, вину. Гораздо корректнее, выслушав претензии коллег, взять паузу и пообещать разобраться, чем сразу объявлять виновных и идти вместе с обвинителем исполнять наказание. Если что-то пошло не так, не из злого же умысла действуют на работе ваши коллеги по цеху. Взять ответственность на себя это проявление силы. Почему-то руководителям трудно признавать свои собственные недоработки и вину, особенно публично. Тактика минимального сопротивления, как дуршлаг, предлагает пропустить сквозь себя весь негатив и объявить виновными исполнителей. Лучше всего в такого рода ситуациях придерживаться подхода, что про подчиненных или очень хорошо, или ничего, и никогда не обсуждать публично их личностные качества, какие мерзопакостные они не были. Позитивный настрой руководителя проекта в таких ситуациях и взятая доля ответственности за действия членов команды помогут поддерживать правильную атмосферу в коллективе.

"Раз и на всегда"

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

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

Опытный руководитель проекта понимает, что сделать что-либо настолько железобетонно, как указывается в данной фразе, физически не возможно, а значит сотрясать воздух такими словами не следует. Есть более сильные и целеустанавливающие фразы вроде "А каким образом можно сделать что бы подобное не повторилось?", "Какие действия необходимо сделать что бы повысить отказоустойчивость?". При этом не требовать быстрого ответа, ведь порой требуется время на размышление. Главное быть последовательным и делегировав задачу подчиненному строго проконтролировать ее выполнение.

"Я тебе сейчас докажу...."

Начинать полемику с нижестоящими членами команды проекта так же плохо для репутации, как и бездумно передавать чужие приказы. Особенно, если это происходит публично, и руководитель проекта под градом доводов проигрывает. Еще Дейл Карнеги рекомендовал избегать острых углов, и спором вряд ли можно добиться положительных результатов в вопросах созидания поля власти внутри подразделения.

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

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

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

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

"А ты помнишь, что должен к такому-то числу сделать то-то и то-то"

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

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

Если есть беспокойство о состоянии задачи, достаточно в календаре у себя и сотрудника прошить "точку контроля" на которой получить полный отчет том, как движется задача. Достаточно заранее «бросить» встречу, в теме которой указать «Промежуточный контроль по задаче …»

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