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

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

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

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

Определение слова «выполнено» как «успешно»

Действительно ли компании предпочитают «выполнено», а не успех? И если так, то зачем?

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

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

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

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

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

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

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

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