На старте многих проектов есть бизнес-идея, спонсор и сроки, но нет согласованного scope и готовых артефактов. Задача системного аналитика — не ждать «ТЗ от заказчика», а организовать discovery: выявить проблему и ценность, зафиксировать допущения и риски, собрать минимальный каркас требований и договориться о критериях «достаточно ясности» для перехода к проектированию. Этот разбор показывает, как за 1–2 недели выйти из неопределённости к выборочному заполнению шаблонов из раздела 10.01.

1. Суть темы

Старт проекта без требований — ситуация, когда формализованные требования отсутствуют или противоречивы: нет User Story, Use Case, API-контрактов, согласованной ролевой модели, но уже есть давление «начать разработку». Это не отказ от требований, а управление неопределённостью (uncertainty) до появления артефактов, которые можно детализировать по шаблонам.

Роль системного аналитика здесь — не заполнять пустые шаблоны ради вида зрелости, а организовать исследование (discovery): отделить проблемное пространство от пространства решений, зафиксировать границы, построить backlog гипотез и определить, когда элемент готов к проработке по Definition of Ready (DoR) — см. 05.02 Scrum и Kanban (аналитик в Agile). На раннем greenfield-старте SA часто совмещает elicitation и scope framing с задачами product discovery; граница ролей BA / SA / PO — в 00.02 Бизнес-анализ vs Системный анализ vs Требования и 00.01 Кто такой аналитик (роли BA, SA, FA).

Типовой вопрос, который закрывает разбор: «Что делать в первые 1–2 недели, если заказчик говорит "сделайте как у конкурента", а разработка просит "хотя бы API"?» Ответ — минимальный согласованный пакет (vision, scope in/out, epics, assumption log, черновики NFR и ролей) и явный план перехода к шаблонам 10.01.x по мере появления архитектурных решений.

flowchart TD
    A[Бизнес-идея без ТЗ] --> B[Discovery: проблема и ценность]
    B --> C[Scope framing + assumption log]
    C --> D[Backlog epics / гипотезы]
    D --> E{Pitch vs результаты discovery?}
    E -->|Расхождение| F[Развилка A/B/C → решение DM]
    F --> C
    E -->|Согласовано| G{DoR выполнен?}
    G -->|Нет: не хватает данных| B
    G -->|Нет: нужен scope cut| C
    G -->|Да| H[Thin slice: шаблоны 10.01.x]
    H --> I[Delivery с progressive elaboration]

Когда такой старт — норма: greenfield-продукт, R&D, смена стратегии, дедлайн «к дате выставки» при сырой идее. Когда — красный флаг: regulated-домен без traceability с первого дня, отсутствие decision maker, параллельный coding без thin slice и freeze-точек.

Отличие от соседнего кейса: в 10.02 Разбор кейса "Миграция legacy-системы" отправная точка — богатый AS-IS и delta к TO-BE; здесь знаний почти нет, и задача SA — создать scope из гипотез, а не согласовать миграцию существующего.

2. Ключевые понятия

ТерминСуть для аналитика
Неопределённость требованийОбъём, детализация и стабильность требований низки; источники знаний разрознены или отсутствуют
Discovery / исследованиеФаза до или параллельно delivery: проблемные интервью, контекст, as-is/to-be на уровне концепции, прототипы, spike
Problem vs solution spaceСначала проблема и outcome для пользователя/бизнеса; фичи и интеграции — следствие
Assumption log / реестр допущенийЯвная фиксация того, что «считаем истинным» без доказательств; триггеры и сроки проверки; формат — см. 08.05 Управление рисками на этапе анализа
Scope framingIn scope / out of scope / deferred — даже при пустом backlog
Walking skeleton / thin sliceМинимальный сквозной сценарий для проверки гипотез; мост к BPMN, REST, FE-спецификациям
Progressive elaborationДетализация требований итеративно, а не Big Design Up Front
Definition of Ready (DoR)Критерии, когда элемент backlog можно брать в проработку по шаблонам 10.01.x; согласуется с командой разработки, не только с заказчиком
Requirements debtНакопленный риск из-за старта разработки без NFR, ролей и границ; paydown — через явный backlog и 02.05.05 Жизненный цикл требования

