С персонами споров о функциях больше нет

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

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

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

Программист: «А что если пользователю понадобится распечатать это?»

Руководитель: «Думаю, что в опции печати для первой версии программы большой необходимости нет».

Программист: «Но кому-то может потребоваться возможность распечатки».

Руководитель: «Может, и так. Но мы ведь можем пока отложить добавление этой функции?»

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

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

Программист: «А что если пользователю понадобится распечатать это?»

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

Программист: «Но кому-то может потребоваться возможность распечатки».

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

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

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

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

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

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

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

Счастливый руководитель: «Получается, что за счет этого мы сэкономим на разработке целых две недели!»

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

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