Цена упущенных возможностей

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

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

Похожая история произошла и с компанией Netscape – она потеряла лидерство на рынке браузеров в тот момент, когда решила попытаться обойти Microsoft в сегменте операционных систем.

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

Издержки прототипирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 1988 году Билл Гейтс купил у меня программу под названием Ruby. Это был язык визуального программирования, который впоследствии объединили с продуктом Билла QuickBasic, превратив его в Visual Basic. То, что первоначально увидел Гейтс, было всего лишь прототипом, но он демонстрировал значимые подвижки в применении проектирования и технологии. (Взглянув на это впервые, он воскликнул: «Как тебе удалось это сделать?») К работе над проектом Ruby был также привлечен Расс Вернер, в то время руководивший разработкой Windows 3.0. Далее мы заключили сделку, согласно которой я должен был написать полноценную программу и довести проект Ruby до завершения. Первым делом я отбросил прототип и начал все заново, с чистого листа, руководствуясь лишь своим опытом и здравым смыслом. Когда об этом узнал Расс, он был страшно удивлен, зол и разъярен. Никто и никогда еще не поступал таким возмутительным образом, и потому он был убежден, что, отбросив прототип, мы тем самым сорвем сроки выпуска продукта. Но все уже свершилось, и, несмотря на опасения Расса, мы завершили создание программы строго по графику. Интеграция среды VB с языком Basic сделала этот продукт одним из самых удачных ранних релизов для Microsoft. В противовес этому событию выпуск Windows 3.0 задержался более чем на год, и с тех пор он пользовался дурной славой неполноценного продукта ввиду чрезмерного количества неиспользуемого кода, оставшегося от прототипа.

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

Как бы то ни было, успешная демонстрация прототипа отразилась на Ральфе отнюдь не самым благоприятным образом. Президент был так впечатлен функционированием «системы», что поручил Ральфу сделать на ее основе готовый продукт. Ральф запротестовал, заявив, что это была только проверка возможности реализации и что она недостаточно надежна, чтобы делать миллионы пользовательских устройств на ее основе. Президент и слышать ничего не хотел. Он своими глазами видел прототип в действии. Ральф уступил, и через восемь долгих лет его компания наконец-то выпустила первый работоспособный релиз продукта. Он работал медленно, содержал множество багов и сильно уступал даже более молодым, новым продуктам конкурентов. Газета New York Times окрестила его «полнейшей катастрофой».

Тот опыт и знания, которые Ральф и его команда получили в процессе создания некорректно функционирующего прототипа, были гораздо более ценны, чем непосредственно код. Президент не сумел этого понять и отдал предпочтение коду, отчего пострадала вся компания.

* * *

Если ставить рамки проекта лишь по дедлайнам и набору опций, то даже выпуск точно в срок не сделает его желанным. Если же описывать проект категориями качества и степени удовлетворенности потребителей, то получится востребованный продукт, сроки разработки которого останутся в допустимых пределах. В Кремниевой долине есть одна старая шутка: «Как сколотить небольшое состояние на разработке программного обеспечения? Ответ: разумеется, начать с большого состояния!» Проекты по созданию программного обеспечения, даже под началом опытных руководителей, влекут такие большие скрытые издержки, которые способны поразить даже Дональда Трампа. Если принять во внимание долгосрочную перспективу, то гонки на яхтах и увлечение наркотическими веществами обойдутся дешевле, чем бесконтрольное создание программного обеспечения.