
- •Алан Купер Психбольница в руках пациентов
- •Содержание
- •Часть 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
- •Культурная изоляция
- •Шкурный интерес
- •Дефицитный образ мыслей
- •Обесчеловечивает процесс, а не технология
Кто главный? Программисты
Несмотря на внешние признаки, программисты полностью контролируют этот процесс принятия решений снизу вверх. Именно они определяют, сколько времени займет реализация каждой возможности, и поэтому могут перемещать требования в конец списка, просто посчитав их трудоемкими. Программисты, из соображений самозащиты, назначают нечетко определенным позициям большую трудоемкость, причем, как правило, речь идет о существенных вопросах взаимодействия с пользователем. Это неизбежно перемещает вопросы пользовательского интерфейса в конец списка. Наверх же всплывают более привычные идиомы - простые в создании меню, мастеры, диалоги. Анализ и скрупулезные размышления, проведенные обладающими властью и высокими зарплатами исполнительными лицами, в одностороннем порядке превращаются в спорные идеи программистом, имеющим собственные соображения или защищающим собственную территорию.
Руководители попадают в незавидное положение и могут влиять лишь на незначимые параметры процесса разработки, словно пытаясь увеличить громкость колонок, в любом случае находящихся вне зоны слышимости. Нет сомнения, что руководству необходимо контролировать процесс создания и выпуска успешных программных продуктов, но, к сожалению, наш культ фиксированных сроков сдачи полностью игнорирует критерии «успешности», сосредотачиваясь на факте «создания». Мы вручаем создателям продукта бразды правления, переводя таким образом руководителей на роль пассажиров и наблюдателей.
Возможности не всегда нужны
Несмотря на кажущееся пристрастие к функциональности, пользователи не слишком стремятся получить максимум возможностей. Успехи и неудачи продуктов неоднократно демонстрировали, что пользователей не очень волнуют функции продуктов. Они интересуются лишь возможностью решать задачи. Иногда функции необходимы для этого, но чаще они просто смущают пользователей и мешают им делать работу. Бесполезные возможности заставляют пользователей чувствовать себя глупо. Если обратиться к предыдущему примеру, успешный PalmPilot обладал гораздо меньшим количеством функций, чем провалившиеся Magic Link от General Magic, Newtown от Apple и компьютер Penpoint. Своим успехом PalmPilot обязан проектировщикам, единодушно сосредоточившимся на целевой аудитории и ее потребностях.
Что я могу сказать хорошего о функциях? Они поддаются измерению. И это свойство измеримости придает им ауру ценности, которой в действительности они не обладают. Отрицательные качества функций полностью съедают все их положительные качества. Функции - причина одной из серьезных проблем проектирования, потому что каждая возможность, предложенная из лучших побуждений и потенциально полезная, оттеняет некоторые возможности, которые, вероятно, будут действительно полезны. Разумеется, реализация возможностей не бесплатна. Каждая из них усложняет продукт. Они требуют увеличения размера и сложности документации и системы контекстной справки. Что еще важнее, с точки зрения затрат они требуют раздувания штата технической поддержки, занятого в консультировании пользователей относительно этих самых возможностей.
Для нашего зациклившегося на функциях мира мысль, наверное, непривычная - вы не достигнете своих целей, используя набор функций как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. Для доказательства этого тезиса проектировщик взаимодействий Скотт Мак-Грегор на своих занятиях использует вот такой замечательный тест. Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет: 1) двигатель внутреннего сгорания; 2) четыре колеса с резиновыми покрышками; 3) трансмиссия, связывающая двигатель с ведущими колесами; 4) трансмиссия и Двигатель смонтированы на ходовой части; 5) рулевое колесо. На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя: 6) быстро и легко срезает траву; 7) на этом удобно сидеть. На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.