Кажется, только ленивый не сделал обзор на книгу Алана Купера «Психбольница в руках пациентов» теперь и моя очередь.
Эта книга сейчас гораздо менее популярна, чем 5-10 лет назад. Понятно, что с момента ее выхода в 2004 году и некоторые представления о пользователях, и примеры интерфейсов устарели. Большинство уже не помнят окошек Windows’95. Тем более удивительно, что не теряют актуальности сами идеи о различиях между проектированием ради функциональности и проектированием для людей. Это книга о разнице подходов в проектировании продуктов с точки зрения проектировщика-дизайнера и проектировщика-программиста. Рассуждение о том, что продукты оказались перегружены функциями не нужными их пользователям и почему так получается.
Далеко не все хорошо оценивают эту книгу. Наверное потому, что автор высказывается провокационно и много рассуждает о точке зрения программистов на проектирование продукта. Достаточно взглянуть на оглавление с названиями разделов «Программисты пожертвуют простотой ради контроля», «Программисты сосредотачиваются на исключительных ситуациях» или «Программисты ведут себя прямолинейно».
📍Что получится, если скрестить компьютер с фотокамерой? Имеется в виду, что перегруженная функциями система перестает напрямую выполнять свои задачи, а превращается во что-то сложное. Будильник с кучей настроек для некоторых пользователей выглядит как компьютер, а не как удобный будильник. Может получиться, что не пользователь управляет будильником, а будильник пользователем...
От себя дополню. В работе аналитика это может проявляться, например, в виде запроса пользователя ”сделайте выгрузку этого в Excel”. Причины запроса могут быть разными и одна из вероятных — работа с записями в системе перегружена непонятными пользователю приемами управления данными, а он хочет сам управлять записями понятным ему способом. Нужно не только обучить пользователя, но и поискать функции, которые для него избыточны.
📍В книге есть задачка для подтверждения тезиса, что не все свойства продукта можно описать перечислением его функций без описания целей пользователя. Какой продукт можно представить по перечислению его функций? В продукте имеются:
• двигатель внутреннего сгорания,
• четыре колеса с резиновыми покрышками,
• трансмиссия, связывающая двигатель с ведущими колесами,
• трансмиссия и двигатель смонтированы на ходовой части,
• рулевое колесо.
Можно решить, что этот продукт — автомобиль, но при этом задачи продукта:
• быстро и легко срезает траву
• на этом удобно сидеть.
Получается минитрактор-газонокосилка.
Я вспоминаю этот пример, когда думаю о документировании требований к функциональности. Не каждому разработчику понравится, если описание задачи перегружено описанием контекста. Разработчику удобнее видеть четкий перечень «что нужно сделать». Зато при изменении требований через пару месяцев, когда уже забыто зачем внедрялось изменение, вы сами будете рады найти информацию о целях и задачах заинтересованных сторон. Эта информация может помочь при тестировании запланировать тесты соответственно контексту. Поэтому при документировании приходится балансировать между описанием функций и задач.
