Психбольница в руках пациентов

Купер Алан

Одна из самых затратных статей, связанных со сложными в применении программами, – это техническая поддержка. Мiсrоsоft ежегодно тратит 800 миллионов долларов на техническую поддержку. А ведь речь идет о компании, которая тратит многие сотни миллионов долларов на юзабилити-тестирование и исследования. Очевидно компания Microsoft убеждена, что такие масштабы поддержки – неизбежное зло. Я в это не верю. Представьте, какие преимущества получит ваша компания, если вы не будете так думать. Представьте, насколько более эффективными станут ваши усилия по разработке, если вы сможете сохранить пять процентов прибыли, не оплачивая техническую поддержку.

Спросите любого,

кому пришлось поработать в службе технической поддержки любой компании, создающей приложения для настольных компьютеров, и этот человек скажет, что большая часть его времени и усилий уходит на разъяснение вопросов, связанных с файловой системой. Совсем как Джейн из главы 1, пользователи не понимают рекурсивную иерархию файловой системы – будь то Finder или Explorer, система Windows, Мас или UNIX. Как ни странно, очень немногие компании тратят средства на проектирование и реализацию более дружественных к человеку альтернатив файловой системе. Все прочие выбирают гораздо более дорогой вариант бесконечной телефонной поддержки по связанным с файловой системой вопросам.

Можете винить «глупого пользователя» сколько хотите, однако вам все равно придется нанимать дорогостоящих сотрудников в службу технической поддержки, если вы собираетесь продавать и распространять программы, не спроектированные как следует.

Дороже разработки ПО обходится только разработка плохого ПО

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

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

Если проектирование не предшествует программированию, вряд ли оно окажет какое-либо влияние. Один руководитель сказал мне: «Наши люди уже пишут код, и я не собираюсь их останавливать». Эти ковбои думают: «Пока мы будем лететь к земле, я успею сшить парашют». Отважное заявление, однако, мне не довелось видеть ему подтверждения.

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

Свойства неизмеримости и неосязаемости программного обеспечения препятствуют точной оценке его масштабов и завершенности. Добавьте любовь программиста к своему ремеслу и вы

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

Стоимость возможностей

В эпоху информации дороже всего обходится не создание чего-либо, а потерянная возможность создать это. Создание провального продукта означает, что вы не создали успешный. Если для создания хорошего продукта потребовалось в течение трех лет выпускать по одной его версии, значит, за три года вы не создали три хороших продукта. Основной бизнес компании Novell – сети, но она же пыталась открыто состязаться с Мiсrоsоft в области офисных приложений. Попытки пробиться на этот рынок обошлись Novell очень и очень недешево, однако самой серьезной потерей стала потеря лидерства на сетевом рынке. Деньги – ничто в сравнении с исключительной возможностью момента.

Компания Netscape утратила лидирующие позиции на рынке броузеров точно таким же образом, а именно когда решила состязаться с Мiсrоsоft в сегменте операционных систем.

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

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

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

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

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