Файл: Алан Купер Психбольница в руках пациентов.pdf

81 таки появился). Все поддающиеся количественному измерению аспекты разработки находились в пределах нормы. Единственное заключение, которое мог сделать этот сведущий в руководстве инвестор, сводилось к существованию неожиданной аномалии рынка. Как мы могли потерпеть неудачу, если все датчики показывали нормальные цифры?
Объективность подобных измерений придает всем уверенности. Объективные и количественные показатели пользуются высоким уважением среди программистов и деловых людей. Неэффективность же таких измерений с точки зрения создания успешных продуктов как-то упускается из виду. Если продукт оказывается успешным, отцы-основатели приписывают все заслуги себе, относя победу на счет своего замечательного понимания технологии и рынка.
С другой стороны, если продукт терпит неудачу, ни у кого нет ни малейшего стимула выкапывать останки и анализировать эту неудачу. Сойдет любое оправдание, если у игроков - руководителей и разработчиков есть возможность перейти к следующей высокотехнологичной идее, коих существует неприлично много. Таким образом, нет причин убиваться из-за неудач. Неприятный побочный эффект непонимания неудач состоит в том, что молчаливо признается невозможность предсказания успеха, все считают, что удача и случай правят миром высоких технологий. Это обстоятельство, в свою очередь, работает за метод финансирования, известный среди инвесторов как
«распыли и молись». Деньги при этом вкладываются небольшими частями в многочисленные предприятия в расчете на то, что одно из них окажется успешным.
* * *
Среды быстрой разработки, такие как Всемирная паутина и Visual Basic до нее, также внесли свой вклад в развитие подхода, согласно которому повторять попытки следует до тех пор, пока одна из них не окажется успешной. Всемирная паутина, будучи новой рекламной площадкой, привлекала и привлекает массу специалистов по маркетингу, которые особенно восприимчивы к мифу о непредсказуемости рынка и, следовательно, правилу повторения попыток. Маркетологам хорошо знаком жестки и капризный мир рекламы и средств массовой информации. В конце концов, реклама во многих случаях - просто стрельба наугад. Например, в рекламе «новое» считается наиболее эффективной концепцией для продвижения продуктов на рынке, однако когда компания Coca-Cola десять лет назад представила миру новый напиток «New Coke», она

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

83 последующей реакции на положительные или отрицательные отзывы клиентов - эффективный, дешевый или даже просто действенный. В мире танцующих медведей подобная стратегия жизнеспособна в минимальной степени, а на любом рынке, проявляющем хоть малейшие признаки конкуренции, она самоубийственно глупа. Даже если на рынке больше никого нет, это весьма расточительный метод.
Многие руководители, восприимчивые и профессиональные в других отношениях, совершенно бесстыдно гордятся этим методом. Один зрелый и опытный руководящий работник (в прошлом маркетолог) однажды спросил меня в тоне самозабвенной риторики: «Как может кто-то утверждать, что знает, чего хочет пользователь?»
Поразительный вопрос. Каждый бизнесмен полагает, что знает это. Ценность большинства деловых людей как раз в их «предположениях» относительно потребностей покупателя. Да, такие предположения наверняка разойдутся с потребностями некоторых пользователей, но отсутствие предположений означает, что результат не понравится
никому. Тот глупец считал, что его клиенты согласны преодолевать последствия его новых предположений, выполняя за него работу по проектированию. Возможно, что сегодня в Кремниевой Долине нашлось бы немало путешествующих по Паутине апологетов, готовых помочь этому лентяю разобраться с его бизнесом, но при этом скольких уцелевших он отпугнул своим надменным отношением? Пока он переделывал работу, реагируя лишь на тех, у кого хватило выдержки вернуться на его веб-сайт еще раз, скольких клиентов он потерял навсегда? Чего хотели они? Говорят, Сталин расчищал минные поля, посылая на них штрафные батальоны. Эффективно такое решение? Да. Рационально, гуманно, жизнеспособно, привлекательно? Нет.
Конечно, самый серьезный недостаток метода в том, что он изначально отпугивает всех уцелевших и остаются лишь пользователи-апологеты. Это существенно искажает природу и качество отзывов, ограничивая аудиторию апологетами-технофилами, то есть очень небольшой долей рынка. Именно по этой причине очень немногие программные продукты для персональных компьютеров успешно становятся массовыми.

