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

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

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

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

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

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

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

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

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