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

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

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

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

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

Проектировочные документы приносят пользу программистам

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

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

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

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

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

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