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

Чтобы перевести разговор с темы деталей, мы спросили: «Чего должна добиться успешная система? Если бы мы должны были доказать себе, что в систему стоит инвестировать, какую информацию мы бы использовали?» Этот разговор дал некоторые четкие, конкретные ответы. Прежде всего, система должна быть запущена в конкретный день, примерно через четыре месяца. Организация участвует в ежегодном мероприятии по случаю празднования дня отрасли, и ее руководители хотели бы продемонстрировать систему спонсорам. Мы спросили: «Что для вас значит запуск?» И снова их ответы были конкретными: нам нужно, чтобы X участников были активными со стороны волонтеров, а Y участников были активными со стороны организации. Поскольку цель сервиса состояла в том, чтобы количество волонтеров и организаций для совместной работы над проектами было сопоставимо, мы должны были сверстать Z соответствий: определенный процент пересечения этих совпадений должен был создать предпосылки для успешных, завершенных проектов.

Такими были наши показатели успеха: X и Y участников, Z совпадений, процент выполненных проектов. (На самом деле, обычно мы устанавливаем конкретные количественные цели, но для этой истории используем переменные).

Затем мы спросили: «Если мы сможем создать эту систему и достигнуть целей без каких-либо функций из вашего списка пожеланий, это вас устроит?» Тут начался более сложный разговор.

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

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

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

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

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

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

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