Есть разные подходы к ведению требований к ПО: одни пишут полноценные сценарии использования, другие выбирают пользовательские истории, а третьи — вообще избегают формализации требований, считая это пустой тратой времени.
Но я так не считаю. Формализация — большой и важный этап разработки требований. В статье об этом расскажу: как происходит ведение требований у нас, какие этапы мы проходим, каких правил придерживаемся и что будет, если отклоняться от правил. Если вы системный или бизнес-аналитик, владелец продукта или просто работаете с требованиями к программному обеспечению, то эта статья для вас.
Прежде всего зададим контекст.
Под программным обеспечением будем понимать цифровой продукт, над созданием которого работает продуктовая команда.
Типовая команда продукта состоит из:
владельца продукта (product owner);
команды разработки: системный аналитик, разработчики и тестировщик;
часто к ним подключается дизайнер, отвечающий за проектирование пользовательского интерфейса;
и архитектор, который помогает с проработкой архитектуры будущего решения.
Большинство продуктовых команд работают по Scrum со спринтами по 1-2 недели. У каждого спринта есть цель, которая связана с какой-то ценностью, в первую очередь, для клиента.
В бэклог текущего спринта должны попадать задачи с понятными требованиями. В противном случае команде разработки потребуется время на их уточнение, что в условиях ограничения по времени повышает риск недостижения поставленной цели.
И здесь возникает формализация.
Этапы формализации требований
Мы избегаем неопределенности и берём в работу задачи только с понятными требованиями, настаиваем на их формализации.
Сейчас расскажу, как это происходит. Общая схема проработки требований выглядит примерно так.
Создание и развитие цифрового продукта направлено на удовлетворение определенных потребностей бизнеса. Чаще всего они имеют финансовое выражение — сводятся к росту прибыли, положительной разнице между доходами и расходами организации. Часть прибыли направляют на развитие бизнеса, что должно привести к ещё большему росту прибыли, часть которой также направляют на развитие и т.д. Если бизнес хочет результат, то он должен быть описан ясно и четко.
За определение потребностей бизнеса отвечает владелец соответствующего цифрового продукта (PO). Он общается с представителями бизнеса, изучает бизнес-процессы, проводит исследование рынка и формулирует бизнес-требования к продукту. У нас они обычно выражаются в виде документа Word (BRD) и эпиков (Epics) в Jira.
BRD содержит полное описание бизнес-требований, которым должен удовлетворять цифровой продукт. На основе данного документа и с учетом принятых архитектурных паттернов архитектор (Solution Architect) разрабатывает видение (Vision) архитектуры будущего решения. Ниже — общий вид BRD как пример.
Epics представляют собой набор отдельных бизнес-требований. Команда продукта (Product Team) проводит их анализ и декомпозицию на пользовательские истории (User Stories). Ниже — пример Epics и User Stories. Справа — Sab-Tasks (о них чуть дальше).
Каждая история характеризуется стейкхолдером, его потребностью и ценностью от её закрытия, критериями приёмки. Именно User Stories обычно и составляют основу бэклога текущего спринта команды.
Однако на данном этапе их ещё нельзя брать в работу. Требования не до конца определены.
На основе Vision для User Stories системный аналитик (SA) разрабатывает проектные решения (Specs).
Обычно они фиксируются на отдельной страничке в пространстве продукта в Confluence. Specs содержат дизайн технических решений, которые необходимо реализовать в цифровом продукте. Они должны быть понятны всем членам команды разработки. Пример Specs на скриншоте ниже.
При необходимости, для User Stories готовится дополнительный артефакт — дизайн пользовательских интерфейсов (UI). Для этого команда подключает к работе над продуктом дизайнера (Designer). Часто он ведёт разработку в Figma и помимо макетов пользовательского интерфейса готовит кликабельные прототипы для дальнейшей валидации требований. Ниже пример подобного UI.
Примечание: Дополнительно про прототипы в статье Использование прототипов в процессе разработки программных продуктов.
На основе Specs и UI команда разработки (DevTeam) выполняет декомпозицию User Stories на подзадачи (Sub-Tasks) для каждого члена команды. Пример Sub-Tasks на картинке.
Таким образом, бизнес-требования и требования стейкхолдеров определены, дизайн пользовательских интерфейсов и технических решений готов, перечень подзадач для их реализации сформирован. Остаётся только выполнить оценку User Stories, приоритезировать бэклог продукта и спланировать текущий спринт.
Мы не торопимся, следуем принятому процессу, следим за качеством проработки требований.
Но что произойдёт, если отклониться от процесса? Об этом расскажу дальше.
Отклонение от процесса
Правила существуют, чтобы их нарушать. А процессы — чтобы от них отступать. Время от времени продуктовые команды отклоняются от описанного процесса в надежде выпустить новую фичу как можно быстрее. Тогда схема проработки требований сократится до такого состояния.
Отклонения обычно проявляются в отказе от разработки технических артефактов — Vision и/или Specs.
Первый артефакт опускают, когда команда разработки состоит из опытных специалистов, способных самостоятельно спроектировать архитектуру будущего решения, а само решение — это доработка существующего цифрового продукта. В этом случае сокращается срок проектирования, однако повышается риск того, что архитектурное решение будет противоречить принятым паттернам и его реализацию откажутся ставить в бой.
Specs бывают не востребованы при мелких доработках, когда каждому члену команды полностью понятно, что и как требуется реализовать, а внесённые изменения достаточно отразить в проектной документации. Однако в случае крупных доработок отсутствие Specs может потребовать дополнительного времени на уточнение требований и следовательно повышает риск недостижения цели спринта.
Я — руководитель системных аналитиков. Мои ребята распределены по продуктовым командам. Однажды пришлось выслушивать недовольство PO одной из команд, связанное с двукратным увеличением оценки сроков проекта. Первичная оценка составляла три месяца. Но когда половина этого периода закончилась, пришло осознание, что необходимо полгода.
На протяжении нескольких спринтов одни и те же User Stories оставались в работе. Тот факт, что они не закрывались, говорит о том, что они не были проработаны должным образом. А DevTeam не до конца понимала требования к цифровому продукту.
Отсюда мы вывели правило — любое отклонение от процесса должно быть осознанным и обоснованным.
Мы исследуем новые способы ведения требований. Однако избегаем слепого следования чужим рекомендациям. Не всегда то, что работает у других, заработает и у нас. Отклоняясь от правил мы понимаем, зачем это делаем.
Итог
Я кратко описал, как мы ведём требования к программному обеспечению. Безусловно процесс не идеален. Иногда команды от него отклоняются с целью ускорить выпуск новой фичи в бой. Однако уверен, из него можно почерпнуть что-то полезное.
Также буду благодарен, если поделитесь собственным опытом ведения требований. Особенно интересует вопрос нахождения компромисса между интересами бизнеса, желающего сократить ТТМ, и команды разработки, члены которой ориентированы на разработку качественного цифрового продукта.
В качестве дополнительных материалов хочу поделиться ссылками на три выступления по теме ведения требований к программному обеспечению. Я регулярно рекомендую их системным аналитикам. Возможно, приведённый в них материал окажется полезен и вам:
Use Case VS User Story. Выбираем подход к специфицированию требований
Георгий Савельев. Толковый бизнес-аналитик: Разработка бизнес-требований
Рекомендуем почитать [подборка редактора блога]
Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.
