Бриф проекта / рабочая схема
Бриф спортивного продукта до оценки разработки
Эта страница — рабочая рамка для discovery. Она помогает описать не только экраны, но и состояния, источники данных, критичные действия, деградацию и условия релиза.
1. Пользовательский сценарий
- Какую задачу пользователь решает за одну сессию?
- Какие действия необратимы или связаны с деньгами?
- Что должно оставаться понятным при обновлении live-данных?
- Какие состояния требуют отдельного текста или блокировки?
2. Контракт данных
- Какой источник является источник истины?
- Есть ли несколько sports-data providers?
- Как выглядят version, timestamp и freshness?
- Какие provider-specific поля запрещено протаскивать в UI?
3. Сценарии отказа
- Что делает UI при timeout, stale, disconnect и partial provider сбой?
- Какие команды можно безопасно retry?
- Как пользователь узнаёт о неопределённом результате?
- Где нужен suspend вместо показа устаревшего состояния?
4. Эксплуатация
- Какие версии клиента и API должны сосуществовать?
- Есть ли long-lived SSE/WebSocket sessions?
- Какие product metrics определяют успешный rollout?
- Как выглядит rollback и кто принимает решение?
5. Приёмочные проверки
- У каждого критичного компонента есть state table.
- У каждого интеграционного граница ответственности есть contract owner.
- Невозможные состояния сформулированы явно.
- Деградация проверяется тестом, а не только runbook.
6. Материалы для команды
После заполнения brief удобно связать решения с ADR, component spec и руководство по интеграции. В библиотеке ITNAN эти форматы разделены, чтобы интерфейсное решение не смешивалось с эксплуатационным runbook.