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

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

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

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

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

На мой взгляд, существует два типа руководителей: инженеры и запуганные инженерами. Первые множат знакомые проблемы, поскольку их точка зрения безнадежно испорчена конфликтом интересов. Вторые множат проблемы, поскольку не умеют говорить на языке программистов. И я не имею в виду языки Java и С#. Я имею в виду, что у деловых людей и программистов нет общих инструментов и общих целей. Человек разумный делегирует человеческие проблемы хомо логикус, не осознавая, что решение могло бы оказаться намного более приятным в случае применения – на исполнительном уровне – уместных финансовых и организационных моделей.

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

Алан Купер,

Пало, Альто, Калифорния

www.cooper.com

[email protected]

Часть I

Компьютерная безграмотность

Глава 1

Загадки века информации

Что получится, если скрестить компьютер с самолетом?

В декабре 1995 года рейс 965 компании American Airlines вылетел по регулярному маршруту из Майами в Кали, Колумбия. На подлете к посадочной полосе пилоту Боинга-757 потребовалось выбрать следующий радиомаяк по имени «ROZO». Он набрал букву «R» в своем навигационном компьютере. Компьютер отобразил перечень ближайших радиомаяков с именами на «R», а пилот выбрал первую позицию в списке, потому что широта и долгота показались ему верными. К несчастью, вместо «ROZO» пилот выбрал маяк «ROMEO», расположенный в 210 километрах к северо-востоку. Самолет направлялся на юг и находился в тот момент в долине, пролегающей с юга на север, так что любое отклонение от курса было опасно. Следуя показаниям полетного компьютера, пилоты начали корректировать курс к востоку, и самолет врезался в гранитный пик на высоте трех километров. Сто пятьдесят два пассажира и восемь членов экипажа погибли. Четыре пассажира выжили, получив серьезные травмы. Национальная комиссия по безопасности транспорта провела расследование и – как обычно – заявила, что причиной явился человеческий фактор. Вспомогательное навигационное средство, показаниями которого руководствовались пилоты, выдало корректную информацию, но не для посадки в Кали. Человеческий фактор, если следовать буквальному смыслу фразы, действительно был причиной — ведь именно пилот выбрал неправильный маяк. Однако если взглянуть на ситуацию в целом, вины пилота здесь не было.

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

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

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

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

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

Что получится, если скрестить компьютер с фотокамерой?

Вот загадка информационного века: что получится, если скрестить компьютер с фотокамерой? Ответ: компьютер! Тридцать лет назад в моем первом фотоаппарате, 35-миллиметровом Pentax H, была маленькая батарейка, питавшая экспонометр. Я просто менял батарейку каждые два года, как в наручных часах.

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