В бэклоге есть высокоценное требование, которое зависит от низкоценного технического требования. Что произойдёт с планом релиза, если приоритизировать их независимо?
План релиза может стать невыполнимым: команда выберет высокоценное требование, но не сможет реализовать его без обязательного технического предусловия. Приоритизация должна учитывать не только самостоятельную бизнес-ценность, но и зависимости между требованиями.
Практики управления требованиями и продуктовым бэклогом развивались как ответ на частые изменения приоритетов и ограниченные ресурсы. Простая сортировка по ценности оказалась недостаточной, поскольку реализация одного требования может быть невозможна до выполнения другого.
Поэтому в анализе требований учитывают зависимости, технические ограничения, риски и порядок поставки. Это позволяет планировать не только наиболее ценные функции, но и необходимые условия для их появления.
Высокоценное требование может иметь низкоприоритетное на вид техническое предусловие: например, новый механизм хранения данных, настройку интеграции или изменение модели доступа. Если рассматривать их независимо, предусловие останется внизу бэклога, а зависимая функция попадёт в ближайший релиз.
Последствиями станут блокировка разработки, перенос сроков, незапланированные обходные решения или выпуск функции в неполном виде. Дополнительный риск — команда начнёт реализовывать техническое предусловие в спешке, без достаточного анализа его влияния на другие требования.
Сначала аналитик фиксирует связь: высокоценное требование является зависимым, а техническое требование — его предпосылкой. Затем проверяет направление зависимости, обязательность предусловия и возможность заменить его другим решением.
Если зависимость обязательна, техническое требование должно быть запланировано раньше или вместе с зависимой функцией. Это не означает, что ему автоматически присваивается более высокая бизнес-ценность: его приоритет повышается из-за влияния на порядок поставки.
Полезно различать несколько случаев:
Приоритизация должна учитывать бизнес-ценность, срочность, стоимость, риск, зависимости и готовность требований. Важно не скрывать техническое требование внутри функционального: явная связь обеспечивает трассируемость и позволяет объяснить заказчику, почему менее заметная работа нужна раньше видимой функции.
Команда планировала функцию автоматического расчёта комиссии. Она имела высокую ценность для бизнеса, но зависела от технического требования: получать актуальный курс валют из внешнего источника. Это требование оценили как низкоценное, поскольку пользователь не взаимодействовал с ним напрямую.
Рассматривались три варианта. Можно было поставить расчёт комиссии первым, но это создавало риск блокировки. Можно было временно использовать фиксированный курс, что ускоряло демонстрацию, но делало результат непригодным для промышленной эксплуатации. Третий вариант — сначала реализовать получение курса и обработать ошибки внешнего сервиса.
Выбрали третий вариант, потому что зависимость была обязательной, а временный обход искажал бизнес-результат. В плане сначала появилась минимальная поставка механизма курса с обработкой недоступности источника, затем — расчёт комиссии. Благодаря этому команда заранее выявила ограничения внешней интеграции и не сорвала релиз основной функции.
1. Всегда ли техническое предусловие нужно ставить раньше всей функциональности?
Нет. Сначала нужно проверить, является ли зависимость обязательной. Иногда достаточно реализовать минимальный вертикальный срез, использовать временную замену или ограничить сценарий. Раннее техническое требование оправдано, когда без него нельзя проверить ценность функции или когда обходной путь создаёт неприемлемый риск.
2. Чем зависимость отличается от обычного порядка задач?
Зависимость означает, что результат одного требования является необходимым условием другого. Обычный порядок может быть выбран для удобства или равномерной загрузки команды и допускает перестановку работ. При зависимости перестановка нарушает реализуемость, увеличивает риск или делает результат непроверяемым.
3. Как обнаружить скрытые зависимости до планирования релиза?
Нужно анализировать предусловия, затрагиваемые данные, интеграции, права доступа, бизнес-правила и архитектурные ограничения. Для каждого требования полезно задать вопрос: «Что должно уже существовать, чтобы этот сценарий можно было реализовать, проверить и принять?» Результат фиксируют в связях между требованиями и обсуждают с представителями бизнеса, разработки и тестирования.