Инженерия требований

Классы пользователей и сторонники продукта

Коротко Сгруппируйте пользователей в классы по тому, что они делают с продуктом, решите, какие классы важнее всего, и дайте каждому важному классу сторонника продукта — реального пользователя, который говорит от имени этого класса. Именно так термин product champion понимают Вигерс и Битти; Леффингуэлл и Уидриг называют тем же английским термином другую роль — на уровне всего проекта (в русском издании их книги это «лидер продукта»).

По материалам: К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 6. Сравнение со вторым значением термина product champion — по книге: Д. Леффингуэлл, Д. Уидриг, «Принципы работы с требованиями к программному обеспечению», гл. 18.

На этой странице

Главные идеи#

От заинтересованных сторон к классам пользователей#

Среди заинтересованных сторон есть заказчики, среди заказчиков — пользователи, а пользователи делятся на классы пользователей (user classes). Один человек может входить в несколько классов: администратор работает ещё и как обычный пользователь.

Как различать классы#

Вигерс и Битти предлагают восемь измерений: права доступа или уровень безопасности; бизнес-задачи, которые выполняют люди; функции, которыми они пользуются; частота использования продукта; опыт в предметной области и в работе с компьютером; используемая платформа; родной язык; работают ли люди с системой напрямую или только получают результаты её работы.

Не классифицируйте по отрасли или географии («крупные банки», «мелкие банки»): так получаются рыночные сегменты. Классифицируйте по работе, которую выполняют люди (операционист, кредитный специалист).

Привилегированные, непривилегированные и прочие классы#

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

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

Расширить, затем сузить#

Вигерс и Битти рекомендуют технику Эллен Готтесдинер: накидать как можно больше кандидатов в классы, а затем объединить похожие. По их совету, в итоге должно остаться не больше 15 классов. Хорошие места для поиска — внешние сущности на контекстной диаграмме и организационная структура: подразделения, которые участвуют в процессе, затронуты им или работают с внешними сторонами. В примере из книги оргструктура фармацевтической компании указывает не только на химиков, но и на отдел охраны труда и техники безопасности, о котором никто не вспомнил.

Персоны#

Персона — вымышленное, но реалистичное описание типичного представителя класса, построенное на реальных исследованиях. Когда до реальных пользователей не добраться, вопрос «Что важнее всего для Фреда?» работает лучше, чем вопрос о безликой группе.

Сторонник продукта в понимании Вигерса и Битти#

Сторонник продукта (product champion) — самый вовлечённый представитель одного класса пользователей, который служит основным связующим звеном между этим классом и бизнес-аналитиком. В идеале это реальный пользователь, а не заместитель вроде руководителя или маркетолога, который лишь воображает себе взгляд пользователя. Ищите человека с ясным видением и увлечённостью, хорошими коммуникативными навыками, авторитетом в организации и знанием предметной области. Сторонник должен иметь полномочия принимать решения за свой класс; если руководители регулярно отменяют его решения, роль теряет смысл.

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

  • Планирование: уточнять границы и интерфейсы, оценивать влияние на бизнес-операции, помогать планировать переход.
  • Требования: собирать информацию от коллег, писать сценарии или истории, разрешать конфликты внутри класса, расставлять приоритеты, задавать целевые значения качества, оценивать прототипы.
  • Валидация и верификация: проверять требования, определять критерии приёмки, писать или выполнять приёмочные тесты, участвовать в бета-тестировании.
  • Материалы для пользователей: участвовать в подготовке документации и обучения, демонстрировать продукт коллегам.
  • Управление изменениями: оценивать запросы на изменения и помогать корректировать будущие релизы.

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

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

Авторы также ссылаются на Кейла и Кармела (Keil, Carmel): проекты, где между пользователями и разработчиками больше прямых связей, как правило, успешнее, потому что каждый посредник искажает сообщение. Разумное исключение — квалифицированный бизнес-аналитик.

Не путать с лидером продукта у Леффингуэлла и Уидрига#

Вигерс и Битти Леффингуэлл и Уидриг
Сколько По одному на класс пользователей Один на проект (или небольшая группа)
Кто Реальный пользователь из этого класса Часто менеджер продукта, менеджер по маркетингу или руководитель проекта
От чьего имени говорит Потребности одного класса Видение продукта в целом
Главная задача Поставлять и проверять требования своего класса Отвечать за видение, разрешать конфликты, согласовывать границы, говорить «нет»

Второе значение описано на странице Роль лидера продукта.

Как применять#

  1. Накидайте кандидатов в классы по контекстной диаграмме и организационной структуре.
  2. Сведите их в обозримый список и отметьте каждый класс как привилегированный, непривилегированный или прочий.
  3. Для каждого привилегированного класса назначьте сторонника и письменно договоритесь, какие обязанности он берёт и что может решать.
  4. Если реальный пользователь недоступен, напишите персону на основе исследований.
  5. Прежде чем считать выявление завершённым, убедитесь, что каждый класс был услышан.

Пример#

«Мастерская», вымышленная сеть веломастерских:

Класс пользователей Статус Чей голос звучит
Клиенты, записывающиеся онлайн Привилегированный Персоны и короткий опрос; ни один сторонник не может говорить за всех клиентов
Сотрудники стойки приёма Привилегированный Сторонник: опытный старший администратор
Механики Привилегированный Сторонник: старший механик с группой поддержки из трёх механиков из разных мастерских
Управляющие мастерских Прочий Интервью
Владелец (только читает отчёты) Прочий, косвенный пользователь Интервью
Система заказов поставщика запчастей Прочий, не человек Спецификация интерфейса
Боты, которые массово бронируют свободное время Непривилегированный Требования, которые не дают массово бронировать время

Источники и что почитать#

  • 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 (для сравнения).