Продукт, вечно не готовый к выпуску
Часто причиной этому служит глубочайший страх каждого, кто руководит разработкой программного обеспечения: если продукт опаздывает, он вообще никогда не будет выпущен. Нет сомнения в правдивости историй о продуктах, которым так и не суждено было увидеть свет. Проект опаздывает сначала на год, потом на два, а потом, на третьем году жизни, его мстительно подвергают эвтаназии руководители высшего звена или члены директората. Это объясняет неистовую приверженность к фиксированным срокам сдачи, пусть даже ценой жизнеспособности продукта.
Для примера – в конце девяностых годов в широко разрекламированной начинающей компании Worlds, Inc. масса умных и способных людей работали над созданием сетевого виртуального мира, где люди, посредством своих аватар, могли бы путешествовать и общаться с другими людьми в реальном времени. Продукт никогда не имел четкого определения или описания, и после растраты десятков миллионов инвестированных долларов члены правления компании милосердно прекратили эту агонию.
В начале девяностых другая начинающая компания, Nomadic Computing, потратила около 15 миллионов долларов, пытаясь создать новый продукт для мобильных деловых людей. К сожалению, никто в этой компании не знал точно, что это за продукт. Все было ясно с рыночной нишей продукта, и были известны возможности программы, однако не было четкого понимания целей потенциальных пользователей. Словно безумные скульпторы, обтесывающие гигантский мраморный камень в надежде обнаружить внутри статую, разработчики писали невероятные объемы бесполезного кода, который в конечном итоге просто выбросили, вместе с деньгами, временем, репутацией и карьерами. Самая же печальная потеря в этой истории – потеря возможности создать востребованную программу.
Даже корпорация Мiсrоsоft не обладает иммунитетом против подобных заблуждений. Ее первая попытка создать продукт для управления базами данных в конце восьмидесятых годов поглотила множество человеко-лет, и Билл Гейтс в конечном итоге, милосердно закрыл проект. Преждевременная смерть проекта ударной волной прокатилась по сообществу разработчиков. Следующий продукт этого направления, Access, разрабатывался с нуля другими разработчиками и другими руководителями.
По иронии судьбы поздний выпуск продукта обычно не является смертельным событием. Опоздавший продукт среднего качества часто оказывается провальным, но если ваш продукт представляет ценность для пользователей, нарушение расписания не обязательно приведет к долговременным отрицательным эффектам. Если продукт оказывается настоящим хитом, то опоздание на месяц – и даже на год – значения совершенно не имеет. Напротив, если продукт отвратительный, – кому интересно, что он выпущен вовремя?
