Заинтересованные лица и классы пользователей

Сегодня в офисе Chatty очень много людей. Кажется, большинство из них Даня видит впервые.

Даня

Что-то случилось? Откуда в офисе столько людей?

Артём

Начинаем выявлять требования! Знакомься, это — заинтересованные лица!

Даня

О, класс! Давно хотел познакомиться с теми, кто изучает английский с помощью нашего веб-приложения 😊

Артём

Расстрою тебя — тут сейчас не ученики Chatty, а другие заинтересованные лица.

Даня

Видимо, мне нужно объяснение 😂

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

Системный аналитик и выявление требований

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

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

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

Что делает системный аналитик при выявлении требований:

Изучает бизнес-требования

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

Определяет пользователей

Для выявления пользовательских требований, нужно определить пользователей продукта. Чтобы не упустить из виду важные потребности пользователей, системный аналитик делит их на классы согласно пользовательским характеристикам (о классах мы расскажем подробнее). Затем аналитик выбирает конкретных пользователей, с которыми в дальнейшем будет работать для выявления требований.

Выявляет требования

Используя различные методы выявления требований (интервью с пользователями, наблюдение за ними и анализ документов), системный аналитик формирует требования к ПО.

Заинтересованные лица

Мы уже не раз упоминали заинтересованных лиц наряду с пользователями, без которых невозможно выявить пользовательские требования. Самое время поговорить о том, кто относится к заинтересованным лицам.

Заинтересованное лицо (stakeholder — cтейкхолдер) — человек, группа людей или организация, связанные с продуктом. Стейкхолдеры заинтересованы в решении проблемы или удовлетворении потребности с помощью продукта. Они могут повлиять на продукт, или продукт может повлиять на них.

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

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

Для кого важен этот проект?
На кого повлияет этот проект?
Кто может повлиять на этот проект?
Кто может одобрить или отклонить этот проект?

Чтобы не упустить важных заинтересованных лиц, можно:

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

Пользовательские требования и требования заинтересованных сторон — взаимозаменяемые понятия.

Подумайте, кто может быть заинтересованным лицом в проекте по созданию функции «словарь» для Chatty. Можно выбрать несколько вариантов ответа.

Ученики языковой школы Chatty

Ученики Chatty — стейкхолдеры, поскольку именно для них готовятся обновления и они могут повлиять на проект.

Отдел закупок в Chatty

Отдел закупок не имеет прямого отношения к созданию словаря, так как его сотрудники отвечают за приобретение товаров, заключают контракты на поставку продукции и прочее.

Тестировщики, работающие над голосовым помощником Chatty

Тестировщики, которые работают над голосовым помощником, не связаны с проектом «словарь».

Системный аналитик Артём

Является заинтересованным лицом, так как влияет на проект.

Мама Артёма, интересующаяся, чем занимается сын

Заинтересованное лицо в проекте «Артём», но никак не связана с проектом «словарь».

Роли заинтересованных лиц

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

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

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

Клиент (не путать с клиентом в архитектуре ПО) — потребитель продукта или сервиса, производимого компанией. Например, клиенты Chatty — ученики.
Пользователь — человек, который напрямую взаимодействует с ПО. Пользователи языковой школы Chatty — и её ученики, и её преподаватели. Не всегда среди пользователей ПО есть клиенты, особенно если ПО создаётся для внутренних нужд компании.
Спонсор — стейкхолдер, инициирующий действия по определению бизнес-потребностей и созданию решения, которое закрывает эти потребности. Спонсором может быть маркетолог или менеджер продукта.
Эксперт в предметной области — человек с глубоким пониманием бизнес-функций, релевантных для создания ПО.
Команда разработки — системный аналитик, разработчики, менеджер проекта, тестировщики и другие специалисты.
Оперативная поддержка — стейкхолдер, ответственный за поддержку и управление продуктом.
Регулятор — учреждение, ответственное за определение стандартов и контролирующее их исполнение. Например, законодательные органы власти.

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

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

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

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

По целям, которых они стремятся достичь при выполнении трудовой деятельности.
По частоте, с которой они используют ПО.
По привилегиям доступа (рядовой пользователь, администратор) и уровню безопасности.
По опыту в предметной области и опыту работы с компьютерными системами.
По платформе, которую они используют (настольные ПК, ноутбуки, планшеты, смартфоны).
По тому, будут ли они работать с ПО напрямую или нет.

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

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

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

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

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

Среди учеников 54% — женщины и 46% — мужчины.

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

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

Техническая поддержка не является пользователем функции «словарь».

На данный момент продукт Chatty доступен только в веб-версии. В будущем планируется добавить мобильную версию для смартфонов и планшетов.

Можно разделить пользователей на классы по используемой платформе. Сейчас класс только один — пользователи веб-версии (на ПК или ноутбуках).

Веб-версия доступна как на macOs, так и на Windows, поскольку запускается через браузер.

Так как приложение запускается в браузере, не важно, какая операционная система у пользователя. Можно не выделять отдельные классы.

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

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

Заказчик будет недоволен продуктом и оставит плохие отзывы на компанию разработки ПО

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

Менеджеру придётся найти аргументы, чтобы договориться с клиентом, или предложить ему скидку

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

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

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

Придётся полностью переделывать дизайн или архитектуру сайта

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

Разработчики будут демотивированы из-за того, что потратили силы зря

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

Подведём итоги

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

Основой, от которой системный аналитик может отталкиваться при выявлении требований могут быть бизнес-требования.

Заинтересованные лица или стейкхолдеры — люди, которые так или иначе связаны с решением: либо они влияют на него, либо оно на них.

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

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