Модуль 1.4. Elicitation: сбор требований без потерь
Интервью, воркшопы, наблюдение, протоколы, конфликт требований, приоритизация (MoSCoW/WSJF). Артефакты: протокол интервью, backlog требований. Практика: провести мини-интервью, оформить backlog.
Цель — научиться извлекать и фиксировать требования так, чтобы ничего не потерялось по дороге от головы стейкхолдера до кода и релиза. Разберём техники (интервью/воркшопы/наблюдение), строгую фиксацию (протоколы), обработку конфликтов, приоритизацию (MoSCoW/WSJF) и доведение до готового backlog с DoR.
Каркас elicitation-процесса (как сотруднику — к исполнению)
- Подготовка: карта стейкхолдеров, цели сессии, гипотезы и вопросы, черновые модели (BPMN as-is, глоссарий v0).
- Сбор: интервью/воркшоп/наблюдение/анализ артефактов, фиксация примеров и чисел.
- Анализ: нормализация терминов, разбор конфликтов, классификация требований (FR/NFR/ограничения).
- Фиксация: протокол решений, требования в реестр (backlog), ссылки на модели.
- Трассируемость: связываем Goal→REQ→Model/Contract→Story/Test→Metric.
- Приоритизация: MoSCoW (для MVP) и WSJF (для порядка разработки).
- Валидация: walkthrough с Dev/QA/архитектором/бизнесом, DoR, готово в спринт/поток.
Интервью: структура, вопросы, анти-паттерны
Роли и регламент
- Фасилитатор (SA) — ведёт, управляет таймингом, держит фокус.
- Скрайбер (SA/BA) — фиксирует факты/решения.
- Эксперты — предметные владельцы процесса.
- Правила: цель, 45–60 мин, запись по согласию, «решения проговариваем вслух».
Сценарий интервью (скелет)
1) Вступление: цель/тайминг/правила/запись. 2) Контекст: кто пользователь, где старт/финиш сценария. 3) Основной путь (happy path) → альтернативы → ошибки/таймауты/повторы. 4) Правила/ограничения: суммы/сроки/роли/регуляторика. 5) Данные/интеграции: источники, «истина», форматы, нагрузка. 6) NFR: latency/ошибки/доступность/безопасность/логирование/трейсинг. 7) Метрики успеха: как поймём, что «ок». 8) Риски/допущения/зависимости: что может пойти не так? 9) Подтверждение решений и следующий шаг.
Набор вопросов (шаблон повестки)
- Сценарий: «Когда пользователь начинает? что триггер? чем заканчиваем?»
- Исключения: «Что делаем при таймауте партнёра? при повторной отправке?»
- Правила: «Срок возврата? лимиты? кто одобряет?»
- Данные: «Какие поля обязательны? кто их заполняет? что валидируем?»
- Интеграции: «Кто владелец API? SLAs? идемпотентность?»
- NFR: «Какая приемлемая задержка p95? допустимый процент ошибок? RTO/RPO?»
- Безопасность: «PII/финданные? кто видит логи?»
- Метрики: «Как мы измерим пользу?»
Анти-паттерны интервью
- Наводящие вопросы («Правильно, что…?») → задавайте открытые и проверяйте перефразом.
- Обсуждение UI вместо правил/данных → держите фокус на процессах/контрактах.
- Нет чисел → всегда добивайтесь числа/порога/формулы.
- «Забыл записать» → назначьте скрайбера; фиксируйте решения немедленно, в конце зачитывайте.
Воркшопы: когда «много людей и мало времени»
Когда: несколько ролей/команд, конфликт интересов, масса правил.
Форматы:
- Event Storming (лайт) — клеим события домена («OrderCreated», «PaymentCaptured»), выясняем «дыры» и источники правды.
- Story Mapping — строим пользовательский путь и MVP-срезы.
- DMN-сессия — вместе переводим «устные договорённости» в таблицы решений (hit policy + примеры).
Выход: фото/экспорт доски + протокол решений → требования в backlog.
Наблюдение (Gemba/Shadowing) и анализ артефактов
- Gemba: смотрим, как реально живёт процесс (оператор кол-центра, бэк-офис).
- Shadowing: «следуем» за пользователем в реальном сценарии.
- Снимите метрики факта: среднее/медиана/пики, где «тормозит»/«ломается».
- Артефакты: регламенты, формы, лог-снимки, SQL-срезы — всё даёт факты против мифов.
Риск: эффект наблюдателя (люди ведут себя иначе).
Мера: анонимизация, несколько замеров в разное время.
Протокол: фиксируем так, чтобы читать через месяц
Шаблон протокола интервью/воркшопа
Тема/Цель: Дата/Время/Формат: Участники: (роль, ФИО) Артефакты на вход: (ссылки) Ключевые тезисы: (маркированно) Решения (Decision): D-001 ... D-00N Открытые вопросы (Open): O-001 ... O-00N (владелец/срок) Риски/Допущения (Risk/Assumption): R-001 ... A-00N Действия (Action): A-001 ... A-00N (владелец/срок) Привязки: REQ-ID / SRS / DMN / OpenAPI / Jira
Пример (фрагмент, e-commerce «возврат»)
- D-001: Возврат доступен в течение 30 календарных после CAPTURED.
- D-002: Идемпотентность по Idempotency-Key в POST /refunds.
- R-001: Риск «двойные списания при ретраях PSP» → требуются ключи корреляции и аудит-лог.
- O-001: Кто владелец лимита суммы? (финконтроль, дедлайн завтра).
Виды требований и карточка в backlog
Классификация
- FR — функциональные (поведение), NFR — нефункциональные (производительность/надёжность/безопасность/наблюдаемость/совместимость),
- Constraints — ограничения, Stakeholder/User/System — по источнику и точке зрения.
Карточка требования (единая форма)
REQ-ID: FR-PAY-001 Title: Создать платёж (идемпотентно) Type: FR Source: Интервью 12.09 + Протокол D-002 SpecLink: /srs/payments#create Model: /bpmn/checkout Contract: /api/openapi.yml#/payments AC/BDD: /tests/payments.feature#create DataImpact: Payment(idempotency_key), Order NFR Tags: perf, reliability, security, observability MoSCoW: Must WSJF: (BV=8, TC=6, RR=5, Size=5) = 19/5=3.8 Dependencies: PSP v3 API Risks: двойные списания (средний) Owner: SA Иванов Status: Review Version: 0.2.0
Конфликт требований: как разруливать
Типовые конфликты
- Бизнес vs Операции: «хотим менять адрес доставки до отгрузки» vs «нам это ломает SLA склада».
- Фронт vs Бэк: «реактивные обновления статуса» vs «нет надёжной шины».
- Прод vs Безопасность: «показывать больше данных» vs «PII/комплаенс».
Инструменты разрешения
- Факты и данные: замеры, лог-снимки, реальное SLA.
- DMN: делаем явные правила («если статус=Packed → запрет PATCH адреса»).
- Опции/последствия: ADR с альтернативами и влиянием на SLO/стоимость.
- De-risking: feature flag, ограниченный пилот, canary.
- RACI: кто решает (A), кто консультируется (C).
- Принцип «две версии»: временная backward compatibility вместо жёсткого лома.
Приоритизация: MoSCoW и WSJF
MoSCoW — «что в MVP»
- Must — без этого релиз бессмысленен/незаконен.
- Should — важно, но можно отложить.
- Could — полезно, когда есть время.
- Won’t (now) — сознательно не делаем.
Пример (фича «Возврат»):
Must: создать возврат, идемпотентность, аудит-лог.
Should: push-события RefundCompleted/Failed.
Could: SSE-стрим для статусов.
Won’t: кросс-валютные возвраты.
WSJF — «в каком порядке делаем»
Формула: WSJF = (BV + TC + RR) / Job Size,
где BV — ценность, TC — критичность по времени, RR — снижение риска/возможность, Job Size — относительная сложность.
Пример расчёта (3 элемента бэклога)
(оценки по Фибоначчи, округление WSJF до сотых)
|
Item |
BV |
TC |
RR |
Size |
Сумма |
WSJF |
|---|---|---|---|---|---|---|
|
Изменение адреса до Shipped |
5 |
6 |
3 |
3 |
14 |
4.67 |
|
Самообслуживание возвратов |
8 |
10 |
7 |
8 |
25 |
3.12 |
|
Подключить Apple/Google Pay |
13 |
8 |
5 |
13 |
26 |
2.00 |
Итог: порядок — адрес → возвраты → кошельки.
DoR для входа требований в разработку
- Карточка REQ заполнена (Type/Source/SpecLink/AC/NFR/DataImpact/Dependencies).
- Решения и открытые вопросы закрыты (D/O в протоколе выполнены).
- Модели и контракты готовы (BPMN/DMN/ER/Sequence, OpenAPI/AsyncAPI), версии указаны.
- NFR измеримы + определены SLI/алерты.
- Есть тест-данные и 3–5 BDD-сценариев.
- Связность в RTM: Goal→REQ→Story/Test/Metric.
Практические мини-кейсы
Кейс A (финтех): «Возврат платежа»
- Интервью: оператор возвратов, владелец PSP, финконтроль.
- Решения: срок 30 дней, идемпотентность по ключу, события Refund*.
- NFR: p95 < 2с, error-rate < 0.5%.
- Конфликт: «разрешать частичный возврат?» — ADR: частичный, но не более capturedAmount.
- Приоритизация: Must — инициировать; Should — события; Could — SSE.
Кейс B (e-commerce): «Смена адреса»
- Наблюдение: 18% обращений — «исправьте адрес».
- DMN: разрешено до status ∈ {Created, Paid, Packed}, затем 409.
- NFR: ответ < 500 мс; маскирование PII.
- WSJF: высокий из-за TC (снижаем отмены/поддержку).
Риски и как их гасить
- «Собрали хотелки» без ограничений → фиксируйте Constraints (регуляторика/технологии/сроки).
- Нет исходников фактов → без записей/логов/SQL-срезов спорят бесконечно. Просите артефакты.
- Смещение в UX/макапы → возвращайте фокус к процессам/правилам/данным/NFR.
- Серые термины → глоссарий и примеры значений.
- Приоритет «по ощущениям» → делайте WSJF-таблицу с допущениями.
- Открытые вопросы тянутся неделями → в протоколе каждому Open — владелец/дедлайн, эскалация по SLA.
Вопрос–Ответ
Q: Записывать встречи на диктофон?
A: Да, при согласии. Храните в корпоративном репозитории, в протоколе — ссылка и тайм-коды ключевых решений.
Q: Сколько людей на воркшоп?
A: 6–10. Больше — дробите по под-темам, иначе теряется фокус.
Q: Что делать, если эксперты не приходят?
A: Зафиксировать риск, эскалировать через владельца процесса/PO, дать варианты (асинхронные ответы/анкета/замена эксперта).
Q: Как фиксировать «мы не уверены»?
A: Assumption с владельцем и датой проверки; до подтверждения — feature flag/ограничение области.
Q: Можно ли без воркшопов — только интервью?
A: Можно для простых тем. Правила/конфликты/много участников — лучше воркшоп (DMN/Event Storming).
Артефакты модуля
Протокол интервью (заготовка)
Тема: Возврат платежа (цель — подтвердить правила и исключения) Дата/Формат: 12.09, 11:00–12:00, Zoom (запись согласована) Участники: Ольга (Операции), Петр (PSP), Анна (Финконтроль), Иван (SA, фасилитатор), Мария (SA, скрайбер) Вход: BPMN as-is, отчёт по возвратам (12% отказов), логи PSP Ключевые тезисы: ... Решения: D-001 (30 дней), D-002 (идемпотентность), D-003 (события Refund*) Открытые вопросы: O-001 (лимит суммы — Анна, 14.09), O-002 (MTLS с PSP — Петр, 15.09) Риски/Допущения: R-001 (двойное списание), A-001 (повтор колбэка — идемпотентность) Действия: A-001 (SA — DMN черновик), A-002 (PSP — предоставить SLA) Ссылки: /srs/refund v0.1, /bpmn/refund.drawio, /api/openapi.yml#/refunds
Backlog требований (пример таблицы)
|
REQ-ID |
Title |
Type |
MoSCoW |
WSJF |
SpecLink |
Contract |
AC/BDD |
Status |
|---|---|---|---|---|---|---|---|---|
|
FR-REF-001 |
Создать возврат (идемпотентно) |
FR |
Must |
3.12 |
/srs/refund#1 |
/api#/refunds |
/tests/refund#create |
Review |
|
FR-REF-002 |
Получить статус возврата |
FR |
Must |
2.40 |
/srs/refund#2 |
/api#/refunds/{id} |
/tests/refund#get |
Ready |
|
FR-EVT-003 |
Событие RefundCompleted |
FR |
Should |
1.60 |
/srs/refund#events |
/events/refund-completed |
/tests/refund#evt |
Draft |
|
NFR-PERF-004 |
p95 POST /refunds < 2s |
NFR |
Must |
— |
/srs/refund#nfr |
— |
/tests/perf#refunds |
Ready |
|
NFR-SEC-005 |
Маскирование PAN в логах |
NFR |
Must |
— |
/srs/refund#sec |
— |
/tests/sec#logs |
Ready |
Практика (2–3 часа): провести мини-интервью и оформить backlog
Задача: на выбранной теме («Возврат платежа» или «Смена адреса доставки») провести 30–45-мин интервью и собрать протокол + минимальный backlog из 6–10 требований с приоритизацией.
Шаги
- Подготовка (15 мин): цели, участники, вопросы, черновой BPMN as-is.
- Интервью (30–45 мин): запись по согласию; ведём протокол по шаблону.
- Анализ (30 мин): выписываем REQ-ID, классифицируем FR/NFR/Constraints, заполняем карточки.
- Приоритизация (20 мин): помечаем MoSCoW; считаем WSJF для 3–5 карточек.
- Валидация (10 мин): прогон с Dev/QA — проверяем DoR.
- Итог: публикуем в Confluence страницу «Протокол» и таблицу backlog, в Jira создаём соответствующие карточки с полями SpecLink/Contract/DataImpact/NFR/TestRef.
Критерии зачёта
- Есть протокол с решениями, открытыми вопросами и действиями.
- Backlog ≥ 6 требований с MoSCoW, ≥ 3 — с WSJF и атрибутами (SpecLink/AC/NFR).
- Для минимум 1 требования — ссылки на модели/контракты.
- DoR «проходит» (готово в разработку).
Шпаргалка «Сбор без потерь»
- Каждое решение — с номером (D-001) и сразу в протокол.
- Любая «общая фраза» → число/порог/пример.
- Всегда спрашивайте ошибки/таймауты/повторы.
- NFR измеримы, есть SLI/алерты.
- Backlog = карточки с полями (SpecLink/AC/NFR/DataImpact/Dependencies).
- MoSCoW — что в MVP; WSJF — что делаем раньше.
- Всё связано в RTM: Goal→REQ→Story/Test→Metric.
