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

Компания Pets.com, специализирующаяся на продаже корма для собак через интернет, не предлагала более качественный корм, как не предлагала и шопинг, более приятный, чем в обычном зоомагазине; она не предлагала новую информацию, новые возможности, новую уверенность. Она предлагала лишь дешевую доставку, складирование и торговлю (все это переменные затраты) на сайте Pets.com. Компания применила классическую тактику снижения затрат, характерную для промышленной эпохи, проигнорировав фундаментальные принципы новой экономики. Конечно, это было еще не первое дыхание новой экономики, но для старой это были последние судороги. Я совершенно убежден, что любой товар можно продавать через интернет успешно и прибыльно. Для этого всего лишь нужно, чтобы в онлайн-магазине было намного приятнее покупать, чем в конкурирующих розничных сетях, и цена здесь – всего лишь один из факторов. Есть лишь один способ добиться этого: архитектуру системы следует создавать с целью максимально удовлетворить конечного пользователя. Нельзя относиться к любому аспекту проектирования и создания программного обеспечения как к производственному процессу – это повлечет за собой провал. Проектирование и программирование – это неподходящие цели для традиционных методов сокращения затрат. Конечно, можно потратить на создание программ слишком много времени и денег, но опасность потратить меньше необходимого гораздо серьезнее.

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

Корпорации уже нанимают проектировщиков взаимодействия и начинают применять целеориентированный подход, однако качество программных продуктов не слишком улучшилось. Более того, высокие затраты на программирование и жесткий процесс создания программ никуда не делись. Почему?

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

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

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

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

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

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