Почему ваши бизнес-требования саботируют проект и как это исправить?
Бизнес-требования – основа успешного проекта, но их низкое качество способно поставить под угрозу даже самые перспективные идеи. Некачественные требования парализуют работу, срывают сроки, увеличивают бюджет и в итоге ведут проект к провалу.
Столкнувшись с подобной ситуацией, я решила изучить, что отличает действительно эффективные бизнес-требования. Это искусство, в основе которого лежат ясность, системность и понимание ценности каждого шага.
В этой статье я поделюсь ключевыми принципами, которые помогут превратить сырую идею в работающее решение, обеспечив четкость, структурированность и практическую ценность ваших требований.
Как сделать бизнес-требования основой успешной разработки?
Вот основные идеи!
1. Предельно подробно описаны болевые точки, которые должно закрывать решение - какую проблему мы решаем.
2. Как резюме проблематики описана ценность в виде "Как [роль], я хочу [цель], чтобы [ценность]".
3. Описание бизнес-процесса:
- для нового БП: текстовое описание БП, схема bpmn.
- для изменения существующего: текстовое БП AS IS, включая схему bpnm, резюме анализа, что требует изменений и в рамках каких требований, описание измененного БП TO BE, включая схему bpmn, c указанием, какие шаги остались прежними, а какие новые.
Схемы должны включать не только действия, выполняемые от имени ролей (пользователей), но и шаги, осуществляемые:
- Автоматически - без участия пользователя.
- Автоматизировано - с частичным участием пользователя.
Для каждого автоматического или автоматизированного шага необходимо указать:
- Систему, в которой выполняется шаг.
- Логику выполнения или условия запуска (если применимо).
4. Предоставлены прототипы макетов, с учетом того, что они могут быть изменены при детализации функциональности командой разработки.
- Прототипы должны пройти UI/UX тестирование концепции, ориентированное на проверку логики пользовательского потока, удобства выполнения ключевых задач и понятности интерфейса, а не на тестирование деталей, которые могут быть изменены в процессе разработки.
- При выполнении корректировки существующего пользовательского интерфейса также должны быть перечислены те элементы, которые остаются прежними, и новые.
5. Описаны все use case, включая альтернативные.
6. Указаны критерии приемки.
7. Общие принципы формулировки бизнес-требований (БТ):
- Бизнес-требования должны быть понятны всем участникам команды и трактоваться ими однозначно.
- Сложные части бизнес-требований необходимо отображать схематично для облегчения восприятия.
8. Ключевые требования
Должны быть выделены минимально необходимые и достаточные требования, без которых решение не может быть внедрено: если удалить хотя бы одно из ключевых требований, решение станет неработоспособным, в том числе ключевые требования производительности.
9. Дана ссылка на общие требования производительности, принятые на проекте.
10. Указано, требуется ли версионность данных или накопление исторических данных для решения задачи.
11. Должны быть перечислены роли, которые участвуют в функциональности. Для каждой роли указать:
- какие действия она может выполнять,
- какие действия недоступны,
- ограничения в доступе к данным и функциям.
12. Указано, как система должна реагировать, если пользователь с определенной ролью:
- Пытается выполнить недоступное ему действие.
- Запрашивает доступ к данным, которые находятся вне его полномочий.
- Описаны механизмы валидации и способы уведомления пользователя о нарушении ограничений.
13. Описаны требования к форматам документов (если применимо).
14. Включены бизнес-правила (нормы отрасли, внутренние регламенты компании и т.п.), которые оказывают влияние на функциональность системы
15. При наличии расчетов предоставлены:
- Формулы.
- Методика расчета (если применимо).
16. Должны быть описаны сценарии расширения - как функциональность может быть модифицирована или дополнена новыми функциями.
17. Должны быть описаны сценарии неожиданных ситуаций - поведение системы при экстремальных ситуациях.
18. Каждое требование должно:
- Представлять собой только одно требование (не объединять несколько требований в одно).
- Описывать значимый результат, то есть четко объяснять, какой полезный результат или цель должна быть достигнута для бизнеса или пользователя. Например: вместо "Добавить кнопку" - "Пользователь должен иметь возможность скачать отчет".
- Быть выполнимым в рамках возможностей системы.
- Быть тестируемым (должна быть возможность проверить и однозначно подтвердить выполнение).
- Быть ясным, точным и исключать многозначность (все участники команды должны одинаково понимать требование).
- Быть законным (не нарушать действующее законодательство).
- Быть структурированным:
- Требования, близкие по смыслу, должны находиться рядом.
- Требования не должны противоречить друг другу.
Исключать избыточность: каждое требование формулируется только один раз. - Все требования должны быть изложены с одинаковым уровнем детализации.