Эту страницу открывают, когда проект начинает буксовать не из-за задач, а из-за людей: непонятно, кто принимает решения, кто согласует изменения, кто реально влияет на сроки и кто должен быть вовлечён в ключевые обсуждения.
Определение участников и ролей завершает сборку рамки проекта, потому что даже сильная цель и ясный scope плохо работают, если в проекте неясно распределены влияния, решения и зоны ответственности.
Что это за компетенция
Это умение собрать ролевую карту проекта: понять, кто является заказчиком, спонсором, пользователем, владельцем требований, исполнителем, согласующим, влияющей стороной и скрытым центром принятия решений.
Речь идёт не только о должностях в оргструктуре. Важнее понять реальное влияние на проект.
Зачем нужна
Навык нужен, чтобы:
- понимать, с кем именно нужно собирать рамку проекта;
- не терять скрытых стейкхолдеров до поздних этапов;
- ускорять согласования и эскалации;
- правильно строить коммуникацию и статусы;
- связывать решения с конкретными владельцами.
Где проявляется в реальной работе
Навык особенно нужен:
- на старте проекта;
- при сборке stakeholder map;
- при интервьюировании и согласовании требований;
- при построении RACI;
- в конфликтных и пограничных ситуациях, где важно знать, у кого финальное слово.
В аутсорсе сложность часто в том, что формальный заказчик и реальный decision maker не совпадают.
Во внутренних проектах сложность чаще в пересечении функциональных руководителей и скрытой политике.
Что ломается без неё
- решения принимаются поздно или не теми людьми;
- PM носит вопросы по кругу;
- важные участники всплывают только на приёмке;
- согласования затягиваются;
- команда не понимает, у кого финальное право сказать «делаем так».
Что можно делегировать, а что нельзя
Нельзя делегировать ответственность за то, чтобы ролевая карта проекта была собрана и понятна самому PM.
Можно делегировать:
- оформление карты влияния;
- сбор оргструктурной информации;
- уточнение конкретных зон ответственности у функциональных лидов.
Как выглядит слабый уровень
- есть только формальный список участников без понимания, кто реально влияет;
- роли заказчика, пользователя и спонсора смешаны;
- внешние зависимости не привязаны к владельцам;
- PM ориентируется только на самых активных в чате.
Как выглядит сильный уровень
- PM понимает, кто принимает решения, кто влияет, кто блокирует и кто исполняет;
- для ключевых тем есть явные владельцы;
- карта ролей учитывает не только формальную, но и фактическую власть;
- коммуникация строится адресно, а не массовыми рассылками на всех.
Как понять, что это ваш пробел
- можете ли вы быстро назвать ключевых участников проекта и их роль;
- понимаете ли, кто утверждает scope, сроки, запуск и приёмку;
- знаете ли, кто способен сорвать решение, даже не будучи частью основной команды;
- понимает ли команда, кто за что отвечает.
Что делать пошагово
1. Выпишите всех участников проекта, включая внешние команды и косвенно влияющих людей. 2. Разведите их по типам ролей: принимает решение, согласует, влияет, исполняет, пользуется результатом. 3. Отдельно отметьте владельцев требований, бюджета, приёмки и зависимостей. 4. Сопоставьте формальную и реальную карту влияния. 5. Зафиксируйте ролевую схему в stakeholder map или RACI. 6. Используйте карту ролей в статусах, эскалациях и планировании коммуникации.
Практический шаблон
Для каждого участника полезно фиксировать:
- роль в проекте;
- интерес к результату;
- уровень влияния;
- зону решения или согласования;
- желаемый формат коммуникации;
- возможные риски взаимодействия.
Такую карту полезно пересматривать на ключевых переходах проекта: после уточнения требований, перед релизом, при появлении новых зависимостей и перед приёмкой. Ролевая схема редко остаётся статичной до конца проекта.
Типовые ошибки
- ограничиваться только оргструктурой;
- не замечать скрытых decision makers;
- не различать «информируем» и «согласует»;
- не обновлять карту ролей по мере развития проекта;
- держать критичную ролевую информацию только в голове.
Как качать навык
- после стартовых и discovery-встреч всегда задавайте вопрос, кто ещё влияет на решение;
- ведите живую stakeholder map;
- развивайте управление ожиданиями и адаптацию сообщения как продолжение ролевой карты;
- используйте RACI, если проект многослойный и роли сильно пересекаются.