Оказывается, бывают ситуации, когда эти понятия либо тождественны, либо имеют настолько понятную и четкую связь, что могли бы быть тождественными. Так часто происходит в промышленном производстве. Благодаря методике создания и проектирования промышленных товаров вы знаете, что если ваша производственная линия выпускает Модели-T, то можно быть вполне уверенным в том, что они будут функционировать так, как и было задумано. А благодаря многолетней истории продаж вы также можете быть уверены, что добьетесь успеха: вы будете продавать примерно то количество автомобилей, которое и планировали. Менеджеров, работающих по такой системе, можно простить за то, что они думают, будто их работа заключается просто в выполнении чего-либо.
Однако благодаря программному обеспечению связь между «мы выполнили это» и «это привело к планируемому эффекту» более-менее ясна. Будет ли наш недавно переделанный сайт действительно способствовать, например, росту аудитории или эти изменения приведут к неожиданным последствиям? Об этом очень трудно узнать без создания и тестирования системы. В отличие от промышленного производства, мы не создаем бесчисленное количество экземпляров одного товара. Вместо этого мы создаем единую систему (или набор взаимосвязанных систем, которые представляются нам как одна система) и зачастую не знаем до тех пор, пока не «выполним», будет ли то, что мы запускаем, работать по плану.
НАЦЕЛЕННОСТЬ НА РЕЗУЛЬТАТ НЕ СРАБОТАЕТ В НЕОПРЕДЕЛЕННОСТИ
Проблема неопределенности в сочетании с природой программного обеспечения означает, что управление нашими проектами с точки зрения результатов не является эффективной стратегией в цифровом мире. И все же наша культура управления и наши инструменты управления нацелены на работу с точки зрения результатов. Давайте для примера взглянем на то, как компании обычно покупают программное обеспечение у сторонних поставщиков.
В типичном процессе мы бы поручили внутренней команде разработать запрос на предложение (RFP – request for proposal). Этот запрос основывался бы на некотором анализе бизнес-проблемы, содержал описание характера решения и перечень требований (как правило, характеристик системы), а также просьбу поставщикам о представлении предложений.
На основе RFP поставщики представляют предложения, обычно информируя о способе решения: сколько времени это займет, кто будет над этим работать, сколько это будет стоить и, конечно, почему именно этот поставщик лучше прочих подходит для выполнения данной работы.
Как только мы выбираем поставщика, мы заключаем контракт, фиксирующий разработанные нами требования, а также цену и сроки, обещанные поставщиком. Подобного рода контракт свидетельствует, что обе стороны содействуют выполнению проекта, нацеленного на некий результат. Поставщик, скорее, стремится к созданию заданного набора функций (другими словами, к «выполнению»), чем к разработке чего-то, что принесет успех.
ОПРЕДЕЛЕНИЕ ПРОБЛЕМЫ В РЕЗУЛЬТАТЕ
Если вы приобретаете пользовательское программное обеспечение примерно тем способом, который описан, вы знаете, что происходит дальше. Поставщик не выполняет обещанное. Опытный ИТ-менеджер объясняет: «Проблема в фиксированных контрактах. Вы оба обманываете друг друга в том, что якобы понимаете, в чем состоит проблема». В результате, когда выясняется истинная природа проблемы, каждая из сторон должна вносить корректировки. Результат поправок? Поставщик опоздал и превысил бюджет. Но опытный менеджер знает: «В итоге всегда появляется проблема, и вместо того, чтобы решать ее или улучшать продукт, вы спорите о том, кто за это заплатит».
КАК FACEBOOK СМОГ ДОСТИЧЬ ВСЕМИРНОГО ВЛИЯНИЯ С ВЕСЬМА НЕБОЛЬШИМ ШТАТОМ СОТРУДНИКОВ И ЗА ТАКОЙ КОРОТКИЙ СРОК? КОНЕЧНО ЖЕ, БЛАГОДАРЯ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ.
АЛЬТЕРНАТИВА РЕЗУЛЬТАТУ – ЦЕЛЬ
Старое маркетинговое клише верно: покупатели не хотят полусантиментровое сверло дрели, они хотят, чтобы дрель просверлила полусантиметровое отверстие. Иначе говоря, их заботит конечный результат, и им совсем не интересно, какими средствами он будет достигнут. То же самое относится и к менеджерам: им все равно, как достичь своих бизнес-целей, они просто хотят их достичь.
Однажды в мире цифровых товаров и услуг появляется неопределенность и становится важным игроком, который разрывает связь между сверлом дрели и просверленной дырой. Некоторые менеджеры пытаются преодолеть проблемы, созданные неопределенностью, путем более тщательного планирования. Это стремление приводит к разработке детальных требований и нормативных документов, но, как мы поняли, такая тактика редко работает в мире программного обеспечения.