О проектных ролях

by Владимир Бычко

В окружении проекта можно выделить следующие роли:

  • Спонсор
  • Заказчик и пользователи
  • Менеджер проекта
  • Команда
  • Другие участники

Спонсор — лицо или группа лиц, снабжающее проект ресурсами.

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

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

Проясню ещё раз. Заказчик и спонсор — в 99 % случаев разные люди. Даже во внутренних проектах.

Заказчик и пользователи — лицо или группа лиц, которые будут использовать результаты проекта (чаще всего это продукт).

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

Команда — лицо или группа лиц, которые выполняют проектные работы для достижения целей проекта.

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

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

Итак, команда — это сотрудники, которые будут писать код, тянуть сеть, таскать кирпичи и производить другие проектные работы.

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

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


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

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

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

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