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

Обновлено: 19.05.2024

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

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

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

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

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

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

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

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

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

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

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

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

Основные этапы жизненного цикла команды проекта

Отечественные специалисты выделяют пять этапов в жизненном цикле команды проекта:

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

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

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

5. Этап расформирования команды. По завершении проекта команда расформировывается. Два типичных сценария развития событий на этом этапе таковы.

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

Во втором случае, когда проект неуспешен, команда расформировывается и чаще всего далее уже не собирается в таком составе.

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

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

спонсор (иногда его называют куратор);
заказчик и пользователи;
команда;
менеджер проекта (или руководитель проекта);
другие участники.

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

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

Спонсор – это тот, кто выделяет на проект ресурсы. На первой взгляд, миллион долларов предлагает клиент, значит, он финансирует, спонсирует проект. Получается, клиент - это и есть спонсор? Он же является и заказчиком? Одно лицо может выполнять две роли – и спонсора, и заказчика. Но такая ситуация бывает очень редко.

Спонсор.

Суть: снабжает ресурсами проект и принимает судьбоносные решения.

Определение: лицо(или группа лиц), предоставляющее ресурсы и поддержку для проекта, программы или портфеля и ответственное за достижение успеха.

Отношения с ПМ (менеджером проекта): он решает то, что не во власти ПМ.

Количество:один или много.

Итак, спонсор снабжает проект ресурсами. В нашем случае кто выделяет ресурсы? Директор! Ведь клиент, по сути, заплатил миллион долларов компании, но эти деньги до проекта еще не дошли. До проекта может быть дойдет 10 тысяч долларов, остальное – налоги, какие-то платежи, сборы. Поэтому тот, кто дал деньги на проект, тот и спонсор. В IT у менеджеров зачастую вообще нет денег. В этой сфере в качестве ресурсов выделяют на проект людей – 5 программистов, 2 тестировщика, аналитик на год. И все – делайте проект. Кто им зарплату платит? Директор! Он вас обеспечил ресурсами – людьми, поэтому он спонсор.

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

Заказчик и пользователи.

Суть: те, кто будет утверждать/использовать результаты проекта.

Определение: люди или организации, участвующие в приемке и использовании результатов проекта.

Отношения с ПМ: их интересы обслуживает ПМ.

Количество: как правило, много.

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

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

Команда проекта.

Суть: те, кто будет выполнять работы.

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

Отношения с ПМ: трудно переоценить.

Количество: всегда много.

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

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

Менеджер проекта.

Суть: рулит командой, во имя достижения успеха проекта.

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

Количество: один, но может формировать целую "команду управления проектом"

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

Заинтересованные стороны.

Суть: все, чьи интересы затрагиваются реализацией проекта.

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

Отношения с ПМ: зависят от вида и влияния заинтересованного лица.

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

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

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

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

Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"

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

Команда проекта – совокупность отдельных лиц (участников проекта), привлеченных к выполнению работ проекта и ответственных перед руководителем проекта за их выполнение.

Вхождение в команду проекта ключевых специалистов и TOP-менеджеров Заказчика является одним из условий успешного достижения целей проекта.

Ниже приведена структура проектной команды и краткое описанием проектных ролей.

Пример формирование команды проекта внедрения
корпоративного хранилища данных

Ниже приведено описание проектных ролей команды проекта со стороны Исполнителя.

Проектная роль	Описание проектной роли
Куратор проекта	Как правило, руководитель высшего звена, который курирует проект, обеспечивает общий контроль и поддержку проекта финансовыми, материальными, человеческими и другими ресурсами. Куратор проекта отвечает за достижение проектом конечных целей и реализацию выгод для организации.
Руководитель проекта	Руководитель проектной команды, ответственный за управление проектом, достижение целей проекта в рамках бюджета, в срок и с заданным уровнем качества.
Системный архитектор	Обеспечивает управление рабочей группой и контроль качества в рамках всех этапов проекта. Формирует архитектуру и идеологию ХД, оценку имеющихся технических возможностей, взаимосвязи со смежными системами, проектную документацию.
Бизнес-аналитик	Обеспечивает двустороннюю взаимосвязь между предметными экспертами (функциональными специалистами) Заказчика и IT-специалистами Исполнителя путем сбора требований, их обработки, документирования и передачи специалистам Исполнителя, а также путем доведения полученных результатов до представителей Заказчика.
Специалист по модели данных	Является архитектором модели данных. Формирует концептуальную и логическую модели данных. Участвует в формировании физической модели данных.
Администратор БД	Проводит установку и настройку СУБД. Непосредственно участвует в разработке физической модели данных. Отвечает за выработку требований к БД, её проектирование, реализацию, оптимизацию, сопровождение и архивирование, включая управление учётными записями пользователей БД и защиту от несанкционированного доступа.
Администратор приложений	Обеспечивает установку и настройку сервера приложений и его компонентов, разработку дополнительных приложений. Обеспечивает разграничение прав доступа на прикладном уровне.
Разработчик ETL-процессов	Проводит установку и настройку сервера ETL. Обеспечивает настройку процессов извлечения данных из систем, их преобразование для хранения в заданных структурах и с заданным качеством, загрузку в область постоянного хранения.
Разработчик BI-приложений	Обеспечивает настройку средств визуализации данных (отчетов, запросов, графиков) в необходимом и наиболее эффективном для пользователя виде.

Ниже приведено описание проектных ролей команды проекта со стороны Заказчика.

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

Для участия в проекте со стороны Заказчика могут привлекаться следующие сотрудники.

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

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

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

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

Динамика развития проектных событий

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

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

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

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

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

Вырастание команды из проектных групп

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

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

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

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

Затем рабочая группа трансформируется в команду управления проектом. К наступившему моменту уже несколько иная проектная группа по существу представляет собой ядро команды, которому PM доверяет и на них полагается. Она состоит из специалистов в конкретных отраслевых, управленческих областях. Поэтому такая группа называется командой управления проектом (КУП), состоящей из непосредственных помощников менеджера. С ними он советуется, на них он возлагает какую-то ответственность и передает определенные полномочия.

Учет характеристик и функций исполнителей

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

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

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

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

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

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

Читайте также: