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

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

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

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

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

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

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

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

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

каким образом продукт облегчит жизнь пользователям.

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

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