Команда проекта — это основной субъект проектной деятельности, поскольку именно от команды в большей степени, чем от отдельного человека, зависит достижение целей проекта. Команды могут быть постоянными и временными, могут существовать внутри функциональной структуры предприятия или обособляться в отдельные организационные единицы. В любом из этих случаев, основные задачи управления командой проекта будут состоять в том, чтобы добиться сплочённости внутри коллектива и координировать роботу его членов.
Цель статьи — подсветить лишь наиболее важные вопросы, связанные с управлением людьми. Ответы на них помогут руководителям рационально распределять обязанности между членами команды и управлять общим ходом работ.
Сотрудник всегда будет тратить часть времени на решение организационных вопросов.
Для понимания, как распределяется полезная нагрузка между участниками проекта обратимся к нашим данным по норме утилизации сотрудников.
- Стажёр тратит на полезную работу только 50% рабочего времени;
- Специалисты (младшие и старшие) тратят 75% рабочего времени на полезную работу:
- Ведущий руководитель только 40% времени занят полезной работой.
Примеры показывают, что любой участник проекта всегда тратит какое-то время на совещания, доклады, отчёты, поиск информации, наставничество и так далее.
Timetta умеет распределять данные учёта рабочего времени по видам работ. Это помогает понять, сколько сотрудник тратит времени непосредственно на решение задач.
- Организационная работа необходима, без неё команда проекта не сможет нормально работать как единое целое.
- Человеку трудно одновременно руководить коллективом и выполнять основные работы проекта. Одно будет идти в ущерб другому.
- При одновременной занятости на нескольких проектах эффективность сотрудника будет падать из-за большей организационной нагрузки.
Конечно, более опытный специалист может быть занят на разных ролях в разных проектах, но в любом случае это будет снижать его полезную нагрузку. Степень вовлеченности сотрудника в проекты компании нужно учитывать при планировании ресурсов — без этого не получится составить крепкую команду, в которой участники будут максимально сосредоточены на результате.
Календарь ресурсов в Timetta показывает свободное и забронированное время сотрудников.
Для планирования ресурсов используются такие приложения, как Timetta Resources, которые позволяют эффективно распределять сотрудников по проектным командам.
Роль — это совокупность ожиданий от участника команды проекта. Чем точнее распределены роли, тем выше слаженность командной работы.
Чаще всего роли связывают с компетенциями. Такие роли можно условно назвать техническими. Проектировщик зданий, программист, архитектор бизнес-приложений — типичные примеры технических ролей. Их состав определяется целями и ограничениями самого проекта. Однако техническими знаниями и навыками понятие роли не исчерпывается, так как человек во время реализации проекта обязан ещё взаимодействовать с другими людьми.
Матрица RACI даёт наиболее общую классификацию ролей применительно к зонам ответственности.
RACI — это акроним, составленный из четырёх основных обязанностей, которые ложатся на плечи участников проектной команды.
- Responsible (Ответственный) — тот, кто непосредственно отвечает за надлежащее выполнение задачи.
- Accountable (Подотчётный) — тот, кто непосредственно принимает результат работы над задачей и контролирует соблюдение всех поставленных перед исполнителем условий.
- Consulted, also Consult before doing (Консультант) — тот, кто согласовывает решения в процессе работы.
- Informed, also Inform after doing (Наблюдатель) — тот, кто наблюдает за общим прогрессом работ.
Матрица ответственности помогает понять, кто в проекте выполняет, а кто контролирует задачи.
|
Игорь Агафонов |
Дмитрий Богатов |
Александр Нестеров |
| Написание кода |
R |
A, C |
I |
| Подготовка документации |
R |
A, C |
I |
Например, в нашем примере Игорь Агафонов непосредственно пишет код и готовит пользовательскую документацию. Дмитрий Богатов принимает его работу и помогает советом, а Александр Нестеров только фиксирует момент завершения задачи.
Матрица RACI не является единственной классификацией ролей, если есть и другие, чуть более экзотические.
В учебнике ВШЭ по управлению проектами приведена организационно-психологическая классификация ролей:
- роли, ориентированные на выполнение задач — определяют проблемы, запрашивают и предлагают информацию, собирают мнения, разъясняют предложения.
- роли, ориентированные на поддержку работы — координируют участников, улаживают разногласия, помогают группе повышать эффективность, вдохновляют, сопровождают участников на разных этапах, следят за планом, поддерживают чужие идеи.
- дисфункциональные роли — ничего не делают, постоянно конфликтуют.
Еще одну схожую психологическую классификацию предложил Мередит Белбин. Он выделял среди участников команды такие типы, как председатель, оформитель, генератор идей, критик, рабочая пчёлка, опора команды, добытчик и завершающий.
Любая успешная проектная работа основана на четырёх базовых принципах:
- ясность и достижимость целей,
- реалистичность плана,
- определенность правил взаимодействия между всеми участниками,
- лидерство менеджера проекта.
Если следовать указанным принципам, то получится достичь синергии между членами команды. Понимание общих целей помогает команде уточнить промежуточные цели, за которые участники будут нести уже персональную ответственность. Реалистичный план гарантирует, что исполнители будут принимать как должное временные рамки, в которые поставлены.
Следовать указанным принципам помогают различные системы для управления проектами. Например, та же Timetta помогает планировать работы, распределять персонал по проектам, координировать действия некоторых участников. Однако бизнес-приложения не могут повлиять на связи внутри коллектива и само отношение людей к работе.
Благодаря исследованиям известно, что наибольших результатов добиваются следующие команды:
- в состав команды входит не более 10 человек,
- члены команды работают над проектом от начала до конца,
- члены команды уделяют проекту все свое рабочее время,
- участники разделяют принципы сотрудничества и доверия,
- все члены команды починяются непосредственно менеджеру проекта,
- команда полностью укомплектована нужными специалистами,
- проект интересен в профессиональном плане абсолютному большинству участников,
- все члены команды собраны в одном месте (или хотя бы могут регулярно взаимодействовать друг с другом).
Из приведённого списка условий видно, что в наиболее эффективные командах участники всегда тесно взаимодействуют по рабочим вопросам и при этом заинтересованы в общем результате. Однако с ростом проекта указанные условия соблюдать всё сложнее. Подлинный талант руководителя раскрывается только в больших проектах.
Мы уже касались матрицы RACI при рассмотрении ролей проекта. Однако круг вопросов, связанных с управлением командой проекта, не ограничивается только разграничением зон ответственности.
Американский исследователь Филипп Уикхэм (его книжка «Консалтинг в управлении проектами» переведена на русский) составил подробный опросник для проектирования проектных команд. Так, Уикхэм касался вопросов, связанных с организацией планирования, проведением совещаний, сдачей отчётов и других направлений работы.
Пример вопросов в блоке «Решение о сотрудничестве»?
- С какими отделами и организациями планирует взаимодействовать команда?
- Каковы роли и ответственность каждой организации?
- Как члены команды планируют обмениваться информацией друг с другом?
- Как информировать сторону о промежуточных результатах, сроках и прогнозах?
- Какой информацией нужно, а какой не нужно делиться?
Опросник показывает, насколько глубоко можно проработать модель управления. На практике довольно много организаций не тратят на это время, а сразу заимствует уже готовые модели. Например, SCRUM для проектов разработки бизнес-приложений.
Немного о SCRUM и других фреймворках
Фреймворк SCRUM был впервые детально описан американскими программистами Кеном Швабером и Джеффом Сазерлендом. Фреймворк содержит готовый набор ролей, артефактов, мероприятий для небольших команд разработчиков, которые создают бизнес-приложения в тесном контакте с заказчиком. Фреймворк позволяет быстро создавать и тестировать новые бизнес-возможности.
Хотя SCRUM многократно доказывал свою эффективность, он неприменим к масштабным, длительным проектам с высокими рисками. В таких случаях предпочтительнее использовать SAFe или подходы, изложенные, например, в PMBOK и PRINCE2
После пандемии всё больше компаний стали переходить к удаленным и гибридным формам работы. Накопленный опыт позволяет заключить, что несмотря на все технологические достижения, виртуальные команды проигрывают в эффективности традиционным формам организации работы.
Дело в том, что человек по своей природе существо социальное. Совместное общение и работа, постоянное чувство локтя повышают производительность как отдельных людей, так и группы в целом. Изоляция сотрудников препятствует общению, затрудняет обмен мнениями и усложняет координацию.
Постепенно эти проблемы удаётся решить за счёт более доступных средств коммуникации (групповых чатов, онлайн-конференций, различных облачных решений), однако улучшения заметны только в пределах небольших коллективов. Чем крупнее организация, тем сложнее наладить постоянное взаимодействие между коллегами, тем больше на это требуется денег и времени.
В целом существуют несколько проверенных рекомендаций, которые позволяют улучшить взаимодействие между участниками проекта.
- Проводить регулярные собрания между всеми участниками проектами. Совместное обсуждение проблем и общих задач поможет сотрудником втянуться в общую работу.
- Постоянно информировать участников команды о том, как идут дела над проектом. Лучше использовать облачные решения, чтобы сотрудник всегда мог увидеть, чем занимается коллега, какой объем работ выполнен и т. д.
- Не позволять членам команды выпадать из общего потока работ. Участникам виртуальных команд тяжело поддерживать постоянные контакт. Руководитель не всегда видит, чем занимается конкретный участник в данный момент. Это создает благодатную почву для абсентеизма.
- Разработать систему приоритетов. Участники должны четко понимать, на что они должны реагировать в первую очередь. Должны также существовать строгие правила обмена значимой для проекта информацией.
- Выработать правила решения споров и конфликтов. При виртуальном общении человек часто не видит лица собеседника и других знаков невербальной коммуникации. Это может приводить к недопониманию или ошибочной трактовке сказанных слов. Просите сотрудников четче формулировать свои мысли и пожелания, чтобы избавиться от разночтений. Глубже вникайте в слова собеседника.
Timetta помогает формировать проектные команды без ущерба для общих целей компании. Timetta будет полезна, если:
- Часть сотрудников задействована на нескольких проектах одновременно и не справляются с работой;
- Часть сотрудников систематически простаивает;
- Менеджеры проектов и руководители часто конфликтуют друг с другом за наиболее ценных кадры.
- Высшее руководство не может быстро понять, чем на самом деле занимаются линейный персонал, каков вклад каждого сотрудника в общее дело компании.
Timetta позволяет рационально управлять ресурсами и собирать данные о полезной загрузке персонала. Подробнее можно узнать из кейса GMSC. Все функции Timetta можно самостоятельно опробовать в бесплатной демоверсии.