Программисты занимаются проектированием, ориентированным на задачи

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

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

Проектирование, ориентированное на цели

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

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

А теперь обратимся к Клэнси, разработчику программного обеспечения, перед которым стоит задача создать программу для Дженнифер. В присущем Клэнси представлении хомо логикус программа решает три задачи (имеет три функции) - под каждую задачу будет отведен отдельный программный модуль. Клэнси кажется естественным, что для каждой из функций отведен собственный участок интерфейса. Ведь это логично. Клэнси думает об интерфейсе, содержащем иерархический список системных компонентов в левой части, а в правой части - информацию о выбранном элементе иерархического списка. Такой интерфейс обладает одним преимуществом - он утвержден компанией Microsoft, а потому кажется программистам разумным. Пользователю придется прощелкать множество системных компонентов, чтобы понять, что происходит с системой, однако вся нужная информация ему доступна только по специальному запросу.

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

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

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

Проектирование для удовлетворения целей персонажа пользователя ясно показывает альтернативный подход к предоставлению функциональности. Часто такой подход дает качественно лучшие способы решения прозаических проблем проектирования. Вот некоторые примеры.