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

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

Каждый из подходов, стандартов, методов формулирует свой набор ценностей. Например, практики Agile исходят из идеи, максимально близкой VUCA-миру, известной как Agile-манифест:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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