Связь с шаблонами 10.01: на раннем этапе шаблоны применяются выборочно и поэтапно — сначала vision и epics уровня 10.01.01 Шаблон User Story / 10.01.02 Шаблон Use Case, затем черновик 10.01.12 Шаблон нефункциональных требований (NFR) и 10.01.11 Шаблон ролевой модели, потом API, БД, очереди по мере архитектурных решений.

3. Как применяется в работе аналитика

Ниже — сквозной разбор типового кейса. Контекст вымышленный, но последовательность артефактов повторяема на реальных проектах.

Граница роли в narrative: в кейсе нет выделенного product owner — SA совмещён с product discovery: предлагает рамку, гипотезы и варианты scope, но финальное решение о MVP и value proposition остаётся за спонсором. В корпоративном контуре те же шаги выполняет SA при поддержке PO; аналитик не подменяет PO в приоритизации бизнес-ценности. Типичные ошибки на этой границе — в §4, подраздел «Граница роли SA».

3.1. Контекст кейса

Бизнес: B2B SaaS для автоматизации закупок в строительных компаниях. Вход: основатель принёс pitch «единый каталог поставщиков + заявки на закупку в один клик», дедлайн — демо через 10 недель на отраслевой конференции. Что есть: презентация для инвесторов, два письма от потенциальных клиентов с разными формулировками боли, команда из 4 разработчиков и 1 дизайнера. Чего нет: согласованного MVP, единого заказчика с полномочиями, API-контрактов, модели данных, NFR.

Ограничения:

  • Бюджет на 3 месяца runway; после конференции — ожидание первых платящих клиентов;
  • Интеграция с 1С «когда-нибудь» — конкуренты обещают, но деталей нет;
  • Регуляторных требований к персональным данным — минимум (B2B, без платёжного контура).

Цель SA: за 2 недели вывести проект из «нет требований» в состояние, где команда может начать thin slice с понятными границами и критериями приёмки.

3.2. Неделя 1. Фиксация рамки и стейкхолдеров

Задачи аналитика:

ЗадачаАртефактСодержание
Зафиксировать «зачем»Charter / one-pagerЦель: сократить время согласования заявки на закупку с 5 дней до 1; proxy-метрика на демо: 3 компании проходят сценарий «заявка → согласование → экспорт в Excel». Формат — уровень 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) (Vision & Scope), не полный BRD
Найти decision makerStakeholder mapОснователь — спонсор и единый approver scope; «голос рынка» — 2 контактных лица из писем (консультанты, не approver)
Разделить известное и неизвестноеAssumption & risk register«Согласование — линейное, 2 роли» (допущение); «1С — out of scope до post-MVP» (решение); риск: «строим не ту заявку» — проверка через 5 интервью. Структура полей — 08.05 Управление рисками на этапе анализа
Наметить границы системыContext diagramСистема «Procurement Hub»; внешние акторы: закупщик, согласующий, поставщик (TBD); интеграции: email-уведомления — in; 1С — out. Следующий шаг детализации — 06.03.05 C4-модель (Container level), когда появятся сервисные границы

Proxy-метрика на демо оформлена по принципам 02.01.02 Цели, KPI и критерии успеха (SMART, GQM): конкретный сценарий, измеримый порог (3 компании), привязка к дедлайну конференции.

Фрагмент one-pager (сжатый; полный формат — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)):

Цель: сократить цикл «заявка → согласование» с 5 дней до 1.
MVP демо: заявка из 1–5 позиций → линейное согласование (2 роли) → email-уведомление → экспорт в Excel.
Out of scope до конференции: каталог поставщиков, 1С, мобильное приложение.
Decision maker: основатель (единый approver scope).
Proxy-метрика: 3 компании проходят сценарий на стенде без помощи команды.

Вопросы на первой сессии с основателем:

  • Какую одну боль закрываем на демо — каталог, заявка или согласование?
  • Кто платит и кто ежедневный пользователь — это один человек?
  • Что сознательно не делаем до конференции?
  • Кто подписывает «достаточно для старта разработки» — только основатель или совместно с tech lead?

