Участники проекта: кто принимает решения, выполняет и использует результат

Щербуха Андрей

Эксперт по управлению проектами, продуктами и программами цифровой трансформации, руководитель проектов. Преподаватель курса «Запуск и планирование проекта»

Кого считать участником проекта

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

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

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

Участники, команда и заинтересованные стороны

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

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

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

Заказчик объясняет, зачем нужен результат

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

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

Заранее уточните представительство. Кто вправе подтверждать требования от имени заказчика? Как поступать, если разные сотрудники дают несовместимые указания? Отсутствие этой договорённости создаёт риск: исполнитель добросовестно выполняет последнюю просьбу, но позднее выясняется, что она не выражала согласованную потребность.

Куратор помогает принимать решения за пределами команды

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

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

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

Руководитель проекта связывает действия участников

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

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

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

Команда выполняет работу и сообщает об ограничениях

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

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

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

Пользователи и внешние исполнители

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

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

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

Пример карты для внутреннего внедрения

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

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

Как совместить роли без путаницы

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

Попробуйте составить карту для знакомой небольшой инициативы и назвать владельца каждого существенного решения. Затем обсудите её с участниками. На курсе запуска и планирования проекта Учебного центра МГУТУ работа с ожиданиями и требованиями соединяется с подготовкой состава работ, ресурсов и рисков. Такая подготовка помогает перейти от списка участников к согласованной организации проекта.

Практика вместо теории

Освойте распределение ролей и ответственности в проекте

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

Смотреть программу

Вопросы и ответы

• Участники проекта и команда — одно и то же?

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

• Всегда ли заказчик является спонсором?

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

• Может ли один человек выполнять несколько ролей?

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

• Как включить будущих пользователей в работу?

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

• Что делать, если после завершения проекта некому поддерживать результат?

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

По теме