Все статьи
Иерархия требований
Дата: 05.09.2026
В этой статье мы поговорим о таком понятии в продуктовой разработке, как иерархия требований.
Кому будет полезно прочитать данную статью: владельцу продукта, менеджерам проектов, тим-лидам команд, бизнес-аналитикам и системные аналитикам.
Начиная работать с требованиями, необходимо учитывать то, что требования должны соответствовать определенным принципам:
- коммуникация лицом к лицу в общении между заказчиком-исполнителем, между различного рода заказчиками;
- обмен контекстом между участниками и выработка договоренностей сначала устно и потом уже фиксация результатов договоренности в документах;
- детализация требований сверху вниз. Мы начинаем с концепции и дальше детализируем требования. В классической структуре это ТЗ и ЧТЗ. Если мы смотрим продуктовую разработку, то у нас есть концепция или видение продукта. И дальше мы его разбиваем на артефакты, которые лежат на более низких уровнях;
- инкрементальность, т.е. каждый этап реализации – это прирост ценности для клиента;
- необходимая экспертиза для того, чтобы на каждом уровне требования были написаны с привлечением необходимых экспертов для того, чтобы снизить риски и повысить качество артефактов;
- передача бизнес-контекста важнее идеально написанных требований. Бизнес-контекст должен присутствовать на всех этапах работы с требованиями.
Требования — необходимый артефакт при планировании. В зависимости от горизонта планирования используются различные форматы требований отличающиеся по глубине проработки и детализации. Какие уровни планирования бывают:
- стратегическое планирование – год+, часто его называют портфельным уровнем;
- тактическое планирование – квартал, уровень программы и продуктов;
- оперативное планирование – это отрезок времени менее месяца. Чаще всего на таком уровне планирования участвуют команды, уровень команд.
Каждому уровню планирования соответствует свой элемент бэклога. Для стратегического планирование используются эпики, проекты, инициативы. Для тактического уровня используются фичи или возможности для развития бизнеса, возможность в вашем продукте. В оперативном планировании используются задачи, пользовательские истории, работы, описанные в виде историй.
Каждый из уровней планирования должен быть связан с другими, то есть появляется атрибут ссылки другой уровень.
Состав элементов уровня портфеля или эпик, проект или инициатива обладает бизнес-контекстом и бизнес метрикой — это атрибут эффективности, который понятен бизнесу.
Опережающий индикатор в эпике — это индикатор, который показывает динамику изменения для движения к результату в процессе. То есть чем раньше можно реагировать и связывать действия с изменением индикатора, тем лучше можно принимать решения о продолжении или заморозки эпика. Иными словами, если индикатор не показывает тех прогнозных значений, которые планировались, то встает вопрос о пересмотре плана действий или других управленческих воздействиях.
Так же обязательны нефункциональные характеристики и владелец или ответственный за эпик.
У фичи продукта или фичи программы обязательно должен быть определен контекст или проблематика, то есть зачем необходимо сделать этот элемент. Если дана проблема, то предполагается, что будет описана и форма предлагаемого решения. Решение в продуктовом подходе подразумевает наличие метрики через оценку эффекта. Чаще всего используется такое понятие, как гипотеза о выгоде, где указывается, какая конкретная метрика поменяется и как. Последним, но не менее важным обязательным атрибутом являются критерии приемки. В критериях приемки учитываются не только функциональные, но и нефункциональные требования.
На уровне команды требования уже декомпозируются достаточно сильно, и в каждом элементе, с которым работает команда, должен быть контекст потребности, роль ситуации, в котором этот контекст важен. То есть если рассматривать пользовательскую историю, то в ней обязательно присутствует роль. Если мы рассматриваем описание работы, то обязательно указывается контекст и ситуация.
Критерии приемки – обязательный атрибут командных требований. Они дают возможность проверить требование, протестировать сценарий, проверить правильность сценария.
Выше была разобрана иерархия требований сверху вниз. В процессе построения иерархии требований команды и подразделения сталкиваются с типовыми ошибками. Перечислим основные ошибки:
- отсутствие контекста на всех уровнях;
- отсутствие метрики и индикаторов эффективности;
- отсутствие связи элементов между собой;
- избыточное описание элементов верхнего уровня;
- избыточное описание бизнес-требований, которые только усложняют, а не дают общее понимание проблематики и решения;
- отсутствие нефункциональных требований на всех уровнях;
- отсутствие критериев в приемке на среднем и нижнем уровне, то есть на уровне фич и историй.
Если вы хотите подробно узнать о данных артефактах или у вас есть такие проблемы, добро пожаловать к нам на продуктовую школу, в которой мы учимся решать проблемы и оттачиваем знания в работе с требованиями.
Если вы дочитали до этого места, значит, вам интересен полезный контент о продуктовом маркетинге. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, подписывайтесь на MAX-канал Enterprise Product Management.
