Алан Купер - Психбольница в руках пациентов

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

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

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

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

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

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

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

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

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

Программистам нужен сильный и умный лидер. В конце концов, они сильные и умные, они предпочитают, очевидно, чтобы их возглавляли равные по рангу, а не нижестоящие. Как утверждает Джерри Вайнберг (Jerry Weinberg), всем известно, что «плохих руководителей найти проще, чем хороших программистов». Это ставит хорошего программиста более выгодное положение, несмотря на номинальный авторитет руководителя в корпоративной иерархии.

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

Я работал с программистами, которые испытывали неприязнь к выполнявшей проектирование сторонней компании. Они знали, что моя работа заключается в «проектировании» и что это самая творческая и самая интересная часть их работы. Однако поработав с нами, они поняли, что мы не только не отнимаем у них работу, но и делаем ее более качественной.

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

Под конец, когда собравшиеся стали разбредаться, нашей команде удалось поговорить с Фредом наедине. Мы объяснили ему, что наша задача сделать программу проще и мощнее с точки зрения конечного пользователя, и что мы полностью осознаем: наши решения требуют серьезных дополнительных размышлений на уровне программирования. Мы настаивали, что нас интересует только конечный пользователь. Внезапно на лицо Фреда нашло выражение потрясения. Он воскликнул: «Вы бросаете мне серьезный технологический вызов!» Его отношение полностью изменилось, как только он осознал, что мы принесли ему грааль всех программистов – сложную проблему, достойную решения.