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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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