84
Я вовсе не хочу сказать, что нельзя учиться методом проб и ошибок, однако эти пробы должны основываться на чем-то большем, чем слепой случай, они, должны начинаться с хорошо продуманного решения, а не тяп-ляпа за один вечер. В противном случае ленивый бизнесмен всегда имеет оправдание своего некорректного обращения с клиентами.
Скрытые издержки некачественного программного обеспечения
Если программа раздражает пользователей и сложна в применении, люди станут избегать работы с ней. Не слишком примечательный факт, если не осознать, что работа многих людей связана с применением программ. Корпоративные затраты на использование таких программ невозможно измерить, однако они вполне ощутимы. Как правило, эти затраты выражаются не в деньгах, но в других более критических валютах, таких как время, уровень беспорядка, репутация и преданность клиентов.
Пользователи делового программного обеспечения могут презирать его сколько угодно, но им платят за то, чтобы они терпели эти программы. В результате изменяется восприятие людьми программ. Пользователям платят за работу с программным обеспечением, поэтому они становятся гораздо более терпеливыми к его недостаткам - ведь у них нет выбора, однако применение подобных программ не становится из-за этого дешевле. Напротив, затраты остаются высокими, а заметить и учесть их становится очень трудно.
Некачественно спроектированные бизнес-приложения вызывают у людей неприязнь к работе. Производительность страдает, в работе появляются ошибки, начинается борьба с программами, возрастает текучесть кадров. Потеря сотрудника стоит очень дорого, причем не только в финансовом выражении, но еще и в нарушении деятельности предприятия: потерянное время никогда не вернуть. Многие из тех, кто получает деньги за применение определенных инструментов, испытывают стеснение из-за того, что не

85 могут на эти инструменты жаловаться, однако это не мешает им раздражаться и быть недовольными по этому поводу.
Одна из самых затратных статей, связанных со сложными в применении программами, - это техническая поддержка. Мiсrоsоft ежегодно тратит 800 миллионов долларов на техническую поддержку. А ведь речь идет о компании, которая тратит многие сотни миллионов долларов на юзабилити-тестирование и исследования.
Очевидно компания Microsoft убеждена, что такие масштабы поддержки - неизбежное зло. Я в это не верю. Представьте, какие преимущества получит ваша компания, если вы не будете так думать. Представьте, насколько более эффективными станут ваши усилия по разработке, если вы сможете сохранить пять процентов прибыли, не оплачивая техническую поддержку.
Спросите любого, кому пришлось поработать в службе технической поддержки любой компании, создающей приложения для настольных компьютеров, и этот человек скажет, что большая часть его времени и усилий уходит на разъяснение вопросов, связанных с файловой системой. Совсем как Джейн из главы 1, пользователи не понимают рекурсивную иерархию файловой системы - будь то Finder или Explorer, система Windows, Мас или UNIX. Как ни странно, очень немногие компании тратят средства на проектирование и реализацию более дружественных к человеку альтернатив файловой системе. Все прочие выбирают гораздо более дорогой вариант бесконечной телефонной поддержки по связанным с файловой системой вопросам.
Можете винить «глупого пользователя» сколько хотите, однако вам все равно придется нанимать дорогостоящих сотрудников в службу технической поддержки, если вы собираетесь продавать и распространять программы, не спроектированные как следует.
Дороже разработки ПО обходится только разработка плохого ПО
Программисты стоят дорого, а программисты, сидящие без дела в ожидании завершения проектирования, крайне раздражают руководителей. Глупо же, думает руководитель, что программисты сидят и ждут, хотя могли бы программировать.
Заставить программистов работать до завершения этапа проектирования - ложная экономия. Когда появляется программный код, процесс уже не остановить, поэтому проектировщики вынуждены реагировать на потребности программистов, а должно быть

