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

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

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

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

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

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

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

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

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

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

Кто отвечает за качество?

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

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

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

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