Проектная команда под контролем: Как достигать результатов вместе

Определение роли руководителя проекта

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

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

Часто возникает вопрос – важны ли глубокие знания в предметной области для РП? В качестве ответа предлагаю придерживаться формулы – чем сложнее и масштабнее проект, тем менее важны компетенции руководителя как эксперта в предмете, например «ИТ-шника», но сильнее необходимы как «управленца». Наличие «hard skills» в предметной области продукта становится крайне полезным, но перестает быть необходимым.

О чёрной и белой магии

«Белая» магия это использование стандартных рекомендаций, которые указаны в книгах и курсах, строгое следование регламентам и инструкциям. Как правило тут все просто, в лоб, честно и прозрачно и как правило не сложно, хоть и отвлекает больше времени и ресурсов. В большинстве случаев использование приёмов белой магии безопасно, не несёт рисков, потому что все ходы чётко записаны в информационных системах управления проектом.

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

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

Жизненный цикл взглядов РП на команду проекта.

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

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

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

Рис. 1.1. Взгляд на команду проекта с точки зрения жизненного цикла проекта.

Инициирование, ключевой вопрос «Кто?»: От того какие человеческие ресурсы окажутся доступны, таким образом и будет создаваться конечный продукт. На этом этапе важно определить наличие необходимых сотрудников в штате компании, отношения с ними, формат взаимодействия – сотрудник в штат или какой-нибудь «…сорсинг» сильно влияют на сроки и бюджет. Тут больше речь идёт о необходимых компетенциях, чем организационной диаграмме команды проекта. Именно на этом этапе руководитель проекта может выбрать методологию, по которой будет осуществляться дальнейшая реализация.

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

Разработка и Внедрение ключевой вопрос «Как?»:

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

Завершение, ключевой вопрос «А дальше?»

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

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

Границы команды проекта, иерархия.

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

К Организационным единицам в проекте относится – Проектный комитет, Куратор проекта, Руководитель проекта, Команда управления проектом, Проектная команда. При этом в границы команды проекта подпадают только последние три.

Команда управления проектом, в английской литературе – «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. Таблица Должности – Задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 6. Попробуйте определить количество требуемых штатных единиц внутри команды.

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

В результате РП получит более точное и качественное представление о членах команды. Уже будет точное понимание какую группу операций необходимо передать внешнему подрядчику, и внести своевременно корректировки в бюджет проекта. Таблицу можно использовать как график привлечения персонала в проект, ведь тут чётко видно на каком этапе проекта понадобится сотрудник с необходимыми в этот момент навыками и компетенциями. Для моментов, когда будут наращиваться внутренние компетенции, учесть необходимость поддержки продукта, понимая кто и для каких регламентных операций может оказаться нужным. А зная приблизительное число сотрудников, можно посчитать размер ФОТ и внести бюджет проекта. Моя практика показывает, используя такой инструмент удаётся состав команды проекта сократить на треть в отличии от приведённого в начале раздела способа.

Естественный подход при управлении

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