1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с клиентом важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

О чем этот набор установок? Часто в жестких иерархичных организациях (да и не только в них) самыми важными приоритетами являлись следование процессам, использование предопределенных инструментов, документирование всех процессов, догмат единожды и навсегда сформированного плана.

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

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

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

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

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

– Ценности? Ха! Да, я тебе расскажу, как у нас с ценностями работают!

– Так, судя по началу, продолжение будет интересное.

– У нас ценности – это то, что нужно зазубрить и четко по номерам на тестировании рассказать. А не расскажешь и не вспомнишь – сам понимаешь…

Из беседы со знакомым руководителем проекта

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

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

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

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

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

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

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

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

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

В разных подходах приняты разные способы организации структуры команды.

Рис. 8. Модели организационной структуры команды

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

В среде Agile команда самоорганизующаяся (по крайней мере по изначальной задумке) и в качестве лидера выступает специалист, который владеет знаниями в организационной психологии, навыками коучинга и фасилитации. Его задача – создать такую среду в коллективе, чтобы все могли максимально реализовать свои возможности и достичь совместного результата. Считается, что идеальной командой в такой среде является «плоская» структура, в которой в чистом виде нет подчинения и уровней власти. Причем есть несколько принципов, характерных именно для Agile-команды:

небольшие кросс-функциональные команды (7±2 человека) добиваются лучших результатов;

делают короткие итерации;

автономны и полностью вовлечены в работы над проектом; мотивированы общими командными целями и показателями эффективности;

достигают мастерства, обогащая работу друг друга.

Каждая команда идет к успеху своим путем, но, если быть внимательным, можно увидеть общее: одни и те же стадии групповой динамики. Каждая команда проходит в своем развитии несколько характерных стадий, на которых с людьми происходят определенные психологические процессы. Этот подход первоначально был описан Брюсом Такманом.

М.: Недавно услышала мнение коллеги, что Брюс Такман был не прав и нет подтверждений, что команды проходят именно эти стадии.

А.: Я еще не встречал команду, которая бы не проходила.

М.: Согласна. Кто-то более выраженно, кто-то менее, в разном темпе. Но каждый раз я восхищаюсь, насколько это понятная и ясная модель и как красиво разворачиваются эти групповые процессы. В общем, я не стала спорить с коллегой. Верит, что Такман не прав, и ладно.

Давайте посмотрим в целом на психодинамику применительно к проектным командам в рамках этого подхода.