Читать книгу Живые команды. Управление стрессом в проектах - Алексей Таченков - Страница 7

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

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

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

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

• Руководитель проекта – управленец, на котором лежит вся полнота ответственности за результаты проекта. Тот, кто должен принимать управленческие решения в проекте.

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

• Команда исполнения проекта – специалисты, которые непосредственно задействованы в исполнении планов проекта и обладающие профильными знаниями и навыками.

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

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

Руководитель проекта, человек старой закалки, решил управлять всеми процессами по исторически сложившемуся каскадному методу, но автоматизацию разбить на функциональные блоки. Так, чтобы в каждой команде работало не более чем 10‒12 специалистов. При этом каждая мини-команда имела свободу выбора подхода для работы – (PMBOK, SCRUM, Kanban и т. д.). Главным требованием к командам было наличие общих промежуточных результатов в четко определенные моменты времени.

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

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