Сергей Барамба – Проектная команда под контролем: Как достигать результатов вместе (страница 2)
Границы команды проекта, иерархия.
Определение границ и правильная организация взаимодействия между различными элементами в проекте, организационными единицами, это основа для достижения успеха. Организационные единицы в проекте представляют собой структурные компоненты, которые помогают РП организовать и управлять проектной деятельностью. От того насколько правильно наполнит и выстроит такие элементы РП зависит успешность выполнения проекта.
К Организационным единицам в проекте относится – Проектный комитет, Куратор проекта, Руководитель проекта, Команда управления проектом, Проектная команда. При этом в границы команды проекта подпадают только последние три.
Команда управления проектом, в английской литературе – «project team management», бывает централизованная и распределённая
Централизованная подразумевает что все активности управления обычно назначены одной персоне, руководителю проекта или похожей роли. В такое ситуации им согласовываются Устав проекта и другие документы и осуществляются все необходимые для проекта процессы.
В распределённой команде управления права, обязанности и ответственность распределяется между некоторым количеством членов команды проекта.
Команда проекта – Совокупность лиц, выполняющих работу по проекту для достижения его целей.1 Состоит из людей, которым определены роли и ответственность за выполнение проекта. По мере выполнения проекта профессиональный и численный состав команды может часто меняться. Распределение ролей и ответственности между членами команды позволяет все членам команды участвовать в планировании проекта и принятии решений, что является ценным для проекта.
Иерархическая схема команды проекта приведена на рисунке 1.2
Рис. 1.2. Иерархическая структура команды проекта.
Несколько тезисов по этому рисунку:
1. Подрядчики или партнёры в зависимости от уставных документов проекта могут оказаться внутри границ или вне их. От этого зависит скорость взаимодействия и количество необходимых документов для согласования выполнения ими работ.
2. По умолчанию команда управления проектом не создаётся, и РП по умолчанию осуществляет несёт ответственность за все процессы внутри проекта – управление рисками, бюджетирование и прочие. В случае введения в состав – эти обязанности делегируются специальсно ответственным лицам внутри команды, например риск менеджмент полностью передаётся отдельному специалисту.
3. Внутри команды проекта возможны совместные активности двух типов:
–Координация – постановка новых задач, изменение условий, согласование сроков. Такие взаимодействия возможны только между лицами наделёнными полномочиями на внесение корректировок.
–Взаимодействие – обмен информаций об уже согласованных задачах, без корректировки их сути. Особые полномочия тут не требуются, все операции идут в рамках стандартных полномочий, низкий уровень ответственности за результат. Между рядовыми членами команды и подрядчиками возможно только взаимодействие, а координация осуществляется только РП.
4. Руководитель пакета работ – член команды, на которого целиком возложено полностью какое-нибудь одно направление. Например, Руководитель ИТ отдела отвечает за все вопросы про сервера. Он вводится в команду проекта один, а его подчинённые остаются за границами. Все задачи, в которых важную роль играет серверная группировка передаются для анализа, декомпозиции и оценки именно ему. Это может быть покупка оборудования, его монтаж, развёртывания программного обеспечения, выполнение задач по обслуживанию. У него есть власть над ресурсами – его подчинёнными и полномочия общаться напрямую с поставщиками и полномочия на координацию. Сотрудники функционального подразделения, возглавляемого членом команды, не несут прямой ответственности за результат проекта или фазы проекта, могут меняться волей руководителя отдела, поэтому вынесены за границы команды проекта.
5. Эксперты – Мне кажется это наиболее недооцененная возможность повышения компетенций внутри команды. Руководитель не должен выносит весь проект исключительно на себе, только своими возможностями. Это некий, ни к чему не обязывающий для РП, источник информации, носитель глубоких знаний и опыта, к которому прибегает РП или члены команды, попадая в затруднительное положение. Для руководителя проекта способы использования экспертов не ограничивается только консультациями. Их можно привлекать для обучение, анализа, поддержка принятия решений, слежения за правильностью использования методологии управления проектом и даже просто если надо выговориться руководителю проекта.
Эксперты дают советы, но не несут ответственности если вы будете следовать их советам или сделаете все наоборот. Поэтому эксперты вынесены за рамки границ команды проекта.
6. Границы команды проекта заканчиваются там, где взаимодействие между сторонами из переходят к процессно-сервисным отношениям. Внутри команды для взаимодействия используется или стандартный треугольник – планирование-делегирование-контроль или по строгим правилам методологий SCRUM или KANBAN.
Состав команды и когда кто нам может оказаться нужен.
После того как определено, где начинаются и заканчиваются границы команды проекта, руководитель должен для себя сформировать список тех, кто разделит все тягости создания продукта, с кем ему делить радости и поражения. Проект, это не только создание продукта, но и ещё куча побочной деятельности – встречи, согласования, создание документов и решение конфликтов – социальных и технических. Столкнувшись с небольшой неприятностью в проекте или нехватке компетенций, нельзя каждый раз открывать вакансию и ждать несколько месяцев пока она заполнится. От того, насколько правильно подобраны люди, их компетенции и потенциал сотрудников для решения не стандартных задач, которым полон любой проект, зависит успех самого руководителя проекта. Ещё руководитель проекта должен держать в голове, что нужный специалист на начальном этапе, на следующих может оказаться не у дел, ему станет скучно ничего не делать. Хорошо если он уйдёт сам, но ведь может остаться – не принося пользу, но потребляя драгоценные ресурсы проекта. Подобной ситуации можно избежать если для редких или одноразовых задач привлекать действительно временных специалистов. Также к таким задачам, которые можно передавать «на аутсорс» можно отнести узкоспециализированные и дорогостоящие компетенции, где закрытие вакансии может длиться месяцами, а интерес к проекту у специалиста может быстро угаснуть. Со «звездами» всегда тяжело работать и удерживать.
Поэтому перед руководителем постоянно стоят вопросы «Кто» или «Что нужно сделать»? – в проект нужен человек с нужными навыками или для выполнения конкретной задачи или этапа. Например, сотрудник с навыками дизайнер UX/UI нужен только на начальном этапе, пока не сформировался интерфейс продукта. Но если помимо навыков в рисовании человек разбирается в смежных областях, например в Scrum и из него может получиться отличный Scrum Master, он может пригодиться для других этапов проекта. И вторая группа вопросов – «Искать или Готовить?». Мы хотим сразу готового специалиста и не готовы вкладываться в его развитие или же согласны взять сотрудника с «потенциалом», и довести его до необходимой «кондиции» за счёт различных форм обучения. На рынке почти невозможно сразу найти специалиста по узкоспециализированному ПО или оборудованию, которое может использоваться в техническом решении вашего проекта. Скорее всего придётся учитывать в плана проекта ранее заполнение потенциальными кандидатами вакансии, возможно даже несколькими. Обучать их, с прицелом что в нужный момент проекта они окажутся готовыми к выполнению запланированных операций.
В стандартном подходе руководитель проекта для формирования состава команды прикидывает, высокоуровневый список задач и сопоставляет с уже имеющимися в распоряжении должностями специалистов (рис. 1.4.). Задачи распределяются между ними исходя из известных РП компетенций конкретных специалистов, уже работающих в вашей компании или общепризнанные для таких должностей. В таком способе сначала пишутся должности сотрудников и уже к ним притягиваются подходящие задачи. Дальше РП переносит это в устав проекта.
Рис. 1.3. Таблица Должности – Задачи
В принципе, ничего плохого в таком подходе нет. Результат получен легко и сразу, буквально за несколько минут. В таком способе есть риски, потому что он не позволяет оценить какими именно компетенциями должны обладать конкретные члены команды в динамике, и с какими именно техническими решениями или задачами в проекте им придётся столкнуться. Это стандартный подход процессного мышления для операционной деятельности. Но нужно учитывать, что в проекте главное не должность сотрудника, а его вклад в результат на каждом из этапов. А еще, таком подходе РП сам себя загоняет в шаблон, и любая нестандартная ситуация, которая оказалась на пути проекта в ходе исполнения будет заставлять его думать и искать среди членов команды «кто может справиться этим». А если окажется некому, то экстренно согласовывать привлечение внешнего подрядчика для решения данной задачи.
Вышеуказанных ошибок при формировании состава команды проекта можно избежать, если попробовать определить состав команды немножко по-другому, внеся в модель список конкретных операций, которые необходимо выполнять.