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

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

Agile-подход действительно дает возможность небольшим, эгалитарным командам принимать решения. В небольших масштабах это напоминает системы, подобные анархическим, с их радикально инклюзивным видением. Сторонники холакратии, например, утверждают, что вы можете управлять крупными организациями без традиционной иерархической системы. Последователи аgile-методов подобных заявлений не делали. Идея о том, что гибкая политика не вписывается в проблематику масштабных организаций и подходит только для уровня команд, была осмыслена технологическим консультантом Дэном Нортом. В ходе выступления на конференции в 2013 году он описал это следующим образом:

Agile-методы не масштабируются. Меня убеждали в этом больше десяти лет, и я просто отказывался верить оппонентам, однако они были правы. Означает ли это, что вы не можете выполнять крупномасштабные программы с использованием agile-методов? Вовсе нет.

Но для масштабирования вам нужно что-то еще, что-то существенно другое, о чем существующие agile-методы умалчивают[51].

УПРАВЛЕНИЕ НА ПРОГРАММНОМ И ПОРТФЕЛЬНОМ УРОВНЯХ

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

В последние годы подход agile перестал считаться методом для особо продвинутых и стал распространенным способом работы. Авторы недавнего доклада, подготовленного по заказу компании Hewlett-Packard, подсчитали, что более 90 % крупных организаций либо уже используют эти подходы, либо работают над их широким использованием[52]. И по мере обретения популярности этих методов, организации по всему миру пытаются найти решения для масштабирования гибкого подхода. Как указывает Норт, это обусловлено тем, что гибкость по существу является «командным» методом работы, а крупным организациям нужна система для координирования работы многих команд.

Один из наиболее популярных подходов к такому координированию называется масштабированный гибкий фреймворк, или SAFe (scaled agile framework). Как следует из аббревиатуры, SAFe дает менеджерам чувство комфорта. В конце концов, огромная организация, в которой существуют самоуправляемые команды – это кошмар для менеджеров. Очень похоже на анархию.

SAFe – это способ дробления больших проектов на небольшие части, работа над которыми поручается командам, а также создания системы подотчетности, гарантирующей, что команды завершат работу, на выполнение которой они подписались. Проблема данного подхода заключается в том, что он, собственно, является подходом «более детализированного плана», который исключает влияние неопределенности. SAFe уводит команды от подхода «почувствовать и отреагировать» и направляет к методам централизованного планирования. Фактически, это снижает статус гибкой команды до уровня производственной команды – ей выставляется фиксированный набор требований, и ожидается, что со сборочной линии сойдет конкретный произведенный товар. Этот подход может подойти для каких-то конкретных задач, но в целом он ограничивает возможность команды обучаться с помощью обратной связи по мере продвижения вперед. А ведь именно опыт обратной связи позволяет командам ориентироваться в условиях высокой неопределенности.

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

Использование целевых «дорожных карт»

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