Персонажи закрывают споры о функциях

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

Жизненно важно, чтобы каждый в команде проектировщиков не только познакомился с набором персонажей, но чтобы все персонажи стали подобны реальным людям, подобны самим участникам команды разработчики. Программистам свойствен математический подход и они естественным образом не склонны рассматривать отдельных пользователей, предпочитая обобщение. Это переходит и на их отношение к пользователям, которых они всегда представляют в общих, агрегатных или же усредненных категориях. Они предпочитают говорить «пользователь», а не «Джуди», «Крэндал», «Луис», «Эстелла», «Раджив» или «Фрэн».

До введения в обращение персонажей типичный диалог программиста и руководителя, занятых проектированием взаимодействий, выглядит примерно так:

Программист: «Что если пользователь захочет вывести это на печать?

Руководитель: «Не думаю, что печать в первой версии так уж необходима».

Программист: «Кому-то может понадобиться печать».

Руководитель: «Вероятно, да, но не могли бы мы отложить пока эту функцию? »

Руководитель не может победить в этом споре, поскольку в его аргументах нет логики. Аргумент, независимо от его правдивости, выглядит лишь аморфным желанием руководителя сделать что-то иначе, тогда как логике программиста о «возможных событиях» сопротивляться нельзя!

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

Программист: «Что если пользователь захочет вывести это на печать?»

Проектировщик взаимодействия: «Розмари печать не нужна».

Программист: «Кому-то может понадобиться печать».

Проектировщик взаимодействия: «Но мы проектируем для Розмари, а не для кого-то».

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

Но поскольку кодом владеют программисты, они могут делать и делают, что захотят, независимо от силы наших аргументов. Ключ к успеху в том, чтобы заставить программистов поверить в существование и реальность созданных персонажей. Каждый из наших проектировщиков решительно настаивает на выражении всех вопросов, связанных с проектированием, с помощью именованных персонажей. Мы никогда не возвращаемся к понятию «пользователь». Через какое-то время такая последовательность приносит плоды, программисты начинают привыкать к персонажам и называть их по именам. Когда программисты начинают называть их по именам по собственной воле, это малозаметное, но переломное событие меняет природу сотрудничества между проектировщиками и разработчиками.

Перелом наступает во всех наших успешных начинаниях, связанных с проектированием. И тогда происходит переключение на высокую передачу. Беседа звучит теперь иначе:

Просветленный программист: «Розмари захочет это напечатать?»

Довольный проектировщик взаимодействия: «Нет. А вот Джейкобу нужна печать квартальных отчетов».

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

Довольный руководитель: «Эдак мы сэкономим на разработке две недели!»

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

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