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

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

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

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

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

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

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

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

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