«Аналитик и» пользователь

В новом сезоне сериала “Аналитик и…” рады представить вам новых героев. Один из них — пользователь. Пользователь — это серый кардинал проекта, этакий незаметный ниндзя, который остается в тени на протяжении всего проекта, а потом делает больно на этапе приемки словами “Это не то, с чем мы хотим работать”.. К нему очень сложно подобраться, не ранив чувств менеджмента заказчика и владельца продукта. Счастливым аналитикам достаются проекты, где конечный пользователь выступает также в роли владельца продукта, а то еще и спонсора проекта. Чаще же это разные люди, что порождает дополнительные испытания и делает приключения аналитика более зрелищными, поднимая рейтинги… в общем, сложность есть, и с ней надо справляться.

Какие бывают пользователи?

Пользователей можно классифицировать несколькими способами:

- по типу восприятия (аудиалы, визуалы, кинестетики, дигиталы)

- по отношению к проекту (лояльные, нейтральные, с негативным отношением)

- по уровню влияния

- по частоте работы с системой

- по соответствию цели проекта (целевые, нецелевые)

- по принадлежности к организации (внешние, внутренние)

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

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

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

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

Нужно тратить много усилий, чтобы завоевать внешних пользователей (например, покупателей интернет-магазина, который вы разрабатываете для заказчика). При этом на аутсорсинговом проекте в задачи аналитика часто не входит работа с таким типом пользователей. А вот со внутренними мы работаем довольно плотно и стараемся не принуждать их к использованию нового продукта либо принятию других изменений — важно сохранить их лояльность.

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

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

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

В компании, помимо разработчиков, есть также и люди, которые отвечают за продвижение продукта.

Эти люди общаются с теми, кто еще не знаком с системой, и поэтому видение пользовательской аудитории искажатеся:

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

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

Вернемся к нашим.. пользователям.

Чего ожидает пользователь от аналитика?

- Аналитик оставит в покое либо не будет грузить лишней работой.

- Аналитик правильно поймет все, что имеет ввиду пользователь.

- Аналитик всегда будет на стороне пользователя и при необходимости будет отстаивать интересы того перед руководством.

- Аналитик будет говорить на языке пользователя.

- Аналитик будет понимать предметную область пользователя.

- Аналитик согласится вносить изменения в требования в любой момент.

- Аналитик предложит решение для высказанных пользователем проблем.

- Аналитик проявит уважение к пользователю.

Хотя некоторые из этих ожиданий следует оправдывать (говорить на языке пользователя, понимать предметную область, предлагать решение), необходимо понимать и риски, связанные с этими ожиданиями. Аналитик должен быть непредвзятым по отношению к любым заинтересованным лицам. Все разногласия должны решаться в соотвествии с установленными правилами на проекте. Желание потакать любым прихотям пользователя может привести к неконтролируемому разрастанию границ проекта. Но в то же время нужно дать понять пользователю, как его запросы могут быть реализованы.

Чего ожидает аналитик от пользователей?

- Пользователь точно и доходчиво объяснит свои цели и требования.

- Пользователь легко определит критерии успешности для целей.

- Пользователь поможет разобраться с предметной областью и ответит на все вопросы.

- Пользователь уделит столько времени аналитику, сколько необходимо.

- Пользователь поймет все ограничения, связанные с реализацией его требований, и согласится с ними.

- Пользователь легко сможет приоритезировать свои требования.

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

- Пользователь проявит уважение к аналитику.

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

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

Статьи по теме:
0. «Аналитик и..»
1. «Аналитик и» Проектный Менеджер
2. «Аналитик и» Эксперт в предметной области
3. «Аналитик и» Cпонсор проекта