В последние годы подход agile перестал считаться методом для особо продвинутых и стал распространенным способом работы. Авторы недавнего доклада, подготовленного по заказу компании Hewlett-Packard, подсчитали, что более 90 % крупных организаций либо уже используют эти подходы, либо работают над их широким использованием[52]. И по мере обретения популярности этих методов, организации по всему миру пытаются найти решения для масштабирования гибкого подхода. Как указывает Норт, это обусловлено тем, что гибкость по существу является «командным» методом работы, а крупным организациям нужна система для координирования работы многих команд.
Один из наиболее популярных подходов к такому координированию называется масштабированный гибкий фреймворк, или SAFe (scaled agile framework). Как следует из аббревиатуры, SAFe дает менеджерам чувство комфорта. В конце концов, огромная организация, в которой существуют самоуправляемые команды – это кошмар для менеджеров. Очень похоже на анархию.
SAFe – это способ дробления больших проектов на небольшие части, работа над которыми поручается командам, а также создания системы подотчетности, гарантирующей, что команды завершат работу, на выполнение которой они подписались. Проблема данного подхода заключается в том, что он, собственно, является подходом «более детализированного плана», который исключает влияние неопределенности. SAFe уводит команды от подхода «почувствовать и отреагировать» и направляет к методам централизованного планирования. Фактически, это снижает статус гибкой команды до уровня производственной команды – ей выставляется фиксированный набор требований, и ожидается, что со сборочной линии сойдет конкретный произведенный товар. Этот подход может подойти для каких-то конкретных задач, но в целом он ограничивает возможность команды обучаться с помощью обратной связи по мере продвижения вперед. А ведь именно опыт обратной связи позволяет командам ориентироваться в условиях высокой неопределенности.
Вместо того, чтобы пытаться вписать гибкость в систему руководства и управления, многие организации придерживаются принципов координирования, больше похожих на командование, – как правило, создают то, что мы называем целевыми «дорожными картами».
Использование целевых «дорожных карт»
Такие «дорожные карты» принимают различные формы. Мы рассмотрим некоторые из них в следующем разделе, но прежде давайте выявим их ключевые элементы. Целевые «дорожные карты» эффективны, потому что они помогают реализовать мультикомандную координацию. Они представляют собой способ каскадного формулирования ключевых элементов, необходимых для руководства работой команд:
• Стратегическое намерение («Мы хотим увеличить долю организации на рынке в десять раз»);
• Стратегические ограничения («Мы сделаем это путем создания онлайн-сервиса, который должен начать работать к X числу»);
• Определение успеха («Сервис будет сопоставлять показатели в X процентов»).
При правильной реализации целевые «дорожные карты» помогают организациям обеспечить согласованность, которая имеет решающее значение для управления работой команд.
КОММУНИКАЦИИ «СНИЗУ-ВВЕРХ» И «СВЕРХУ-ВНИЗ»
Существует критический компонент руководства, который выходит за рамки того, что вы обсуждаете. Не менее важно то, как вы передаете свои мысли. Информация должна идти и «сверху вниз», по цепочке командования, и в обратном направлении. Иначе говоря, общение должно идти в обоих направлениях, и этот обмен данными «сверху» и «снизу» должен циркулировать постоянно. Он продолжителен во времени. Только в такого рода процессе коммуникаций формируется согласованность.
Работая над этой книгой, мы узнали о компании, которая рассматривала эти методы как часть ежегодного планирования. Эта американская фирма – стартап, занимающийся онлайн-торговлей, – является одной из наиболее успешных организаций, практикующих гибкие методы. Они не из тех, кто делает все «по правилам». Компания воплощает многие идеи и приемы, свойственные гибкому подходу. Помимо всего прочего, фирма является одним из первых и успешных последователей метода, называемого процессом непрерывного развертывания, – сторонником идеи о том, что программное обеспечение выпускается не каждые несколько месяцев или каждые пару недель, а непрерывно. (Мы рассказывали об этом в Главе 1. Это процесс, с помощью которого Amazon способен выпускать обновление каждые 11,6 сек). На протяжении многих лет они развивали культуру экспериментов, A/B-тестирования и оптимизации.
[52] TechBeacon, “State of Performance Engineering, 2015–2016 Edition,” http://techbeacon.com/sites/default/fi les/State-of-Performance-Engineering-2015-16_FINAL2.pdf.