Ознакомительная версия. Доступно 11 страниц из 55
возможность небольшим, эгалитарным командам принимать решения. В небольших масштабах это напоминает системы, подобные анархическим, с их радикально инклюзивным видением. Сторонники холакратии, например, утверждают, что вы можете управлять крупными организациями без традиционной иерархической системы. Последователи аgile-методов подобных заявлений не делали. Идея о том, что гибкая политика не вписывается в проблематику масштабных организаций и подходит только для уровня команд, была осмыслена технологическим консультантом Дэном Нортом. В ходе выступления на конференции в 2013 году он описал это следующим образом:
Agile-методы не масштабируются. Меня убеждали в этом больше десяти лет, и я просто отказывался верить оппонентам, однако они были правы. Означает ли это, что вы не можете выполнять крупномасштабные программы с использованием agile-методов? Вовсе нет.
Но для масштабирования вам нужно что-то еще, что-то существенно другое, о чем существующие agile-методы умалчивают[51].
УПРАВЛЕНИЕ НА ПРОГРАММНОМ И ПОРТФЕЛЬНОМ УРОВНЯХ
На примере Taproot мы наблюдали, как одна команда смогла приблизиться к созданию проекта с помощью agile-методов. Но если мы действительно хотим создать agile-организации, нам следует рассмотреть, как гибкий подход может быть применим не только на уровне команды, но и на двух следующих уровнях. Первый – это программный уровень, когда группа из двух или более команд сотрудничает между собой и работает над достижением общей цели. Второй – портфельный уровень, отражающий совокупность всей работы организации.
В последние годы подход agile перестал считаться методом для особо продвинутых и стал распространенным способом работы. Авторы недавнего доклада, подготовленного по заказу компании Hewlett-Packard, подсчитали, что более 90 % крупных организаций либо уже используют эти подходы, либо работают над их широким использованием[52]. И по мере обретения популярности этих методов, организации по всему миру пытаются найти решения для масштабирования гибкого подхода. Как указывает Норт, это обусловлено тем, что гибкость по существу является «командным» методом работы, а крупным организациям нужна система для координирования работы многих команд.
Один из наиболее популярных подходов к такому координированию называется масштабированный гибкий фреймворк, или SAFe (scaled agile framework). Как следует из аббревиатуры, SAFe дает менеджерам чувство комфорта. В конце концов, огромная организация, в которой существуют самоуправляемые команды – это кошмар для менеджеров. Очень похоже на анархию.
SAFe – это способ дробления больших проектов на небольшие части, работа над которыми поручается командам, а также создания системы подотчетности, гарантирующей, что команды завершат работу, на выполнение которой они подписались. Проблема данного подхода заключается в том, что он, собственно, является подходом «более детализированного плана», который исключает влияние неопределенности. SAFe уводит команды от подхода «почувствовать и отреагировать» и направляет к методам централизованного планирования. Фактически, это снижает статус гибкой команды до уровня производственной команды – ей выставляется фиксированный набор требований, и ожидается, что со сборочной линии сойдет конкретный произведенный товар. Этот подход может подойти для каких-то конкретных задач, но в целом он ограничивает возможность команды обучаться с помощью обратной связи по мере продвижения вперед. А ведь именно опыт обратной связи позволяет командам ориентироваться в условиях высокой неопределенности.
Вместо того, чтобы пытаться вписать гибкость в систему руководства и управления, многие организации придерживаются принципов координирования, больше похожих на командование, – как правило, создают то, что мы называем целевыми «дорожными картами».
Использование целевых «дорожных карт»
Такие «дорожные карты» принимают различные формы. Мы рассмотрим некоторые из них в следующем разделе, но прежде давайте выявим их ключевые элементы. Целевые «дорожные карты» эффективны, потому что они помогают реализовать мультикомандную координацию. Они представляют собой способ каскадного формулирования ключевых элементов, необходимых для руководства работой команд:
• Стратегическое намерение («Мы хотим увеличить долю организации на рынке в десять раз»);
• Стратегические ограничения («Мы сделаем это путем создания онлайн-сервиса, который должен начать работать к X числу»);
• Определение успеха («Сервис будет сопоставлять показатели в X процентов»).
При правильной реализации целевые «дорожные карты» помогают организациям обеспечить согласованность, которая имеет решающее значение для управления работой команд.
КОММУНИКАЦИИ «СНИЗУ-ВВЕРХ» И «СВЕРХУ-ВНИЗ»
Существует критический компонент руководства, который выходит за рамки того, что вы обсуждаете. Не менее важно то, как вы передаете свои мысли. Информация должна идти и «сверху вниз», по цепочке командования, и в обратном направлении. Иначе говоря, общение должно идти в обоих направлениях, и этот обмен данными «сверху» и «снизу» должен циркулировать постоянно. Он продолжителен во времени. Только в такого рода процессе коммуникаций формируется согласованность.
Работая над этой книгой, мы узнали о компании, которая рассматривала эти методы как часть ежегодного планирования. Эта американская фирма – стартап, занимающийся онлайн-торговлей, – является одной из наиболее успешных организаций, практикующих гибкие методы. Они не из тех, кто делает все «по правилам». Компания воплощает многие идеи и приемы, свойственные гибкому подходу. Помимо всего прочего, фирма является одним из первых и успешных последователей метода, называемого процессом непрерывного развертывания, – сторонником идеи о том, что программное обеспечение выпускается не каждые несколько месяцев или каждые пару недель, а непрерывно. (Мы рассказывали об этом в Главе 1. Это процесс, с помощью которого Amazon способен выпускать обновление каждые 11,6 сек). На протяжении многих лет они развивали культуру экспериментов, A/B-тестирования и оптимизации.
Аgile-методы позволяют применить экспериментальный подход к выпуску новой программы. К примеру, компания хочет изменить дизайн страницы продукта на своем веб-сайте. Вместо того, чтобы гадать, в каком исполнении страница будет работать лучшего всего, она быстро разрабатывает и создает несколько версий страницы, запускает их на сайте, направляет часть контролируемых пользователей к каждой из версий, а затем определяет, какая из страниц лучшая.
Такой подход, основанный на эксперименте и легкий в исполнении, дает значительные результаты, а потому он быстро стал основным элементом культуры компании. Для команд вполне естественно работать таким образом, постоянно тестируя и оптимизируя свою работу. Правда, как-то один менеджер рассказал нам о том, что в прошлом такая схема как раз способствовала появлению проблем: «Мы сосредоточились на быстрых победах, а не на программировании». Похоже, что проблема заключалась в выборе того, что именно нужно тестировать, а в более общем плане – над чем нужно работать. Когда компания была меньше, было проще согласовывать работу команд неформальным образом. Однако по мере роста понадобилась большая координация.
К концу 2015 года компания насчитывала уже 5 тысяч сотрудников, ее годовой доход оценивался в сотни миллионов долларов. Проблема с координированием становилась все более острой. Руководители понимали, что они должны обеспечить большую согласованность. При разработке «дорожной карты» на год они использовали методы планирования и «сверху-вниз», и «снизу-вверх».
СОЗДАНИЕ ЦЕЛЕВОЙ «ДОРОЖНОЙ КАРТЫ»
В первой части работы участвовали высшие руководители, которые представили перечень стратегических задач на следующий год. Эти темы стали инструкцией «сверху-вниз» – координирующими идеями, которые
Ознакомительная версия. Доступно 11 страниц из 55