Конфликт интересов (типовой сценарий): если «голос рынка» из интервью требует каталог, а основатель настаивает на «заявке в один клик» — SA не выбирает победителя сам, а фиксирует расхождение в assumption log и выносит на решение спонсора с явными trade-off (срок демо vs полнота value prop). Эскалация и переговоры — 09.03 Управление конфликтами и переговоры, 09.07 Управление ожиданиями заказчика.

Оформление stakeholder analysis — см. 02.01.03 Анализ заинтересованных сторон (Stakeholder Map); границы — 02.01.04 Определение границ решения (Scope Modelling).

3.3. Неделя 1–2. Elicitation без готовых требований

Техники (по доступности информации):

Backlog гипотез (не только user stories):

Гипотеза H1: закупщики тратят > 30% времени на ручной сбор цен из Excel. Проверим: 5 интервью + прототип каталога. Критерий: 3 из 5 называют каталог «must have» на демо.

Гипотеза H2: согласование укладывается в 2 роли без параллельных веток. Проверим: разбор 3 реальных заявок от клиентов. Критерий: не более 2 ролей в 80% случаев.

Проверка гипотез — это validation на уровне эксперимента (02.04.01 Верификация и валидация (V&V)), не полный UAT.

Discovery в backlog: интервью, воркшоп и spike оформляются отдельными элементами backlog (discovery story / enabler), а не «невидимой работой». Пример: «DS-1: 5 интервью закупщиков», «EN-1: spike Kafka для r1» — capacity спринта делится между discovery и delivery (05.02 Scrum и Kanban (аналитик в Agile)). Без этого параллельный coding + discovery съедает 2 недели «только встречами».

Техники elicitation — 02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии, 02.02.04 Прототипирование и UI-UX-исследования; story map — практика Jeff Patton (см. источники).

Развилка после elicitation: pitch vs результаты H1

После 5 интервью H1 подтвердилась: 4 из 5 назвали каталог «must have» на демо. Одновременно H2 подтвердилась — согласование укладывается в 2 роли. Противоречие не в данных, а в сроках и value proposition для конференции.

SA подготовил три варианта для решения основателя:

ВариантДемо на конференцииКаталог (E4)Риск
A. Полный pitchЗаявка + каталогIn scope r0Не уложиться в 10 недель
B. Урезанный MVPТолько заявка → согласованиеDeferred post-demoPitch на слайдах ≠ продукт; нужен новый narrative
C. Смена value prop«Согласование за 1 день» вместо «каталог + заявка»Deferred, каталог — post-MVP epicИнвесторский deck устарел

Решение спонсора: вариант B — thin slice без каталога, E4 в deferred с явной датой post-demo. Обновлён one-pager: «Демо = скорость согласования; каталог — следующий релиз после подтверждения H1 на конференции». Противоречие pitch ↔ scope снято документом, а не замалчиванием: assumption log содержит запись «каталог must have по рынку, но не в r0 по решению DM от [дата]».

3.4. Минимальный пакет перед инженерным стартом

После двух недель discovery команда согласовывает Definition of Ready для thin slice. DoR — договорённость основателя, SA, tech lead и команды разработки (09.06 Ведение переговоров с техническими командами): что считается «достаточно API», кто ревьюит контракт, когда story можно брать в спринт.

АртефактСтатус в кейсе
Vision + scope in/outIn: заявка, линейное согласование, email; Out: 1С, мобильное приложение, аналитика; Deferred: E4 каталог (post-demo)
10.01.14 Шаблон глоссария и словаря данных12 терминов: Заявка, Позиция, Согласующий, Статус…
Epics (3–5 шт.)E1 Создание заявки; E2 Согласование; E3 Уведомления; E4 Справочник поставщиков (deferred post-demo, trace: H1 validated → E4 in backlog, deferred по решению DM)
10.01.01 Шаблон User Story4 stories уровня r0 для thin slice — только happy path
10.01.12 Шаблон нефункциональных требований (NFR)Черновик: 50 concurrent users, RTO не приоритет, audit log смен статусов, хранение в РФ
10.01.11 Шаблон ролевой моделиЗакупщик, Согласующий, Админ (read-only на демо)
DoR для API/БДStory должна иметь 02.04.02 Критерии приёмки (Acceptance Criteria) (AC), затронутые сущности, mock прототипа

