Классы пользователей и сторонники продукта
Коротко Сгруппируйте пользователей в классы по тому, что они делают с продуктом, решите, какие классы важнее всего, и дайте каждому важному классу сторонника продукта — реального пользователя, который говорит от имени этого класса. Именно так термин product champion понимают Вигерс и Битти; Леффингуэлл и Уидриг называют тем же английским термином другую роль — на уровне всего проекта (в русском издании их книги это «лидер продукта»).
По материалам: К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 6. Сравнение со вторым значением термина product champion — по книге: Д. Леффингуэлл, Д. Уидриг, «Принципы работы с требованиями к программному обеспечению», гл. 18.
На этой странице
Главные идеи#
От заинтересованных сторон к классам пользователей#
Среди заинтересованных сторон есть заказчики, среди заказчиков — пользователи, а пользователи делятся на классы пользователей (user classes). Один человек может входить в несколько классов: администратор работает ещё и как обычный пользователь.
Как различать классы#
Вигерс и Битти предлагают восемь измерений: права доступа или уровень безопасности; бизнес-задачи, которые выполняют люди; функции, которыми они пользуются; частота использования продукта; опыт в предметной области и в работе с компьютером; используемая платформа; родной язык; работают ли люди с системой напрямую или только получают результаты её работы.
Не классифицируйте по отрасли или географии («крупные банки», «мелкие банки»): так получаются рыночные сегменты. Классифицируйте по работе, которую выполняют люди (операционист, кредитный специалист).
Привилегированные, непривилегированные и прочие классы#
- Привилегированные классы важнее всего для достижения бизнес-целей. Их потребности побеждают в конфликтах — неважно, кто платит и у кого больше политического веса.
- Непривилегированные классы не должны иметь возможности пользоваться системой — по юридическим причинам или из соображений безопасности. Требования к ним говорят «предотвратить», а не «удовлетворить»: заблокировать учётную запись после нескольких неудачных попыток входа, не пускать автоматических сборщиков данных.
- Прочие классы обслуживаются по возможности.
Классы не обязательно состоят из людей. Программные агенты, например интеграции или боты, тоже образуют классы, иногда непривилегированные.
Расширить, затем сузить#
Вигерс и Битти рекомендуют технику Эллен Готтесдинер: накидать как можно больше кандидатов в классы, а затем объединить похожие. По их совету, в итоге должно остаться не больше 15 классов. Хорошие места для поиска — внешние сущности на контекстной диаграмме и организационная структура: подразделения, которые участвуют в процессе, затронуты им или работают с внешними сторонами. В примере из книги оргструктура фармацевтической компании указывает не только на химиков, но и на отдел охраны труда и техники безопасности, о котором никто не вспомнил.
Персоны#
Персона — вымышленное, но реалистичное описание типичного представителя класса, построенное на реальных исследованиях. Когда до реальных пользователей не добраться, вопрос «Что важнее всего для Фреда?» работает лучше, чем вопрос о безликой группе.
Сторонник продукта в понимании Вигерса и Битти#
Сторонник продукта (product champion) — самый вовлечённый представитель одного класса пользователей, который служит основным связующим звеном между этим классом и бизнес-аналитиком. В идеале это реальный пользователь, а не заместитель вроде руководителя или маркетолога, который лишь воображает себе взгляд пользователя. Ищите человека с ясным видением и увлечённостью, хорошими коммуникативными навыками, авторитетом в организации и знанием предметной области. Сторонник должен иметь полномочия принимать решения за свой класс; если руководители регулярно отменяют его решения, роль теряет смысл.
Возможные обязанности сторонника делятся на пять областей; договоритесь, какие из них относятся к каждому конкретному человеку:
- Планирование: уточнять границы и интерфейсы, оценивать влияние на бизнес-операции, помогать планировать переход.
- Требования: собирать информацию от коллег, писать сценарии или истории, разрешать конфликты внутри класса, расставлять приоритеты, задавать целевые значения качества, оценивать прототипы.
- Валидация и верификация: проверять требования, определять критерии приёмки, писать или выполнять приёмочные тесты, участвовать в бета-тестировании.
- Материалы для пользователей: участвовать в подготовке документации и обучения, демонстрировать продукт коллегам.
- Управление изменениями: оценивать запросы на изменения и помогать корректировать будущие релизы.
Для большого или неоднородного класса один сторонник может собрать небольшую группу поддержки из представителей разных подгрупп. В примере из книги сторонник примерно тысячи химиков работал с пятью химиками из разных отделов.
Для коммерческих продуктов без прямого доступа к пользователям авторы описывают четыре варианта: пригласить представителей крупных клиентов, нанять эксперта в предметной области на полный рабочий день, нанять бывших сотрудников клиентов или отправить аналитиков поработать на площадках клиентов. В любом случае проверьте, что взгляд человека актуален и типичен.
Авторы также ссылаются на Кейла и Кармела (Keil, Carmel): проекты, где между пользователями и разработчиками больше прямых связей, как правило, успешнее, потому что каждый посредник искажает сообщение. Разумное исключение — квалифицированный бизнес-аналитик.
Не путать с лидером продукта у Леффингуэлла и Уидрига#
| Вигерс и Битти | Леффингуэлл и Уидриг | |
|---|---|---|
| Сколько | По одному на класс пользователей | Один на проект (или небольшая группа) |
| Кто | Реальный пользователь из этого класса | Часто менеджер продукта, менеджер по маркетингу или руководитель проекта |
| От чьего имени говорит | Потребности одного класса | Видение продукта в целом |
| Главная задача | Поставлять и проверять требования своего класса | Отвечать за видение, разрешать конфликты, согласовывать границы, говорить «нет» |
Второе значение описано на странице Роль лидера продукта.
Как применять#
- Накидайте кандидатов в классы по контекстной диаграмме и организационной структуре.
- Сведите их в обозримый список и отметьте каждый класс как привилегированный, непривилегированный или прочий.
- Для каждого привилегированного класса назначьте сторонника и письменно договоритесь, какие обязанности он берёт и что может решать.
- Если реальный пользователь недоступен, напишите персону на основе исследований.
- Прежде чем считать выявление завершённым, убедитесь, что каждый класс был услышан.
Пример#
«Мастерская», вымышленная сеть веломастерских:
| Класс пользователей | Статус | Чей голос звучит |
|---|---|---|
| Клиенты, записывающиеся онлайн | Привилегированный | Персоны и короткий опрос; ни один сторонник не может говорить за всех клиентов |
| Сотрудники стойки приёма | Привилегированный | Сторонник: опытный старший администратор |
| Механики | Привилегированный | Сторонник: старший механик с группой поддержки из трёх механиков из разных мастерских |
| Управляющие мастерских | Прочий | Интервью |
| Владелец (только читает отчёты) | Прочий, косвенный пользователь | Интервью |
| Система заказов поставщика запчастей | Прочий, не человек | Спецификация интерфейса |
| Боты, которые массово бронируют свободное время | Непривилегированный | Требования, которые не дают массово бронировать время |
Источники и что почитать#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 6.
- D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. Гл. 18 (для сравнения).