Управление требованиями и определение бизнес-процессов
~ 50 минут
Чтобы детально спланировать работы по проекту, важно определить ряд моментов:
- выявить стейкхолдеров — людей, которые могут влиять на реализацию проекта;
- выяснить требования к продукту;
- описать пользовательские сценарии.
Когда эти параметры станут известны, можно планировать изменения в архитектуре и распределять задачи.
В этом уроке вы познакомитесь с правилами работы со стейкхолдерами и тем, как структурировать и описывать требования к проекту.
Управление стейкхолдерами
✏️ При реализации проектов в компании всегда есть люди, которые заинтересованы в изменениях и могут повлиять на ход работы, — таких людей называют стейкхолдерами. Стейкхолдеры могут участвовать в бюджетировании, определять требования и принимать результаты.
Например, для компании N важно запустить стриминг-платформу и научиться привлекать клиентов сегмента B2C. За создание всей платформы отвечает менеджер продукта, но за будущие стратегию продаж и маркетинг — руководитель отдела цифровых продаж. Он становится одним из стейкхолдеров создания стриминг-платформы, так как заинтересован, чтобы и в продукте, и вокруг него были реализованы инструменты привлечения и аналитики пользователей.
В проекте может быть несколько стейкхолдеров. Чтобы учесть интересы всех, стейкхолдерами нужно управлять.
В целом стейкхолдеров можно разделить на две группы:
- Внутренние стейкхолдеры — это сотрудники компании, заинтересованные в проекте. Например, в компании N это будут руководитель отдела цифровых продаж или сотрудники команды производства контента.
- Внешние стейкхолдеры — государственные органы и другие участники рынка, которые проявляют интерес к проекту. Например, если конкурент компании N тоже хочет создать стриминг-сервис, значит, нам лучше запустить MVP раньше конкурента, а это может привести к изменениям в проекте.
Процесс работы со стейкхолдерами
Чтобы организовать управление стейкхолдерами, нужно:
- Выявить стейкхолдеров и определить их требования. Можно начать с заказчиков или руководителей смежных подразделений.
- Определить степень вовлечённости стейкхолдеров в проект и их влияние. По степени влияния и вовлечённости можно выделить четыре группы стейкхолдеров:
- Высокая вовлечённость, высокое влияние С ним(или с ними) команда взаимодействует постоянно, получает обратную связь, часто именно эта группа стейкхолдеров инициирует проект. Для компании N стейкхолдером с высокими влиянием и вовлечённостью может быть директор стриминг-платформы.
- Высокая вовлечённость, низкое влияние Это могут быть команды, которые участвуют в проекте, но не принимают важных решений. Например, отдел поддержки пользователей компании N заинтересован в проекте, но его интерес прежде всего в том, чтобы заранее знать, какая будет нагрузка на сотрудников отдела.
- Низкая вовлечённость, высокое влияние Такие стейкхолдеры могут сильно повлиять на проект, но напрямую они в нём не заинтересованы. Например, отдел закупок компании N: его сотрудники могут не знать тонкостей оборудования для IT-инфраструктуры, и если оборудование закупить не получится, то стриминг-платформа компании N не запустится. Ещё примером такого стейкхолдера могут быть отделы информационной безопасности в некоторых организациях: при составлении матрицы стейкхолдеров их можно упустить из виду, но ближе к релизу проекта они могут повлиять на запуск — как правило, сильно сдвинуть сроки.
- Низкая вовлечённость, низкое влияние Обычно это внешние стейкхолдеры — СМИ или конкуренты.
- Наконец, для организации работы стейкхолдеров их интересы нужно регулярно подвергать анализу и переоценке: проводить встречи для синхронизации, уточнять требования и рассказывать о результатах.
Выявить стейкхолдеров с высоким влиянием и учесть их требования — задача менеджера проекта. Чтобы лучше структурировать информацию о стейкхолдерах, можно оформить ключевую информацию о них в виде матрицы.
Матрица стейкхолдеров
В матрице можно указать любую информацию, которая важна для проекта. Допустим, если проект интеграционный, можно занести в матрицу отношение стейкхолдера к IT-системе или связать его с какой-то группой требований — например, с требованиями к информационной безопасности.
Такая матрица — это в большей степени инструмент менеджера. Но не стоит ею пренебрегать, поскольку важно получать и описывать требования стейкхолдеров и непосредственного заказчика проекта или менеджера продукта. Если не выявить важного стейкхолдера, часть работ по проекту окажется незапланированной.
Пример
Контент компании N будет транслироваться на её каналах, и нужно предусмотреть юридические тонкости, связанные с этим. Юридический отдел компании в этой ситуации — стейкхолдер с высоким влиянием, но низкой вовлечённостью. Если его не выявить на раннем этапе, то на платформе может появиться контент, на который не выкуплены права, что может повлечь за собой как судебные тяжбы, так и изменение сроков запуска всей платформы.
Если требований много, то их можно выделять в группы и связывать со стейкхолдерами из матрицы. Степень влияния и важность стейкхолдера поможет определить, насколько требование приоритетно.
Как описывать требования
Требования к продукту — это набор полезных для пользователя характеристик, которые он ожидает от продукта. Требования делятся на функциональные и нефункциональные.
✏️ Функциональные требования описывают то, что система должна делать, то есть конкретные функции.
Например, функциональное требование продукта компании N может звучать так: платформа должна отправлять уведомления пользователям о статусе их подписки — сообщения об оформлении, условиях и отключении.
✏️ Нефункциональные требования описывают то, как система будет реализовывать функции при работе. Их ещё называют атрибутами качества. Это могут быть требования, которые влияют на производительность, надёжность, удобство использования системы.
Для компании N нефункциональное требование будет, например, таким: платформа должна обрабатывать не менее 500 запросов в секунду при пиковых нагрузках. Если при обработке запросов участвуют другие системы, они тоже должны выдерживать пиковую нагрузку.
Набор функциональных и нефункциональных требований поможет определить архитектуру изменений.
Модель описания требований FURPS+
Функциональные и нефункциональные требования удобно описывать по модели FURPS+. Её применяют в заказной разработке, когда набор требований заранее согласуется с заказчиком и включается в план реализации проекта.
Функциональные (Functionality, F) — то, что система должна выполнять на релизе. Такой пример мы описывали выше.
Удобство использования (Usability, U) — правила, по которым система взаимодействует с пользователем. Это могут быть UX/UI-дизайн, правила работы интерфейса для людей с ограниченными возможностями, справочная информация по работе с системой.
Надёжность (Reliability, R) — всё, что относится к работоспособности системы: время простоя в случае сбоя, режим работы, график обслуживания. Обычно невозможно сделать систему устойчивой в любой ситуации, поэтому сразу важно заложить ограничения.
Производительность (Performance, P) — всё, что относится к быстродействию и потреблению ресурсов: время отклика, масштабирование системы, число одновременных пользователей.
Поддерживаемость (Supportability, S) — возможность и правила тестирования, параметры расширения и доработки системы.
Ограничения (остальное со знаком +) — это дополнительные ограничения, которые мы накладываем на систему: языки программирования, правила проектирования, применение определённых баз данных. Эту группу можно отнести к архитектурно значимым требованиям, о которых мы поговорим позже.
💡 Собрать всё на раннем этапе может быть сложно, особенно когда разрабатывается новый продукт, — в таких случаях обычно новые требования возникают в ходе работы. Однако даже в этом случае можно использовать FURPS+, выделяя только значимые требования.
Если мы находимся на этапе планирования и нужно определить, как реализовать конкретный набор задач, то будет достаточно базовых функциональных требований и некоторых нефункциональных, влияющих на архитектуру и реализацию. То есть на раннем этапе можно ограничиться категориями F, R и P+.
Конечный набор требований зависит от задач. Например, если компания собирается купить ERP-систему, то при выборе поставщиков могут быть важны требования группы S в части возможности поддержки и расширения. То же касается и группы требований U: для определённых задач они могут быть важны и должны быть явно указаны — например, если нужно, чтобы все приложения компании соответствовали дизайн-коду.
Архитектурно значимые требования
✏️ Архитектурно значимые требования — это требования, которые оказывают влияние на архитектуру системы. Это могут быть требования как к программному обеспечению, так и к оборудованию.
Другими словами, если появляется архитектурно значимое требование, то оно точно окажет влияние на архитектуру и реализацию. Чаще всего в эту группу попадают нефункциональные требования.
Например, для стриминг-платформы нужно обеспечить возможность полного развёртывания в облаке с перспективой максимально простой миграции на свою инфраструктуру. С одной стороны, это нефункциональное требование — оно может быть сформулировано в разделе P, если раскрыть его со стороны масштабирования. Но такое требование существенно затронет архитектуру, потому что для его удовлетворения можно, например, рассматривать вариант развёртывания системы в Kubernetes-кластере, а это важно учесть сразу.
В модели FURPS+ за архитектурно значимые требования отвечает последний раздел + — ограничения (Restrictions).
Обычно выделяют четыре группы ограничений:
- Ограничения проектирования: средства разработки, технологии.
- Ограничения реализации: стандарты разработки кода или требования к архитектуре.
- Требования к интерфейсам: форматы взаимодействия компонентов, протоколы или способы взаимодействия, например, синхронные или асинхронные.
- Физические ограничения: они накладываются на аппаратные средства и окружение системы, например, температура, влажность, условия эксплуатации оборудования.
Пример описания требований по FURPS+
Рассмотрим модель FURPS+ для стриминг-платформы компании N.
Оргструктура платформы:
- Управление развития:
- Отдел продуктового развития и сопровождения.
- Отдел технологического развития и сопровождения платформы.
- Отдел маркетинга и цифровых продаж.
- Отдел закупок.
- Отдел технологического подбора.
Чтобы определить архитектуру и запланировать задачи, нужно разобраться, что и как должна уметь делать платформа.
При описании удобно использовать одну или несколько таблиц, а также нумеровать требования или делать ссылки, чтобы потом их можно было использовать в тексте документации и описывать пользовательские сценарии.
💡 Важно акцентировать внимание на том, что и как должна делать система, не уходя в детали описания, полученные от стейкхолдеров. Конечный список требований можно обсудить ещё раз и договориться о том, являются ли эти требования самыми важными на данном этапе.
Можно самостоятельно добавить требования, которые кажутся важными. Например, в конспекте указано: пользователь может войти также по этому номеру, установив пароль, и с одноразовым кодом для дополнительной безопасности. Можно сделать допущение, что пользователю выдаётся начальный пароль после регистрации, он приходит в СМС, затем пароль можно поменять в профиле на платформе, а значит, нам нужна страница с профилем.
Также требования можно разбить по функциональным группам, например, «Авторизация и аутентификация», «Главная страница». Ещё можно выделить требования к сторонним системам, если такие зависимости есть. Конечный формат описания зависит от конкретной задачи.
Также выделяем в общую группу ограничений архитектурно значимые требования.
Итак, после нескольких встреч менеджера проекта по запуску MVP с менеджером продукта, IT-командой и представителями бизнеса компании N был составлен конспект. А затем менеджер конкретизировал его и перевёл в перечень требований по модели FURPS+:
Этот набор требований можно уточнять, обсуждать детали, от него можно будет отталкиваться при проектировании архитектуры и планировании задач.
Кроме требований, важно определить, с помощью каких действий пользователя они будут реализованы и к каким результатам в системе или смежных системах приведут. Для этого используются различные описания пользовательских сценариев.
Пользовательские сценарии
✏️ Use Cases, или пользовательские сценарии, описывают, какие действия совершает пользователь и как система на них реагирует. Иначе говоря, это варианты использования. Например, пользователь вводит номер телефона в форму авторизации — это очень простой Use Case, состоящий из одного шага.
Сценарии можно описывать с разным уровнем детализации, в том числе до подробных действий. В Agile-подходах к разработке часто используется инструмент User Story. Обычно это небольшая задача с фокусом на действиях пользователя в продукте. Её могут сформулировать так: «Как пользователь платформы я хочу иметь возможность фильтровать контент на главной странице, чтобы видеть только то, что хочу посмотреть в данный момент».
Нередко таких формулировок достаточно, чтобы понять задачи, требования и архитектуру проекта или его части. В Agile из таких User Stories формируется список задач, внутри которых рассматриваются отдельные пользовательские сценарии. Подробнее ознакомиться с таким подходом можно в дополнительных материалах к уроку.
Построение пользовательских сценариев
Сценарии можно описывать от общего к частному, то есть определять, какие есть Use Cases, как они связаны, и потом детализировать описание каждого из них.
Это можно сделать в виде диаграммы, на которой отражаются:
- действующие лица (пользователи);
- варианты использования;
- при необходимости другие системы, которые участвуют в процессе.
Такие диаграммы используются в стандарте UML, но можно использовать и произвольную нотацию. Когда диаграмма готова, можно текстом описать детали каждого пользовательского сценария.
Пример диаграммы пользовательского сценария:
Вместо диаграммы можно использовать таблицы:
Каждый сценарий можно детализировать:
Можно добавить или убрать элементы из этого списка в зависимости от задачи. На самом деле Use Case — это инструмент системного аналитика, который позволяет детально описать задачи команде разработки. Скажем, на этапе проектирования архитектуры, как правило, ещё нет возможности описать настолько детальные требования. Поэтому часто достаточно только описания шагов Use Case, чтобы определить, какие системы должны быть задействованы в архитектуре. В следующем уроке мы поговорим об этом более детально.
Use Cases с описанием удобно оформить в виде таблицы:
Если мы ранее получили общие функциональные требования, то их можно детализировать с помощью Use Case.
Рассмотрим требования для компании N:
F8 — Пользователь может оплатить подписку после бесплатного периода в месяц. Оплата происходит картой через платёжный шлюз партнёра Simple and Fast Payments.
В ходе обсуждений с продакт-менеджером для этого требования можно расписать такой сценарий:
В детальном описании сценариев отдельным пунктом выделены альтернативные, поскольку обычно Use Case имеет множество ветвлений, на которые система реагирует по-разному.
Потоки вариантов использования
✏️ Последовательность выполнения пользовательского сценария называют потоком варианта использования (Use Case Flow). Основную последовательность, которая приводит к целевому результату, называют основным потоком (Basic Flow), а различные ветвления — альтернативными потоками (Alternative Flow).
Основной поток определяет, приходит ли пользователь к цели (например, к оформлению заказа). Если в ходе выполнения Use Case на первых шагах происходит ошибка, которая приводит к окончанию сценария, и никаких ветвлений ещё не было, то это не означает, что пользователь прошёл по основному потоку, это также будет альтернативный поток.
Например, пользователь при оформлении заказа не смог выбрать подходящий адрес доставки и решил не продолжать оформление, а просто закрыл сайт.
На схеме ниже видно, что шаги могут приводить к ветвлениям:
Когда мы рассматриваем работу с требованиями для планирования изменений и дальнейшего проектирования архитектуры, достаточно рассматривать основной поток выполнения, потому что именно он приведёт нас к целевому действию.
Основной поток для оплаты подписки в компании N может выглядеть так:
Оплата подписки после бесплатного периода — UC1
- Пользователь пытается запустить просмотр контента.
- Платформа проверяет, что у пользователя нет активной подписки.
- Пользователю предлагают оплатить подписку.
- Если он соглашается, то платформа сохраняет подписку в статусе «Ожидает оплаты».
- Происходит переход на страницу платёжной системы.
- Пользователь производит оплату.
- После оплаты платёжный шлюз вызывает платформу.
- Платформа подключает подписку, пользователь видит окно успеха и может пользоваться контентом.
На шестом шаге может быть ветвление, если оплата не прошла. Например, пользователь производит оплату:
- Если пользователь не оплатил подписку в течение 10 минут и платежный шлюз не уведомил платформу, то подписка переводится из статуса «Ожидает оплаты» в «Неактивно».
- При возврате на сайт пользователь видит окно с тем, что нужно попробовать оформить подписку ещё раз.
Это ветвление — частное требование. Взаимодействие платформы и платёжного шлюза во всех вариантах можно продумать позднее. Нам важно определить, что в будущем нужно будет реализовать задачу по интеграции и как будут взаимодействовать компоненты.
Описание бизнес-процессов
При разработке систем пользовательские сценарии обычно относят к детальным требованиям. Чтобы лучше понять, как будет реализован продукт, и запланировать изменения, могут быть полезны описания бизнес-процессов. Если они описаны достаточно, то потенциально их можно использовать как альтернативу описания Use Cases.
Для описания процессов может использоваться нотация EPC. Визуально она похожа на алгоритмическую последовательность действий: имеет логические операторы, описание функций в процессе и событий, которые к ним приводят.
Так выглядит пример нотации EPC.
Эта нотация предполагает, что к действиям (функциям) всегда приводят события. Она хорошо позволяет описывать даже сложные процессы, но не акцентирует внимание на инициаторах событий (например, на сотрудниках компании и их взаимодействиях) — это важно в бизнес-процессах.
Для удобного описания таких взаимодействий существует нотация BPMN — она позволяет детально описывать процессы со всеми взаимодействиями, потому что они выделяются на отдельные «дорожки» (swimline). Эта нотация позволяет описывать как ручные процессы, так и автоматизированные за счёт большого числа различных объектов в ней: например, задач, связей, шлюзов. Эта нотация также имеет программное представление в виде XML, что позволяет использовать её в системах моделирования бизнес-процессов BPMS. За счёт своей универсальности сегодня BPMN является одним из самых популярных инструментов для моделирования и описания процессов.
Более детально с различными нотациями можно ознакомиться в дополнительных материалах к уроку.
- Материал в блоге Практикума о том, кто такие стейкхолдеры и как выгодно взаимодействовать с ними.
- Развёрнутый разбор требований FURPS+ c дополнительными примерами.
- Исчерпывающая статья в блоге Практикума с примерами пользовательских сценариев.
- Про agile-подход при построении пользовательских сценариев.
- Англоязычный материал о том, что такое основные и неосновные потоки в Use Cases.
- Про нотации бизнес-процессов:
Итоги
- Когда принято решение о той или иной трансформации бизнеса, нужно конкретизировать требования к новшествам и выявить тех, кто в компании в них заинтересован или может на них повлиять. Людей, влияющих на внедрение, называют стейкхолдерами, и прежде всего нужно выявить тех из них, кто обладает наибольшим влиянием и проявляет наибольший интерес к реализации. Обычно это руководители компании и отделов, кого напрямую затронут грядущие перемены.
- Стейкхолдерами можно и нужно управлять. Обычно этим занимается менеджер проекта, и его задачей становится создать матрицу стейкхолдеров, чтобы найти пересечения их интересов. Чтобы эти интересы не противоречили и не тормозили проекты, нужно проводить встречи для синхронизации, уточнять требования и рассказывать о результатах.
- Когда стейкхолдеры и степень их влияния определены, они помогут определить требования к продукту. Требования — это набор пользовательских характеристик, которые делают продукт полезным и удобным. Требования бывают функциональными — они буквально касаются функций, и нефункциональными — в них заложены технические характеристики и ограничения будущего продукта.
- Требования удобно фиксировать в модели FURPS+, которая учитывает параметры продукта от функций и удобства использования до технических ограничений. Важно помнить, что на начальном этапе модель FURPS+ не всегда можно заполнить полностью — это нормально. На первых итерациях достаточно воспользоваться только теми параметрами, которые удалось выявить. Постепенно модель будет пополняться новыми вводными.
- Чтобы лучше понять итоговый вид продукта, его технические стороны и возможные затруднения в реализации, нужно определять и фиксировать возможные пользовательские сценарии. Описание пользовательских сценариев также может вернуть разработку продукта на уровень выше и дополнить требования к продукту.