86 наоборот. И вправду, глупо заставлять своих программистов ждать, а ведь очень просто сделать так, чтобы они не сидели без дела - надо, чтобы проектировщики взаимодействия планировали следующий продукт или релиз параллельно с созданием текущего продукта или релиза.
В долгосрочной перспективе беспорядочное программирование обойдется: дороже, чем полное отсутствие программирования. Эта истина настолько противоречит здравому смыслу, что большинство руководителей никак ее не воспринимает. Когда код написан, очень трудно его выбросить. Подобно писателям, влюбленным в свою прозу, программисты привязываются к своим алгоритмам на эмоциональном уровне.
Модификация программы на полуслове вносит беспорядочность в процесс разработки и вредит коду. Руководителю еще труднее выбросить код, потому что он дорого заплатил за его создание и хорошо понимает, что замена обойдется еще дороже.
Если проектирование не предшествует программированию, вряд ли оно окажет какое-либо влияние. Один руководитель сказал мне: «Наши люди уже пишут код, и я не собираюсь их останавливать». Эти ковбои думают: «Пока мы будем лететь к земле, я успею сшить парашют». Отважное заявление, однако, мне не довелось видеть ему подтверждения.
Не имея результатов серьезного этапа проектирования, программисты непрерывно экспериментируют со своими программами в поисках лучших решений. Они действуют так же расточительно, как плотник, распиливающий доски «на глаз», пока не зашьет дыру в стене.
Свойства неизмеримости и неосязаемости программного обеспечения препятствуют точной оценке его масштабов и завершенности. Добавьте любовь программиста к своему ремеслу и вы поймете, что проекты неизбежно распухают в объеме и времени.
Программируя подобным образом, мы всегда будем получать сюрпризы, пока не начнем правильно устанавливать промежуточные сроки и определять, где мы находимся.
Стоимость возможностей
В эпоху информации дороже всего обходится не создание чего-либо, а потерянная возможность создать это. Создание провального продукта означает, что вы не создали успешный. Если для создания хорошего продукта потребовалось в течение трех лет выпускать по одной его версии, значит, за три года вы не создали три хороших продукта.

87
Основной бизнес компании Novell - сети, но она же пыталась открыто состязаться с
Мiсrоsоft в области офисных приложений. Попытки пробиться на этот рынок обошлись
Novell очень и очень недешево, однако самой серьезной потерей стала потеря лидерства на сетевом рынке. Деньги - ничто в сравнении с исключительной возможностью момента.
Компания Netscape утратила лидирующие позиции на рынке броузеров точно таким же образом, а именно когда решила состязаться с Мiсrоsоft в сегменте операционных систем.
Каждый разработчик продуктов, основанных на кремнии, должен оценить и изучить самые важные цели своих пользователей и стойко сосредоточиться на достижении этих целей. Слишком уж легко поддаться соблазну многочисленных возможностей в области высоких технологий и упустить главный шанс. Программисты, независимо от их интеллекта, деловой хватки, преданности и добрых намерений, прислушиваются к несколько иным мотивам и способны легко отвлечь предприятие от правильных целей.
Издержки прототипирования
Прототипирование - это то же программирование, с той же основой и затратами, однако результат не обладает эластичностью настоящего кода. Программные прототипы
- это строительные леса, они имеют мало общего с долгоживущим, расширяемым кодом, пригодным к сопровождению, эквивалентом каменных стен. Руководители, в частности, неохотно выбрасывают работающий код, даже если это прототип. Они не видят разницы между строительными лесами и каменными стенами.
Прототип можно создать гораздо быстрее, чем настоящую программу. Что и делает прототип привлекательным, ведь он кажется столь недорогим; однако, программирование дает надежную программу, тогда как создание прототипа дает лишь шаткий фундамент. Прототипы - это эксперименты, результаты которых надлежит выбрасывать, хотя в реальной жизни прототипы чаще сохраняют. Руководители смотрят на работающий прототип и спрашивают: «Почему бы нам просто не использовать это?»
Ответ технически слишком сложен и перегружен неопределенностью, чтобы переубедить руководителя, который видит перед собой возможность сэкономить многие месяцы дорогостоящих усилий.
Суть хорошего программирования в отсроченном вознаграждении. Выкладываясь в

88 начале, вы пожинаете плоды позже. Немного найдется задач, выполнение которых вручную обойдется дороже. Однако единожды написанную программу можно выполнять миллионы раз, не неся дополнительных затрат. Самая дорогая программа - та, что будет запущена только один раз. Самая дешевая - та, что будет запущена десять миллиардов раз. Если не принимать во внимание крошечные программы, типа тех, что пишутся в школьные годы, экономика программного обеспечения странным образом полностью видоизменилась: самые дешевые программы с точки зрения пользователей дороже всего в разработке, а самые дорогие для пользователя, наоборот, дешевле в разработке.
Создание большой программы можно сравнить с постройкой столба из кирпича.
Этот столб состоит из тысячи кирпичей, положенных один на другой. Столб может быть выстроен, только если класть кирпичи с большой точностью. Любое отклонение приведет к падению кирпичей. Если кирпич номер 998 отклонится на пять миллиметров, столб, вероятно, сможет выдержать тысячу кирпичей, но если отклонение в пятом кирпиче, столб никогда не станет выше трех десятков.
Это характерная особенность программного обеспечения - фундамент намного чувствительнее к манипуляциям, чем программный код более высоких уровней. В процесс е конструирования любой программы разработчик совершает ошибки и вносит изменения по ходу действий. Как следствие, программа обрастает рубцовой тканью измененного кода. В любой программе существуют рудиментарные функции и нереализованные возможности. В каждой программе существуют возможности и процедуры, потребность в которых обнаружилась через какое-то время после начала работы. Каждый из этих шрамов - маленькое отклонение на вертикали кирпичей.

