Ко второму месяцу проекта команда создала систему с пересмотренным порядком действий, а затем сосредоточилась на ее настройке – определении деталей, необходимых в бизнес-процессах, и создании программного обеспечения для поддержки этих процессов. Как команде облегчить перечисление проектов организациям? Как убедиться в том, что списки мотивируют волонтеров? Насколько простой может быть контактная система? Как упростить планирование встреч? К окончанию четырехмесячного проекта у команды появилась система, созданная и запущенная в течение трех месяцев, намного превосходящая цели производительности, прописанные в контракте.
Решение проблемы местных знаний
Подобные проекты работают потому, что они следуют гибким принципам руководства. Они предоставляют командам стратегию и набор целей для достижения, наряду с набором ограничений, а также предоставляют свободу использовать свои знания о ситуации для решения проблем. В данном случае стратегия, которой придерживалась Taproot Foundation, заключалась в использовании возможностей интернета увеличить влиятельность организаций в десятки раз. Стратегические ограничения для проекта также были ясны: спонсоры платили за то, чтобы команда создала онлайн-сервис подбора. Независимо от того, как действовала команда, она должна была создать этот сервис, хоть и заручилась значительной долей свободы для определения того, как он будет выглядеть. Также у команды были жесткие ограничения по дате: система должна была быть запущена через четыре месяца. Но у команды было достаточно свободы, чтобы решить, как ей функционировать.
Данный подход к руководству проектами не распространен, мы чаще наблюдаем его в командах стартапов и в небольших организациях. Проект Taproot был разработан небольшой командой, которая мало что согласовывала с другими. Масштабирование этого подхода до многочисленных команд и крупных организаций является сложной и деликатной проблемой, которая требует соблюдения тщательного баланса между централизованным планированием и децентрализованными полномочиями.
Мы увидели много примеров провала централизованного планирования в современную эпоху. Достаточного вспомнить неудачи советского блока и коммунистической китайской экономики XX века, чтобы увидеть примеры того, что экономисты называют проблемой местных знаний: речь о том, что центральные органы планирования не имеют четкого понимания реальности на местах для разработки адекватных детальных планов. Сколько хлеба нужно в этом городе? Сколько пшеницы нужно поставить этой фабрике? А что если будет плохой урожай? Что если на складе случится пожар? Что если в регионе едят рис?
Противоположностью централизованного планирования является децентрализация власти. На периферии этого децентрализованного спектра находятся такие явления, как анархия, холакратия и даже, в глазах некоторых, гибкая разработка программного обеспечения.
Agile-подход действительно дает возможность небольшим, эгалитарным командам принимать решения. В небольших масштабах это напоминает системы, подобные анархическим, с их радикально инклюзивным видением. Сторонники холакратии, например, утверждают, что вы можете управлять крупными организациями без традиционной иерархической системы. Последователи аgile-методов подобных заявлений не делали. Идея о том, что гибкая политика не вписывается в проблематику масштабных организаций и подходит только для уровня команд, была осмыслена технологическим консультантом Дэном Нортом. В ходе выступления на конференции в 2013 году он описал это следующим образом:
Agile-методы не масштабируются. Меня убеждали в этом больше десяти лет, и я просто отказывался верить оппонентам, однако они были правы. Означает ли это, что вы не можете выполнять крупномасштабные программы с использованием agile-методов? Вовсе нет.
Но для масштабирования вам нужно что-то еще, что-то существенно другое, о чем существующие agile-методы умалчивают[51].
УПРАВЛЕНИЕ НА ПРОГРАММНОМ И ПОРТФЕЛЬНОМ УРОВНЯХ
На примере Taproot мы наблюдали, как одна команда смогла приблизиться к созданию проекта с помощью agile-методов. Но если мы действительно хотим создать agile-организации, нам следует рассмотреть, как гибкий подход может быть применим не только на уровне команды, но и на двух следующих уровнях. Первый – это программный уровень, когда группа из двух или более команд сотрудничает между собой и работает над достижением общей цели. Второй – портфельный уровень, отражающий совокупность всей работы организации.
[51] Dan North, “Why Agile Doesn’t Scale, and What You Can Do About It,” presentation at GOTO conference, September 30, 2013, http://gotocon.com/aarhus-2013/presentation/Why+Agile+doesn’t+scale,+and+what+you+can+do+about+it. When we spoke to North, he went on to say, “If you want to scale and be agile, the solution may not be more scrum teams.” (Scrum is the most popular agile method. When people think of agile, they’re usually thinking of scrum.) Instead, he told us, “When you have a lot of work to do,you have to ask, What is the shape of the work, and what’s the best shape of people to do the work?” North described a process of asking these questions quarterly and adjusting assignments and organization