Метод CRISP для написания качественных требований

Метод CRISP ...«Пользователи должны иметь возможность легко управлять своими настройками»... ...«Система должна обеспечивать бесшовный процесс онбординга»... ...«Пользователи должны иметь возможность быстро находить релевантный контент»... Эти фразы звучат умно, но не проходят элементарную проверку на качество требования: можно ли понаблюдать за действиями пользователя и понять, сработала ли функция так, как нужно? «Легко» — по чьей оценке? «Бесшовный» — как измеряется? «Релевантный» — по каким критериям? Когда требования не определены, инженеры трактуют их по-разному, QA не могут составить на их основе тест-кейсы, метрик и аналитик нет, и продакт попадает в созданный им же замкнутый круг переделок. Подход Алистера Кокберна CRISP заменяет расплывчатые требования структурированными сценариями, описывающими наблюдаемое поведение. CRISP – это: – Context (Контекст) – Role (Роль) – Intent (Цель/Намерение) – Steps (Шаги) – Postcondition (Пост-состояние). Тоже самое требование об «управлении настройками» в формате CRISP будет выглядеть так: – Контекст: Авторизованный пользователь с активной учетной записью. – Роль: Владелец учетной записи. – Цель: Изменить частоту получения уведомлений. – Шаги + alternate flows. Пользователь открывает «Настройки», выбирает раздел «Уведомления», меняет частоту с «Ежедневно» на «Еженедельно», подтверждает изменение и видит сообщение о подтверждении. Alternate flows: пользователь отключил PUSH в телефоне/разные часовые пояса/и т.д. – Пост-состояние: При следующем цикле рассылки система отправляет уведомление. Три CRISP-совета 🍤 Стоит явно зашивать в Context/Intent связку с JTBD, иначе метод просто оптимизирует форму требования (которое может быть ошибочным), а не ценность фичи и продукта. 🍤 Постусловие пишется первым, шаги задом наперёд. Если вы не можете сформулировать постусловие до того, как придумали шаги, то вы не знаете, что строите, а просто рисуете UI. Постусловие — это ещё и спецификация аналитики, а не только тест-кейс, потому что use case, доведённый до постусловия, автоматически диктует то, какой ивент нужно логировать. 🍤 PRD пишется не только с ИИ, но и с QA и разрабом, которые пытаются сломать постусловие, потому что единоличное авторство use case воспроизводит ту же проблему, что и с расплывчатым PRD, просто один человек теперь уверен в своей однозначности.

Ценность метода реализуется в адверсариальном ревью: кто-то должен спросить «а если...» до продакшена (а не как обычно после). И не забывайте про alternate flows!

Готово! Абстракция заменена конкретной последовательностью действий и проверяемым результатом, объём работ становится чётко определён и не допускает вольной трактовки, оценки разрабов становятся точнее, приёмочное тестирование упрощается, метрики и аналитика настроены с самого начала. – Chef de produit: bon appetit!