89
Перенос кнопки с одной стороны диалога на другую эквивалентен подталкивание кирпича с номером 998, а изменение кода, отвечающего за отображение всех кнопок, - подталкивание пятого кирпича. Объектно-ориентированное программирование и принципы инкапсуляции данных - эта защитные методы, единственное назначение которых в том, чтобы защитить программу от образования рубцовой ткани. По сути дела, объектно-ориентированный подход разделяет башню из 1000 кирпичей на десять башен по 100 кирпичей.
Хорошие программисты тратят невероятное количество времени и сил при подготовке к созданию большой программы. Настройка среды программирования может продлиться несколько дней, прежде чем будет написана хотя бы строка кода будущего продукта. Необходимо отобрать подходящие библиотеки. Определить структуры данных. Проанализировать подсистемы хранения и поиска данных, определить их, закодировать и протестировать.
Углубляясь в работу, программисты неизбежно обнаруживают ошибки планирования и изъяны своих предположений. Они сталкиваются с гобсоновским выбором - потратить время и силы на то, чтобы исправить все, самого начала, или же решить проблему на месте, создав новый рубец в виде отклонения от плана. Давать задний ход всегда очень дорого, однако рубцовая ткань в конечном итоге ограничивает размер программы - высоту кирпичной вертикали.
При каждом изменении программы - будь то исправление ошибок или добавление функций - появляются новые рубцы. Именно поэтому программы следует выбрасывать и полностью переписывать каждые пару десятков лет. Рубцовая ткань с течением времени становится настолько толстой, что препятствует нормальной работе.
Прототипы по своей природе представляют собой программы, создаваемые в спешке и позволяющие проверить некоторые предположения. Чтобы быстро создать прототип, программист должен пожертвовать идеальным выравниванием кирпичей.
Здесь не используются «правильные» структуры данных, информация бессистемна.
Здесь не используются «правильные» алгоритмы, но используются любые подвернувшиеся фрагменты кода. Прототип начинает существование как масса рубцовой ткани. Он не может вырасти очень большим.
Некоторые разработчики пришли к прискорбному выводу, что современные инструменты для быстрого создания прототипов, такие как Visual Basic, представляют

90 собой эффективные инструменты проектирования. Вместо того чтобы заняться проектированием продукта, они наскоро создают крайне бледную версию продукта при помощи инструмента визуального программирования. Этот прототип, как правило, становится фундаментам продукта. Ради иллюзорных выгод в жертву приносится надежность продукта и продолжительность его жизни. Карандаш, лист бумаги и хорошая методология позволяют лучше спроектировать продукт, чем любое количество прототипов.
Для людей, не являющихся проектировщиками, визуализация формы еще не существующей программы затруднительна, а часто и невозможна. Дляэтих деловых людей прототипы исполняют роль инструмента визуализации. Поскольку прототип - это приближенная модель, созданная на основе существующих и доступных на момент разработки инструментов, он по определению полон временных компромиссов. Однако работающая программа, независимо от того, насколько плохо она работает, производит мощнейшее впечатление на тех, кому придется платить за ее разработку. Движущийся, пусть и хромающий, прототип обладает опасной силой, не соответствующей своей действительной ценности.
Силен соблазн руководителя сказать: «Не выбрасывайте прототип, используем его как фундамент настоящего продукта». Такое решение часто, в конечном итоге, препятствует появлению продукта на рынке.
Программисты оказываются приговоренными к постоянной реанимации программы, дающей по мере своего развития смертоносные сбои. Это башня из кирпичей, где первые 25 кирпичей положили наудачу: независимо от того, насколько точно вы кладете все последующие кирпичи, насколько тщательно работает каменщик, насколько крепко держит строительный раствор, сила гравитации неизбежно разрушит башню где-то на пятидесятом уровне.
Ценность прототипа в знаниях, приобретенных в процесс е его создания, а совсем не в коде. Мудрый разработчик Фредерик Брукс говорит: «Планируйте выбросить одну версию». Так или иначе, вы ее выбросите, так почему не запланировать это событие с самого начала?
В 1988 году я продал Биллу Гейтсу программу под названием Ruby, представлявшую собой язык визуального программирования, который в сочетании с продуктом Билла QuickBasic стал средой Visual Basic. Ruby была просто прототипом, но демонстрировала некоторые значительные новшества в подходе и технологии (при