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

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

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

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

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

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

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

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

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

Дружественный процесс проектирования

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

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

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

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