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

Рис. 1.4. Таблица Должности – Задачи

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

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

В такие моменты нашим лучшим помощником становиться Excel и два вопроса: «Что делать?» и «Когда делать?». Для выполнения упражнения нам ещё понадобится план реализации проекта.

Шаг 1. Создайте новый файл и заполните первые 3 столбца названиями:

Рис. 1.5. Первый шаг заполнения состава команды.

Мы уже точно знаем, что в состав команды войдёте вы – как руководитель проекта. Остальные должности нам пока не известны, и привязываться к ним как раз не стоит. Поэтому остальные столбцы пока не надо заполнять должностями.

Шаг 2. Заполните столбцы «Что делать» и «Когда делать». Возьмите за основу план проекта или иерархическую структуру работ. На забудьте указать задачи менеджмента, обучения пользователей, управление рисками и бюджетом, встречи с заказчиком. В когда делать можно указать, если известно конкретные даты начала и конца, или названия этапа жизненного цикла проекта, как на рис 1.6..

Рис.1.6. Заполненные столбцы «Что делать» и «Когда».

Шаг 3. «Кластеризуйте», по областям получившиеся задачи из столбца «Что делать. И отвечая на вопрос «Эти работы лучше подходят для…» и проставьте условные должности «Менеджер по…» или «Специалист по» , «Главный по…». Например – «Специалист по видеонаблюдению», на рисунке 1.7. обобщённые задачи и должность выделены фиолетовым и оранжевым.

Рис. 1.7. Результаты кластеризации.

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