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

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

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

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

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

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

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

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

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