Алексей Таченков - Живые команды. Управление стрессом в проектах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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