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

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

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

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

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

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

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

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

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

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

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

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