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

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

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

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

Проектировочные документы помогают в разработке документации и технической поддержке

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

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

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

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

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

«Выгоды от услуг проектирования измеряются сэкономленными месяцами напряженной работы».

Проектировочные документы выгодны компании в целом

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

Более того, точно осознавая, что вы делаете, вы избежите траты сил на то, чего вы точно не собираетесь делать. Ни одна компания не может себе позволить тратить силы на вещи, не относящиеся к делу.

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

Кто отвечает за качество продукта?

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

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

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

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

Включение проектирования в процесс

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

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