Цитаты из книги «Психбольница в руках пациентов. Алан Купер об интерфейсах»

«Семь навыков высокоэффективных инженеров». Пункты этого списка невероятно точно отражают суть, хотя и слегка преувеличены. 1. Они безгранично великодушны в своем эгоизме. 2. Чем меньше они видят, тем лучше это для них. 3. Они укусят не только руку, их кормящую, но и собственную руку. 4. Они приложат максимум усилий, чтобы поддерживать свой имидж в таком состоянии, чтобы все думали, что их это не заботит. 5. Они будут чинить и чинить то, что не сломано, пока оно окончательно не сломается. 6. «Это не я неверно ответил, это вы не так спросили». 7. Считают отсутствие критики лучшей похвалой.

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

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

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

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

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

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

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

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

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