Минимальная traceability (даже без regulated-контура): гипотеза → epic → story; assumption / риск → epic или deferred-элемент. На демо — 4 строки в 10.01.15 Шаблон матрицы трассировки, не полная ISO-модель.

Thin slice для первого спринта (freeze scope): «Закупщик создаёт заявку из 1–5 позиций (ручной ввод, без каталога) → отправляет → согласующий approve/reject → закупщик видит финальный статус». Scope заморожен до конца спринта 1; расширение — только через пересмотр с основателем (02.05.03 Управление объёмом (Scope Creep) и ожиданиями).

Joint sign-off «достаточно для разработки»: one-pager + DoR подписывают основатель (бизнес-scope) и tech lead (техническая реализуемость thin slice).

3.5. Переход к шаблонам 10.01 — только для thin slice

На этом этапе аналитик не заполняет все 15 шаблонов, а связывает только то, что нужно для одного сквозного потока. Детали полей REST, БД и BPMN — в соответствующих шаблонах; здесь — только сквозной пример. Формат User Story, а не Use Case, выбран из-за короткого backlog и итеративной детализации r0 — см. 04.03 Use Case vs User Story — выбор подхода.

User Story и BPMN

Пример story с AC (полный формат — 10.01.01 Шаблон User Story):

US-3: Как закупщик, я отправляю заявку на согласование, чтобы согласующий получил email и мог принять решение без звонка.
AC-1: После Submit статус заявки = PendingApproval.
AC-2: Согласующий получает email со ссылкой на заявку в течение 2 минут.
AC-3: При Approve / Reject закупщик видит финальный статус без перезагрузки страницы.

Сквозной процесс — 10.01.08 Шаблон сквозной фичи (BPMN-процесс) с дорожками: Закупщик, Система, Согласующий.

REST API и БД — один сквозной контур

Для r0 достаточно связки «создание и отправка заявки → решение согласующего». Минимум по 10.01.04 Шаблон спецификации REST API: POST /requests, GET /requests/{id}, POST /requests/{id}/submit, POST /requests/{id}/approve, POST /requests/{id}/reject. Черновик контракта — уровень 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) (OpenAPI draft, не полная спецификация). Сущности по 10.01.03 Шаблон спецификации БД сервиса: requests, request_lines, approval_decisions. Остальные эндпоинты и таблицы — по мере появления stories r1.

Kafka/Rabbit — не заполняем на r0: email через синхронный адаптер; события RequestApproved — в backlog r1 как spike (не user story) с последующим заполнением 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ).

Трассировка и ADR

10.01.15 Шаблон матрицы трассировки — story → API → поле БД → тест-кейс (пока 4 строки, не 400).

Ключевое архитектурное решение «монолит vs 2 сервиса» — 10.01.13 Шаблон архитектурного решения (ADR): на демо — монолит с модульными границами; split после первых платящих клиентов.

3.6. Процесс и коммуникация после старта разработки

Правила работы с неопределённостью:

  • Каждый review с основателем — протокол: известно / предполагаем / неизвестно;
  • Новые идеи «как у конкурента X» — в backlog с меткой deferred, не в текущий спринт без пересмотра scope;
  • Критические допущения из assumption log пересматриваются по триггеру (например, после 5-го интервью);
  • Progressive elaboration: детализация API/БД — только для stories со статусом «Ready» по DoR;
  • Freeze scope на время thin slice: любая работа вне r0 — stop-the-line и возврат к scope framing.

Состояние кейса на выходе из discovery (narrative «как дошли за 2 недели»). Полный перечень проверок перед dev — в 10.04 Чеклист аналитика перед стартом разработки:

