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

В отличие от промышленного производства, мы не создаем бесчисленное количество экземпляров одного товара. Вместо этого мы создаем единую систему (или набор взаимосвязанных систем, которые представляются нам как одна система) и зачастую не знаем до тех пор, пока не «выполним», будет ли то, что мы запускаем, работать по плану.

НАЦЕЛЕННОСТЬ НА РЕЗУЛЬТАТ НЕ СРАБОТАЕТ В НЕОПРЕДЕЛЕННОСТИ

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

В типичном процессе мы бы поручили внутренней команде разработать запрос на предложение (RFP – request for proposal). Этот запрос основывался бы на некотором анализе бизнес-проблемы, содержал описание характера решения и перечень требований (как правило, характеристик системы), а также просьбу поставщикам о представлении предложений.

На основе RFP поставщики представляют предложения, обычно информируя о способе решения: сколько времени это займет, кто будет над этим работать, сколько это будет стоить и, конечно, почему именно этот поставщик лучше прочих подходит для выполнения данной работы.

Как только мы выбираем поставщика, мы заключаем контракт, фиксирующий разработанные нами требования, а также цену и сроки, обещанные поставщиком. Подобного рода контракт свидетельствует, что обе стороны содействуют выполнению проекта, нацеленного на некий результат. Поставщик, скорее, стремится к созданию заданного набора функций (другими словами, к «выполнению»), чем к разработке чего-то, что принесет успех.

ОПРЕДЕЛЕНИЕ ПРОБЛЕМЫ В РЕЗУЛЬТАТЕ

Если вы приобретаете пользовательское программное обеспечение примерно тем способом, который описан, вы знаете, что происходит дальше. Поставщик не выполняет обещанное. Опытный ИТ-менеджер объясняет: «Проблема в фиксированных контрактах. Вы оба обманываете друг друга в том, что якобы понимаете, в чем состоит проблема». В результате, когда выясняется истинная природа проблемы, каждая из сторон должна вносить корректировки. Результат поправок? Поставщик опоздал и превысил бюджет. Но опытный менеджер знает: «В итоге всегда появляется проблема, и вместо того, чтобы решать ее или улучшать продукт, вы спорите о том, кто за это заплатит».

КАК FACEBOOK СМОГ ДОСТИЧЬ ВСЕМИРНОГО ВЛИЯНИЯ С ВЕСЬМА НЕБОЛЬШИМ ШТАТОМ СОТРУДНИКОВ И ЗА ТАКОЙ КОРОТКИЙ СРОК? КОНЕЧНО ЖЕ, БЛАГОДАРЯ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ.

АЛЬТЕРНАТИВА РЕЗУЛЬТАТУ – ЦЕЛЬ

Старое маркетинговое клише верно: покупатели не хотят полусантиментровое сверло дрели, они хотят, чтобы дрель просверлила полусантиметровое отверстие. Иначе говоря, их заботит конечный результат, и им совсем не интересно, какими средствами он будет достигнут. То же самое относится и к менеджерам: им все равно, как достичь своих бизнес-целей, они просто хотят их достичь.

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

Оказывается, подобную проблему – срыв планов вследствие неопределенности и ошибочную реакцию в виде составления все более подробных планов – военные командиры пытались решить на протяжении сотен, если не тысяч лет. Они разработали систему военного руководства под названием управление целями как альтернативу жесткой системе руководства, которая очень подробно определяет, что подразделения должны делать в бою. Новая гибкая система, напротив, предписывает высшему командованию устанавливать цели и задачи, но при этом оставляет принятие конкретных решений людям, ведущим боевые действия. В работе Стивена Бунгей «The Art of Action» прослеживается развитие этих идей в прусской армии 1800-х годов и описывается система, которую военачальники разработали для того, чтобы справляться с неопределенностью на поле битвы[50].

Такое гибкое командование строится на трех важных принципах:

• Не командуйте больше, чем нужно, или не планируйте сверхпредсказуемые условия;

• Донесите до каждого подразделения как можно больше идей, необходимых для достижения цели;

• Убедитесь в том, что каждый человек свободен в принятии решений в пределах своей ответственности.

В переложении к нашим целям это означает, что мы будем ориентировать команды на цель, которую хотим достичь (наше намерение), предоставляя им большую, но с определенными ограничениями, степень самостоятельности для ее достижения, и при этом будем готовы к тому, что наши планы будут корректироваться по мере их выполнения.

УПРАВЛЕНИЕ ЦЕЛЯМИ

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

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

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

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

Затем мы спросили: «Если мы сможем создать эту систему и достигнуть целей без каких-либо функций из