Отдельная группа заинтересованных лиц и участников проекта – пользователи. Это те, кто будет непосредственно работать с системой. В самом начале работы над проектом необходимо определить и охарактеризовать различные классы пользователей, чтобы узнать о требованиях представителей всех важных классов.
Пользователь (user) – лицо или организация, которая использует действующую систему для выполнения конкретной функции.
Классы пользователей
Пользователей продукта можно подразделять по таким признакам:
• частота использования продукта;
• опыт в предметной области и опыт работы с компьютерными системами;
• функциональность, которая им требуется;
• задачи, которые им приходится решать;
• права доступа к системе, например «обычный пользователь», «гость» или «администратор».
На основе этих признаков формируются классы пользователей. Некоторых сотрудников можно отнести к нескольким классам. Например, администратор иногда работает с системой как рядовой пользователь. Конечные пользователи ПО – это потенциальные кандидаты на отдельные классы пользователей.
Одни классы пользователей важнее других. При принятии решения о приоритетах или поиске компромисса между требованиями, выдвинутыми различными классами пользователей, мнение привилегированных классов имеет первостепенное значение.
Привилегированные классы – это группы пользователей, работа которых с продуктом определяет, достигнет он заявленных бизнес-целей или нет.
Непривилегированные классы – это пользователи, которые по причинам безопасности, конфиденциальности или правовым причинам не работают с продуктом.
Игнорируемые классы – это остальные классы пользователей, которые можно проигнорировать. Они получат то, что удастся создать; при разработке системы не нужно учитывать их интересы.
Прочие классы – пользователи, мнения которых при определении требований к продукту имеют примерно одинаковое значение.
У каждого класса пользователей есть свой набор требований, сформировавшийся в ходе выполнения задач. Кроме того, появляются различные нефункциональные требования, например удобство применения. Они влияют на проектирование пользовательского интерфейса.
Скажем, новичков волнует, насколько легко научиться работать (или вспомнить принципы работы) с продуктом. Такие клиенты предпочитают графические интерфейсы, упорядоченное представление информации на экране, подробные подсказки мастеров и согласованность с другими приложениями, с которыми они уже знакомы.
Опытных пользователей больше интересует легкость использования и эффективность работы. Они ценят клавиатурные сокращения, макросы, возможности настройки, панели инструментов, возможности создания сценариев. В некоторых случаях они даже предпочитают интерфейс командной строки графическому интерфейсу пользователя.
Важно помнить о классах косвенных, или вторичных, пользователей. Они могут не напрямую обращаться к приложению, а работать с его данными и сервисами через другие приложения или отчеты. Однако даже опосредованный клиент все равно остается клиентом.
Классы пользователей не обязательно состоят из людей. Сторонние приложения и аппаратные компоненты можно рассматривать в качестве дополнительных классов пользователей, с которыми взаимодействует система.
Пример
Система впрыска топлива в автомобиле – пользовательский класс ПО, встроенного в систему управления двигателем. Система впрыска топлива не может говорить сама за себя, поэтому аналитику придется выяснить у инженера, разработавшего систему впрыска, требования к ПО, которое управляет процессом.
Выявление классов пользователей
Один из полезных способов определения классов называется «от расширения к сжатию» (expand then contract). Для начала нужно придумать как можно больше классов пользователей, пусть даже их будет слишком много. Важно не пропустить какой-либо класс, иначе это аукнется позже.
Следующий этап – выявить группы с похожими потребностями. Их можно объединить в один класс или рассматривать как несколько подклассов одного крупного класса пользователей. В списке отдельных классов не должно быть больше 15 пунктов.
Здесь могут оказаться полезными следующие вопросы.
1. Кто пользователь системы?
2. Кто заказчик (экономический покупатель) системы?
3. На кого еще окажут влияние результаты работы системы?
4. Кто будет оценивать и принимать систему, когда она будет представлена и развернута?
5. Существуют ли другие внутренние или внешние пользователи системы, чьи потребности необходимо учесть?
6. Кто будет заниматься сопровождением новой системы?
7. Не забыли ли мы кого-нибудь?
Классы пользователей, их отличительные черты, меру ответственности и физическое расположение в спецификации требований к ПО нужно задокументировать.
Для чего нужна классификация пользователей
Например, одна компания, разрабатывающая ПО для 65 корпоративных клиентов, рассматривала каждого из них как отдельного пользователя со своими потребностями. Описание требований с позиции каждого клиента сильно затрудняла работу. А вот классификация клиентов по шести классам значительно упростила сбор требований для будущих версий продукта.
Не все заинтересованные в проекте лица на самом деле будут работать с продуктом. Поэтому класс пользователей – это группа людей, которым следует предоставить возможность выразить свое мнение о создаваемом продукте.
Организационная модель
Информация в этом разделе носит скорее ознакомительный характер. Но при работе в крупных компаниях она будет очень полезна в процессе сбора требований для выявления стейкхолдеров и общения с ними, да и в целом позволит понять, как у вас в принципе строятся процессы в организации.
Организационная модель – это принципы формирования подразделений компании, делегирования полномочий и наделения ответственностью. По сути, организационная модель показывает, как формируются подразделения.
На практике применяют следующие принципы организационных моделей.
1. Функциональная модель: одно подразделение = одна функция.
2. Процессная модель: одно подразделение = один процесс.
3. Матричная модель: один проект = группа сотрудников из разных функциональных подразделений.
4. Модель, ориентированная на контрагента: одно подразделение = один контрагент, то есть клиент или клиентская группа, поставщик, подрядчик и пр.
Последняя модель применяется в случае, если рынок контрагента ограничен. Например, когда число потребителей невелико, целесообразно применить модель, ориентированную на клиента или клиентскую группу: одно подразделение = один клиент.
В большинстве же случаев используются функциональная и процессная модели, а также их различные модификации.
Структуры управления на многих современных предприятиях построены в соответствии с функциональной моделью. В ее основе лежат принципы, сформулированные еще в начале ХХ века немецким социологом Максом Вебером; он создал концепцию рациональной бюрократии.
Принципы функциональной модели следующие.
1. Принцип иерархичности уровней управления. Каждый нижестоящий уровень контролируется вышестоящим и подчиняется ему.
2. Принцип соответствия полномочий и ответственности работников управления их месту в иерархии.
3. Принцип разделения труда на отдельные функции и специализации работников по выполняемым функциям.
4. Принцип формализации и стандартизации деятельности. Он обеспечивает однородность выполнения работниками своих обязанностей и скоординированность задач.
5. Принцип обезличенности выполнения работниками своих функций.
6. Принцип квалификационного отбора. Наем и увольнение с работы производится в строгом соответствии с квалификационными требованиями.
Организационная структура, построенная в соответствии с этими принципами, получила название иерархической, или бюрократической, структуры. Наиболее распространенный ее тип – линейно-функциональная (линейная) структура.
Процессные системы строятся на основе нескольких базовых принципов концепции управления процессами. В 80-х годах XIX века Фредерик Тейлор предложил менеджерам использовать методы процессного управления для наилучшей организации деятельности. В начале 1900-х годов Анри Файоль разработал концепцию реинжиниринга. Реинжиниринг – это осуществление деятельности в соответствии с поставленными задачами путем получения оптимального преимущества из всех доступных ресурсов.
Принципы процессной модели следующие.
1. Принцип объединения процедур. Операции, которые выполняли разные сотрудники, интегрируются в одну, то есть происходит горизонтальное сжатие процесса. Если не удается привести все шаги процесса к одной работе, то создается команда, отвечающая за этот процесс.
2. Принцип неразрывной последовательности. Шаги процесса выполняются в естественном порядке. Работа производится в том месте, где это целесообразно, силами смешанных групп, состоящих из работников различной предметной (функциональной) принадлежности или специализации.
3. Принцип владельца процесса. Уполномоченный менеджер обеспечивает единую точку контакта. Он играет роль буфера между сложным процессом и заказчиком. Ведет себя с заказчиком так, как если бы отвечал за весь процесс.
4. Принцип самостоятельности выбора. Исполнители принимают самостоятельные решения и несут ответственность за получение заданного результата деятельности.
5. Принцип горизонтального контроля. Качество результата проверяется его потребителем – следующим элементом процессной цепочки.
6. Принцип системности (целостности) управления. Управление затратами происходит по месту их возникновения. Система управления издержками строится совместно с организационной структурой, без отрыва от деятельности, по правилу «один процесс – одно подразделение – один бюджет».