Состояние в кейсе
One-pager подписан основателем и tech lead; decision maker зафиксирован
4 stories r0 в Ready; epics E1–E3 in scope, E4 deferred post-demo
H1 validated → E4 in backlog, deferred по решению DM; H2 validated → in scope
REST, БД, BPMN, FE, NFR, роли — да; Kafka, 1С — нет
Развилка pitch vs discovery (вариант B) — в assumption log и one-pager

3.7. Уроки кейса

  • Сработало: scope out для 1С снял 3 недели скрытой работы; assumption log предотвратил спор «мы обещали параллельное согласование»; явная развилка после H1 сняла противоречие «каталог must have, но не в демо»; thin slice дал демо на конференции;
  • Что пошло не так (типично): в спринте 2 команда начала детализировать каталог (E4, deferred) — типичный requirements debt: работа по отложенному элементу без пересмотра scope. Сработало правило freeze scope (02.05.03 Управление объёмом (Scope Creep) и ожиданиями): work stopped, возврат к backlog с меткой deferred и ссылкой на решение DM от недели 2;
  • Критерий «достаточно discovery»: decision maker подписал MVP и out of scope; есть epics с AC; NFR-скелет не блокирует интеграции; первый thin slice трассируется в матрице; pitch на демо согласован с фактическим scope.

4. Типовые ошибки и ограничения

Ограничения подхода

  • Discovery не бесплатен — нужны время, доступ к людям и полномочия на решения; без sponsor/decision maker аналитик фиксирует гипотезы, но не закрывает scope.
  • Regulated / safety-critical домены — «старт без требований» сужается до «старт без полной детализации». Минимум с первого дня: assumption & risk register, NFR-скелет, traceability гипотеза → epic → story и assumption → риск → mitigation; полный SRS — позже (00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148), 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)).
  • Аутсорсинг / фикс-прайс без SOW — другой профиль риска: контракт требует scope baseline раньше; этот кейс заточен под in-house / стартап с product discovery.
  • Параллельный coding и discovery увеличивает waste, если нет thin slice, discovery items в backlog и freeze-точек на scope.
  • Analysis paralysis — бесконечное исследование без критерия «достаточно»; нужен явный DoR и дата «decision to build».

Типичные ошибки

ОшибкаПоследствиеЧто делать аналитику
Путать «нет документа ТЗ» с «можно не выяснять потребность»Неверный продукт, scope creepНачать с 02.01.01 Определение бизнес-проблем и возможностей и problem space
Игнорировать расхождение pitch и результатов discoveryДемо не совпадает с обещаниямиЯвная развилка A/B/C и решение DM с обновлением one-pager
Сразу детализировать API/БД без vision и сценариевКонтракты под неверную модельСначала epics и thin slice; API — после прототипа или story map
Не вести assumption logСпоры «мы так не договаривались»Реестр допущений с владельцем и датой проверки (08.05 Управление рисками на этапе анализа)
Нет out of scopeБесконечный backlogЯвный deferred-список на каждом review
Один «голос заказчика» без проверкиЛокальный optimum3–5 интервью; при расхождении с DM — эскалация (09.07 Управление ожиданиями заказчика)
DoR только с заказчиком, без разработки«API есть, но не то»Согласовать DoR с tech lead (09.06 Ведение переговоров с техническими командами)
Пропуск NFR и ролей «до MVP»Блокеры на безопасности и интеграцияхЧерновик 10.01.12 Шаблон нефункциональных требований (NFR) и 10.01.11 Шаблон ролевой модели в неделю 1–2
Бесконечный discoveryСрыв дедлайнаКритерии выхода + 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано) для MVP
Пустые шаблоны 10.01.xИллюзия зрелостиЗаполнять шаблон только при DoR; иначе — one-pager и гипотезы

Граница роли SA: аналитик организует clarity и варианты решений, но не подменяет product owner / спонсора в приоритизации бизнес-ценности. Если decision maker отсутствует — эскалация риска, а не silent scope.

Связи с другими разделами базы

Источники и дополнительные материалы

Стандарты и своды знаний

Agile и product discovery

Книги и практические методики