Целеориентированное проектирование

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

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

А теперь представим себе Клэнси – разработчика программного обеспечения, который должен написать программу для Дженнифер. Со стороны Клэнси и присущего ему образа мышления Хомо логикус, ПО для Дженнифер выполняет три задачи – три основные функции, каждая из которых выполняется в отдельном программном модуле. Для Клэнси кажется вполне естественным, что у каждой из этих функций также будет свой раздел в интерфейсе. Такой подход кажется ему логичным. Клэнси задумывает интерфейс, в котором левая боковая панель будет содержать иерархический список компонентов системы, а правая часть экрана будет отображать детали о каждом компоненте, как только он будет выбран из списка. Именно такая форма интерфейса принята в Microsoft, а потому программистам она кажется вполне разумной. Конечно, в таком случае пользователь будет вынужден пройтись по множеству компонентов системы, чтобы выяснить, где кроется проблема, однако вся нужная информация уже присутствует в программе и доступна по запросу.

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

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

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

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

Целеориентированный выпуск новостей

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

В бизнесе новостей может случиться всякое, так что ведущим нужна позиция для отступления. Их целью является всегда иметь приемлемую передачу, пригодную для вывода в эфир. Выпуск вечерних новостей создается утром и представляет собой полноценную, готовую к передаче в эфир запись. Ее продолжительность составляет 22 минуты (без учета рекламы), и она всегда готова к показу. Под каждый новостной фрагмент отведено определенное время, а все фрагменты в сумме всегда составляют 22 минуты. Это похоже на то, как изображение с нечетким фокусом медленно обретает резкость: границы телепередачи всегда фиксированы, а контент постепенно уточняется и обрастает подробностями. Передача готова к выпуску уже с десяти утра, ее можно поставить в эфир в любой момент, если потребуется, однако своей наилучшей формы она достигнет приблизительно к пяти часам вечера.

Каждый выпуск новостей включает от 20 до 30 сюжетов, составленных из комментариев, видео, репортажей и интервью в студии. В ходе текущего дня приоритеты сюжетов сдвигаются, равно как сдвигается время выхода каждого и отведенное под него время, – все это делается на усмотрение директора службы новостей. К началу второй половины дня все внимание может привлечь к себе сенсационная новость, из-за чего другие новости придется сдвинуть или вовсе исключить из выпуска. Репортеры и директор службы новостей будут вносить коррективы и изменения в сценарий вплоть до самой последней секунды – иногда даже прямо во время эфира.

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

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