- •Алан Купер Психбольница в руках пациентов
- •Содержание
- •Часть I. Компьютерная безграмотность 27
- •Глава 1. Загадки века информации 27
- •Глава 2. Когнитивное сопротивление 44
- •Часть II. Масштабные издержки 68
- •Глава 3. Пустая трата денег 68
- •Глава 4. Танцующий медведь 89
- •Об авторе
- •Благодарности
- •Предисловие научного редактора
- •Предисловие
- •Введение Книга-обоснование
- •Инженер, сведущий в бизнесе, либо бизнесмен, сведущий в технологии
- •ЧастьI. Компьютерная безграмотность Глава 1. Загадки века информации Что получится, если скрестить компьютер с самолетом?
- •Что получится, если скрестить компьютер с фотокамерой?
- •Что получится, если скрестить компьютер с будильником?
- •Что получится, если скрестить компьютер с автомобилем?
- •Что получится, если скрестить компьютер с банком?
- •Компьютер позволяет легко попасть в беду
- •Коммерческое программное обеспечение тоже страдает
- •Что получится, если скрестить компьютер с военным кораблем?
- •Техноярость
- •Индустрия в «несознанке»
- •Мотивы создания этой книги
- •Глава 2. Когнитивное сопротивление
- •Поведение, не связанное с физическими силами
- •Проектирование1- слово емкое
- •Отношения между программистами и проектировщиками
- •Большинство программ проектируются случайным образом
- •Проектирование «взаимодействия» против проектирования «интерфейса»
- •Отличительные черты продуктов, основанных на программном обеспечении
- •Танцующий медведь
- •Стоимость дополнительных возможностей программного обеспечения
- •Апологеты и уцелевшие
- •Наша реакция на когнитивное сопротивление
- •Демократизация власти потребителя
- •Виноват пользователь
- •Программный апартеид
- •ЧастьIi. Масштабные издержки Глава 3. Пустая трата денег
- •Управление, ориентированное на крайние сроки сдачи
- •Что такое «готово»?
- •Закон Паркинсона
- •Продукт, вечно не готовый к выпуску
- •Поздний выпуск - не беда
- •Торг за набор функций
- •Кто главный? Программисты
- •Возможности не всегда нужны
- •Итерации и миф о непредсказуемости рынка
- •Скрытые издержки некачественного программного обеспечения
- •Дороже разработки по обходится только разработка плохого по
- •Стоимость возможностей
- •Издержки прототипирования
- •Глава 4. Танцующий медведь
- •Если это проблема, то почему ее до сих пор не решили?
- •Жертва бытовой электроники
- •Чем плохи почтовые клиенты
- •Чем плохи программы для планирования
- •Чем плохи календари
- •Массовая веб-истерия
- •Что не так с программным обеспечением?
- •Программы забывают
- •Программы ленивы
- •Программы скупы на информацию
- •Программы не гибки
- •Программы возлагают вину на пользователей
- •Программы не несут ответственности
- •Глава 5. Нелояльность клиентов
- •Привлекательность
- •Одно сравнение
- •Время выхода на рынок
- •ЧастьIii. Как есть суп вилкой Глава 6. Психбольница в руках пациентов
- •Вождение на заднем сиденье
- •Подготовка катастрофы
- •Компьютеры против людей
- •Учим собак быть кошками
- •Глава 7. НоmoLogicus
- •Авиационный тест
- •Психология программистов
- •Программисты пожертвуют простотой ради контроля
- •Программисты обменяют успех на понимание
- •Программисты сосредотачиваются на исключительных ситуациях
- •Программисты ведут себя грубо и прямолинейно
- •Глава 8. Отмирающая культура
- •Культура программирования
- •Повторное использование кода
- •Общепринятая культура
- •Культура программирования в Мicrоsоft
- •Культурная изоляция
- •Шкурный интерес
- •Дефицитный образ мыслей
- •Обесчеловечивает процесс, а не технология
Большинство программ проектируются случайным образом
Глиняные лачуги и подземные норы проектируются, пусть зачастую неосознанно, в рамках возможностей камня и тростника. Аналогичным образом все программы проектируются в рамках таинственных потребностей языков программирования и баз данных. Самое сильное влияние на проектирование во всех перечисленных материалах оказывает традиция. Разница, и большая, в том, что строитель, проектирующий лачугу, также является и ее основным жильцом, тогда как программисты обычно не используют спроектированные ими приложения.
В большинстве фирм, занимающихся разработкой программного обеспечения, просто нет людей, имеющих представление о проектировании для конечного пользователя. Но есть люди, имеющие более чем серьезное представление о проектировании программ, имеющие свое собственное мнение и личные предпочтения. И потому они делают то, что делают, - проектируют взаимодействие с программой, как для самих себя, выбирая функциональность, которую проще всего и интереснее всего реализовывать, и при этом воображают, что на самом деле проектируют для пользователей. И хотя программисту кажется, что объем выполняемого проектирования очень велик, на деле много всего лишь проектирования программного, а проектирование для конечного пользователя почти отсутствует.
Недостаточное проектирование - тоже вид проектирования, поэтому когда кто-либо принимает решения о поведении программы, он принимает на себя роль проектировщика взаимодействия. Когда маркетолог настаивает на включении привлекательной функции в продукт, он проектирует. Когда программист реализует в продукте излюбленный способ поведения, он проектирует.
Разница между проектированием хорошим и непроизвольным - в стиле глиняных домиков - не в применяемых инструментах и приспособлениях, но в мотивации. Настоящий проектировщик взаимодействия принимает решения, исходя из задач пользователя. Эрзац- проектировщики принимают решения, исходя из произвольного числа случайных соображений. Личные предпочтения, знакомство с предметом, страх перед неизвестностью, указания от Microsoft, ошибочные замечания коллег - все эти факторы играют на удивление серьезную роль. Впрочем, чаще всего решения эрзац - проектировщиков склоняются в сторону пути наименьшего сопротивления.
Проектирование «взаимодействия» против проектирования «интерфейса»
Я предпочитаю термин «проектирование взаимодействия» термину «проектирование интерфейса», поскольку слово «интерфейс» предполагает, что код находится в одном месте, люди в другом, а интерфейс между ними позволяет обмениваться сообщениями. Подразумевается, что именно интерфейс несет ответственность за потребности пользователей. Последствия изоляции проектирования на уровне интерфейса таковы - программисты начинают делать выводы примерно такого характера: «Я могу писать, как мне угодно, потому что «интерфейс» появится уже после того, как я закончу». Проектирование откладывается до завершения программирования, когда уже слишком поздно.
Дизайн интерфейса позволяет придать определенный вид уже существующему поведению системы, так и гунна Аттилу можно одеть в костюм от Армани. Например, в генераторе отчетов дизайн интерфейса устранит ненужные границы и прочие визуальные помехи из таблицы с цифрами, выделит цветом важные поля, обеспечит качественный отклик на действия пользователя и т. д. Это лучше, чем ничего, но далеко не достаточно. Microsoft вкладывает многие миллионы долларов в проектирование интерфейсов, но продукты этой компании так и не снискали любви пользователей.
«Поведенческое проектирование» указывает, как элементы программы должны действовать и передавать информацию. Продолжая пример, можно сказать, что проектирование поведения указывает, какие инструменты можно применять к таблице отчета, как включать в отчет средние или итоговые показатели. Проектировщики взаимодействия также работают от общего к частному, начиная с целей, которых пытается достичь пользователь, но, не забывая о более широких потребностях бизнеса, ограничениях технологии и подчиненных задачах.
Можно углубиться еще далее, в область, которую мы называем «концептуальным проектированием». Концептуальное проектирование рассматривает вещи с точки зрения их возможной ценности для пользователей. В нашем примере концептуальное, проектирование может выявить, что изучение таблицы с данными - второстепенная задача, а реальная цель пользователя - в том, чтобы отследить тенденции. Отсюда следует, что надо создавать вовсе не генератор отчетов, а анализатор тенденций. Чтобы обеспечить пользователей ощущением могущества и удовлетворения, необходимо сначала думать концептуально, затем в терминах поведения и лишь в последнюю очередь - в терминах интерфейса.