Живые команды. Управление стрессом в проектах

М. – Можешь простыми словами объяснить, зачем эти стандарты нужны?

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

– Так по идее в разных сферах деятельности должны быть разные стандарты?

– Не совсем. Универсальные стандарты не зависят от типа проекта – создается ли программный продукт, конструируются ли вертолеты или возводятся здания. Если компания работает по единому стандарту, участники проектной деятельности смогут хорошо понимать друг друга. Кроме того, вместо «кусочного» фрагментарного управления стандарты дают единый управленческий подход.

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

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

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

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

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

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

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

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

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

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

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

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

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