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

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

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

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

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

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

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

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

Программистам требуется разумный и сильный лидер. Ведь они и сами такие, а потому предпочитают идти за тем, кто похож на них, а не за тем, кто уступает им в способностях. Джерри Вайнберг утверждает, что всем известна такая истина: «Легче найти плохого руководителя, чем хорошего программиста». Так программисты сразу оказываются в более выгодном положении, невзирая на то что номинально руководители находятся выше в иерархической структуре компании.

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

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

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

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

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