📜Бизнес-функциональные требования, когда и зачем БФТ - договор на языке пользователей о том, как будет работать система: сценарии, CJM, блок-схема процесса, понятные границы. Без технических деталей - они пойдут в ТЗ.
🎯 Когда требуется БФТ Мы эксплуатируем внутренние сервисы. БФТ готовим тогда, когда меняется опыт пользователя или его сценарии, либо появляется новый путь в системе. Цель - договориться на языке пользователей о новом поведении системы, границах и критериях приемки. 🚦Триггеры для БФТ: • новые шаги в процессе, статусы, роли, поля, формы, уведомления; • новый путь или пользовательская история, которая ранее отсутствовала; • изменения модели данных или обменов, которые пользователь увидит в отчетах, виджетах, интеграциях;
🧩 Артефакты БФТ: • CJM ключевых ролей и точек контакта; • блок-схема процесса (AS-IS/TO-BE) с границами и исключениями; • user stories с примерами и ожидаемым результатом; • список исключений и результат на языке пользователей.
🛠️ Когда без БФТ можно обойтись • минорные изменения, где смысл и риск очевидны: новая колонка в отчете, переименование кнопки, сортировка по умолчанию, обязательность поля без изменения логики процесса. Здесь достаточно RFC с описанием и ожидаемым результатом. • изменения, не затрагивающие пользовательский опыт: изменение API, индексы в таблицах, оптимизация запросов или обновление вендора.
· 25.08.2025
Полезный материал
ответить
коммент удалён