сложность прогнозирования того, что необходимо рынку, темпы изменения внутри самого рынка – все это уменьшает эффективность использования автономных подходов.
Когда Borders передала свой книжный магазин компании Amazon, она не просто уступила свой канал конкуренту. Она лишила себя важной возможности вести двусторонний разговор с новым сегментом клиентов, взаимодействовать с их новым типом поведения, узнавать о том, что они хотят, и о том, как обслуживать этих клиентов в интернете. Неважно, что в 2001 году Borders не знала, как нужно управлять бизнесом в интернете. В то время почти никто об этом не знал. Согласитесь, что и Amazon в том числе. Но в период с 2001 по 2008 годы Borders – за свой, практически, счет, а также вследствие фактической передачи своих покупателей – предоставила компании Amazon возможность получить знания о том, как победить в этой игре. А все потому, что Borders позволила Amazon участвовать вместо себя в половине разговора, в ходе которого ей следовало бы общаться напрямую со своими покупателями.
Новая стратегия, формирующаяся благодаря технологической индустрии, дает нам возможность интегрировать этот двусторонний разговор в самую суть наших компаний. Давайте рассмотрим эту стратегию и поразмышляем о том, почему она так важна для нас.
Гибкая методология разработки: стратегия для информационной эпохи
Первыми людьми, которые искали новую стратегию, были инженеры-программисты, работавшие в 1980-х – 1990-х годах. Несколько разочарованных и вдумчивых практиков взглянули на процесс разработки программного обеспечения и задались вопросом, почему же так трудно создавать эффективные программные системы. (Оглядываясь назад, легко понять, почему было так много разочарований. Хорошо известное на тот момент исследование – «отчет 1994 года ”ХАОС”» компании Standish Group – показало, что 84 % ИТ-проекта либо не показывали никаких результатов, либо серьезно страдали от перерасхода средств и несоблюдения установленного графика). Эти специалисты-практики пришли к выводу, что методы, которые использовались для создания программного обеспечения, были основаны на неверной модели.
Основные на тот момент модели разработки программного обеспечения базировались на проверенных временем методиках прошлого столетия. Но они были пригодны для таких процессов, как производство машин и строительство зданий. Процессов, которые имели конкретные и понятные требования. Процессов с показателями усилия и нагрузки, а также с другими свойствами, которые можно было рассчитать с помощью проверенных уравнений. Процессы, которые вы смогли бы просчитать перед самым началом производства, а затем разработать планы для передачи строителям. Планы, которые не менялись после того, как начался процесс сборки.
Наша группа разочарованных специалистов-практиков поняла ключевое отличие в работе с программным обеспечением: после начала проекта всегда меняются требования. В течение многих лет программисты боролись с фактом изменения
