Понятно, что руководители, подписавшие контракт, были обеспокоены: какие у них гарантии того, что это будет полноценный проект?

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

Наш контракт с Taproot содержал не только список желаемых функций, но и список желаемых целей. Вот цели, которые мы вписали в этот контракт:

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

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

Стоит признать, что многие организации не обладают достаточной гибкостью с точки зрения процессов финансирования проектов и правил закупок, поэтому для их руководителей такого рода контракт может оказаться вне пределов компетенции. Однако, как мы обсуждали в Главе 3, дальновидные организации работают над тем, чтобы это изменить.

ВИДЕНИЕ РЕЗУЛЬТАТОВ

Так как же продвигался проект? Сначала команда считала, что самой важной вехой является запуск системы. Чтобы не ждать четыре месяца (срок исполнения проекта), члены команды решили запустить ее как можно скорее. Как оказалось, они смогли выйти в эфир для пробной аудитории в течение месяца. Они запустили радикально упрощенную версию сервиса с очень небольшим количеством автоматических функций. Большая часть работы в системе выполнялась вручную специальным человеком, комьюнити-менеджером (комьюнити-менеджер – специалист в области создания, поддержки и развития сообществ/структур – перев.), действующим за кулисами. (Подобный подход, который использовался командой Cooking Light Diet, мы описали в Главе 2).

Этот диспетчерский подход к минимальному жизнеспособному продукту (MVP) стал популярным способом запуска систем. Команда Taproot знала, что потребуется больше автоматизации, если она хочет, чтобы система расширялась в масштабах, но также она знала, что автоматизация может появиться и позже. Досрочный запуск достиг двух целей. Во-первых, он гарантировал, что команде будет что показать спонсорам на ежегодном мероприятии. Это было чрезвычайно важной маркетинговой и торговой целью. А во-вторых, что более важно, он позволил команде выяснить, какие функции ей действительно понадобятся для масштабной работы системы. Другими словами, это вывело команду в режим «почувствовать и отреагировать» – двусторонний разговор с рынком, который и будет направлять развитие сервиса.

Например, проектировщики предполагали, что квалифицированные волонтеры должны иметь возможность создавать в сервисе профили. Затем организации будут просматривать эти профили и отбирать волонтеров, которые пришлись им по душе. Это оказалось совершенно неверным. Когда команда предложила волонтерам создавать профили, те ответили безразличием. Команда осознала – для того чтобы система работала, волонтеров придется замотивировать к участию: им необходимо подыскать проекты, которые им понравятся. Для этого нужны списки проектов, а не списки волонтеров. Иначе говоря, команда должна была изменить порядок системы, поскольку первоначальные планы были неверными.

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

Решение проблемы местных знаний

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

Данный подход к руководству проектами не распространен, мы чаще наблюдаем его в командах стартапов и в небольших организациях. Проект Taproot был разработан небольшой командой, которая мало что согласовывала с другими. Масштабирование этого подхода до многочисленных команд и крупных организаций является сложной и деликатной проблемой, которая требует соблюдения тщательного баланса между централизованным планированием и децентрализованными полномочиями.

Мы увидели много примеров провала централизованного планирования в современную эпоху. Достаточного вспомнить неудачи советского блока и коммунистической китайской экономики XX века, чтобы увидеть примеры того, что экономисты называют проблемой местных знаний: речь о том, что центральные органы планирования не имеют четкого понимания реальности на местах для разработки адекватных детальных планов. Сколько хлеба нужно в этом городе? Сколько пшеницы нужно поставить этой фабрике? А что если будет плохой урожай? Что если на складе случится пожар? Что если в регионе едят рис?

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

Agile-подход действительно дает