Выявление требований: интервью, наблюдение, воркшопы, работа с документами

В BABOK этот раздел работы называется elicitation, а не collection. Разница не косметическая. «Сбор» предполагает, что требования уже существуют в готовом виде и лежат у заказчика в голове или в папке — надо прийти и забрать. «Выявление» признаёт три неприятных факта:

1. Люди не знают всего, что знают. Опытный оператор склада не расскажет про правило «на возврат по маркетплейсу нужен акт», потому что для него это не правило, а воздух. Это неявное знание (tacit knowledge) — оно проявляется в действиях, а не в ответах.
2. Люди не знают, что им нужно, пока не увидят. Требование к тому, чего ещё нет, — не факт, а прогноз. Прогнозы людей о собственном будущем поведении систематически неточны.
3. Разные люди знают разное и противоречат друг другу. Причём не «один прав, другой врёт»: у финансов и у продаж реально разные правила про одну и ту же скидку, и оба описания верны в своём контуре.

Отсюда рабочее определение: выявление — это построение и проверка модели того, как устроена работа и как она должна быть устроена, из нескольких независимых источников. Не стенография. Аналитик, который просто записывает, что сказали, производит документ, но не производит знание — и первым узнаёт об этом на приёмке, разбор которой — в Приёмке.

Полезно сразу отделить эту работу от продуктового discovery. В Discovery: интервью, JTBD, проверка проблемы речь о том, существует ли проблема и стоит ли её решать. Здесь мы считаем, что решать уже решили, и выясняем, как устроена предметная область: шаги, роли, правила, исключения, данные, смежные системы. Техники частично общие, вопросы разные. Если продуктовое решение ещё не принято — начинать надо с discovery, иначе вы соберёте безупречно детальные требования к ненужной функции.

Что именно мы ищем: четыре слоя знания

Главная причина, по которой «поговорили с заказчиком» не работает, — знание лежит на разной глубине, и разные техники достают до разной.

Три следствия, которые экономят месяцы:

• Ни одна техника не самодостаточна. Интервью без наблюдения даёт идеализированный процесс; наблюдение без интервью — набор действий без объяснения «почему»; документы без данных — описание того, как должно быть, а не как есть.
• Слой 3 — источник большинства сюрпризов в разработке. Обходные пути (свой Excel, звонок вместо формы, двойной ввод) — это и есть настоящие требования, только не сформулированные.
• Слой 4 нельзя выяснить разговором. Про несуществующий экран люди отвечают вежливо и бесполезно. Он выявляется макетом — см. Прототипирование и Вайрфреймы и прототипы.

Выявление — это цикл, а не этап

В любом методологическом описании выявление стоит первым, и из этого делают ошибочный вывод, что его можно «закончить». Практически это цикл, который крутится всё время жизни фичи, просто с уменьшающейся амплитудой.

Два узла на этой схеме отличают профессиональную работу от любительской.

Узел «Проверка». Всё, что сказал один человек один раз, — гипотеза. Она становится фактом после подтверждения из независимого источника: другой человек, документ, данные в базе, наблюдение. Правило «два источника на каждое неочевидное правило» дешевле любого другого известного мне приёма.

Узел «Достаточно». Критерий остановки не «мы выяснили всё» (недостижимо), а: не осталось открытых вопросов, которые меняют ближайшее решение. Всё прочее оформляется как допущение с владельцем — техника из Управления рисками.

Планирование: что выяснять сейчас, а что подождёт

Времени экспертов всегда меньше, чем вопросов. Приоритет вопросов задаётся не любопытством, а произведением «неопределённость × цена ошибки».

Что делать в каждом квадранте:

• Дорого и непонятно — деньги, регуляторика, миграция данных, интеграции. Только явный разбор с владельцем правила, письменная фиксация, желательно с примерами-расчётами. Это же список архитектурно значимых требований, ср. материалы курса по архитектуре о требованиях.
• Дорого, но вроде понятно — самая опасная зона: «все знают» и никто не проверял. Тратьте время не на обсуждение, а на подтверждение документом или запросом к базе.
• Дешёво и понятно — решайте в чате или на доске, не пишите документ.
• Дешёво, но непонятно — не выясняйте разговором, это слой 4. Дешевле сделать вариант и посмотреть на поведение.

У кого спрашивать: минимальная карта источников

Прежде чем идти к людям, полезно проверить полноту списка. Дыры повторяются от проекта к проекту:

Ключевая проверка: не общаетесь ли вы только с прокси. Руководитель отдела рассказывает, как процесс задуман; оператор — как он идёт. Их описания расходятся всегда, и оба нужны. Конфликты интересов и правила согласования — тема Работы со стейкхолдерами.

Интервью

Интервью — основной инструмент для слоя 2 и единственный, который даёт «почему». И самый легко портящийся: разговор ощущается продуктивным даже когда не дал ничего.

Подготовка: 30 минут, которые определяют результат

• Одна цель на сессию. «Понять, как считается срок возврата и какие исключения» — цель. «Обсудить возвраты» — не цель, разговор растечётся.
• Прочитать документы и данные заранее. Вопросы, ответ на которые есть в регламенте или в базе, — прямой расход доверия эксперта. Хуже того, вам перескажут документ по памяти, с ошибками.
• Список вопросов, упорядоченный по важности. Реально задаёте половину; первыми должны идти вопросы из «дорогого» квадранта.
• Правильный человек. Спросите заранее: «кто чаще всех сталкивается с нестандартными случаями?» — обычно это не тот, кого вам назначили.
• 45–60 минут, не больше. После часа качество ответов падает, а ваша способность фиксировать — тем более.
• Договориться о записи. Аудио с разрешения даёт возможность слушать, а не стенографировать. Без разрешения — не записывайте: цена испорченного доверия выше пользы.

Каркас разговора на 45 минут

0:00  Рамка. Кто я, зачем встреча, что будет с результатом, сколько времени.
      «Я не проверяю вашу работу. Мне нужно понять, как всё устроено,
       чтобы система не мешала.»
0:03  Контекст человека. Роль, стаж, что делает в течение дня, чем меряют
      его результат. Это калибровка: сильные и слабые места ответов.
0:08  Открытый заход. «Расскажите, как проходит оформление возврата
      от момента, когда приходит заявка, и до момента, когда закрываете.»
      Не перебивать. Записывать термины его словами.
0:20  Воронка. Возвращаемся к точкам, где было «обычно», «как правило»,
      «ну там по-разному» — и раскапываем каждую.
0:32  Исключения и последний сбой. «Расскажите про последний случай,
      когда всё пошло не так.» «Как часто такое? Раз в день, в неделю?»
0:40  Проверка понимания. Пересказываю процесс своими словами,
      прошу поправить. Ошибки в пересказе — самый ценный момент встречи.
0:44  Закрытие. Что дальше, когда пришлю конспект, к кому идти
      за оставшимся, можно ли вернуться с уточнениями.

Типы вопросов и техника воронки

• Открытые («как проходит…», «что происходит после…») — для карты процесса. С них начинают.
• Закрытые («срок считается от даты вручения?») — для проверки конкретной гипотезы. Ими заканчивают, не начинают: закрытый вопрос в начале навязывает вашу модель.
• Воронка (funnel) — от общего к частному: процесс → шаг → правило → исключение → пример с конкретными числами. Уровень «пример с числами» обязателен: пока не прозвучали конкретные дата, сумма, статус — правило не выявлено, а пересказано.
• Лестница вверх (laddering up) — «а зачем этот шаг?», «что случится, если его не делать?» Ведёт от «хотелки» к цели. Инструмент против решений, выданных за требования.
• Лестница вниз (laddering down) — «а как именно вы это делаете?», «покажите на своём экране». Ведёт от абстракции к слою 3.
• Охота за контрпримером — «бывает так, что заявка приходит без номера заказа?» Ищем не подтверждение правила, а его нарушение: правило без известных исключений почти всегда означает, что исключения ещё не найдены.

Плохой вопрос и хороший вопрос

Это самая практичная таблица во всей статье. Левый столбец — то, что произносят почти все на первых интервью.

Отдельно: «почему» произносить осторожно. «Почему вы делаете двойной ввод?» звучит как обвинение и включает защиту. «Что заставляет вводить это дважды?» — тот же вопрос без адресата вины. Приём подробно разобран у Роба Фицпатрика в «The Mom Test»: спрашивайте про факты прошлого, а не про мнения о будущем.

Протокол интервью с обязательным подтверждением

Интервью не заканчивается в комнате. Не подтверждённый конспект — это ваша интерпретация чужих слов, и на приёмке она обычно оказывается неточной.

Три детали, которые чаще всего опускают:

• «Поправьте, где я ошибся» работает лучше, чем «подтвердите, всё ли верно». Первое просит найти ошибку — люди хорошо умеют находить ошибки в чужом тексте. Второе просит одобрить — люди хорошо умеют одобрять не читая.
• Конспект в тот же день. Через сутки вы помните тезисы, но теряете термины и оговорки, а именно в них живут исключения.
• Термины — словами эксперта. Если он говорит «отгрузка», не переименовывайте в «доставку»: вы потеряете различие, которое в домене может быть существенным. Расхождение терминов — повод для словаря данных, см. Моделирование данных.

Антипаттерны интервью

• Стенография. Записали дословно, не задали ни одного уточняющего вопроса. Результат: набор цитат, из которых нельзя вывести поведение системы.
• Интервью как приём заявок. Разговор сползает в перечисление пожеланий к интерфейсу. Возвращайте к задаче: «а какую проблему это решает для вас?»
• Демонстрация экспертизы. Аналитик говорит больше эксперта. Считайте грубо: ваша доля реплик выше 30% — сессия провалена.
• Групповое интервью вместо воркшопа. Пять человек в переговорке без фасилитации = говорит самый старший, остальные молчат и потом не выполняют договорённости.
• Опрос по списку. Двадцать вопросов подряд без реакции на ответы. Ответы будут короткими и бесполезными: человек чувствует анкету и отвечает как анкете.
• Вера в одно интервью. Один эксперт даёт свою половину домена. Тот же вопрос третьему человеку регулярно даёт третий ответ — и это находка, а не досада.

Наблюдение: единственный доступ к слою 3

Наблюдение (job shadowing, contextual inquiry, в лексике Lean — gemba walk, «идти туда, где делается работа») отвечает на вопрос, который в интервью не задать: что человек делает, не замечая этого.

Классический разрыв «слова против действий»:

Правила, без которых наблюдение превращается в вежливые посиделки:

1. Смотреть на реальную работу, а не на демонстрацию. «Покажите, как вы обычно делаете» даёт постановочную версию. Договоритесь наблюдать обычный поток и молчать.
2. Модель «мастер и подмастерье». Человек работает и комментирует вслух; вы задаёте уточнения только на паузах и не подсказываете, как «правильно».
3. Не помогать и не исправлять. Как только вы начали учить, поток кончился, начался тренинг.
4. Фиксировать время. Тайминг шагов превращает «неудобно» в измеримый аргумент для приоритизации.
5. Ловить обходные пути. Каждый Excel, стикер на мониторе, звонок вместо формы, копипаста между окнами — это невыполненное требование. Спросите: «что было бы, если бы этого файла не стало?»
6. Наблюдать разных людей. Новичок и опытный работают по-разному: у новичка виден регламент, у опытного — реальные правила и все срезанные углы.

Шаблон записи, который потом легко превращается в модель процесса:

Из этой таблички автоматически вытекают четыре требования: справочник лимитов внутри системы, статус «На согласовании», журнал согласований для аудита, отсутствие ручного копирования номера. Ни одно из них в интервью не прозвучало.

Где наблюдение не работает: редкие процессы (закрытие года, инцидент раз в квартал), распределённые процессы без единого рабочего места, а также ситуации, где ваше присутствие меняет поведение (эффект наблюдателя — при контроле качества особенно заметен). Для редких случаев работает разбор последнего случая по следам: тикеты, письма, логи, «покажите, как это выглядело в системе».

Работа с документами и данными: археология вместо доверия

Документы — самый дешёвый источник и самый обманчивый. Базовое правило:

Регламент описывает, как задумано. Данные описывают, как есть. Расхождение между ними — это и есть ваше поле работы.

Что стоит прочитать до первого интервью и что оттуда брать:

Проверка правила запросом: самый недооценённый приём

Любое утверждение о данных проверяется за пять минут и переворачивает разговор. Три канонических запроса, которые я задаю почти в каждом проекте:

-- 1. «У заказа всегда один получатель» — проверяем кардинальность.
--    Если находится хотя бы один заказ с двумя получателями, требование меняется.
select recipients_cnt, count(*) as orders
from (
    select o.id, count(distinct r.id) as recipients_cnt
    from orders o
    join recipients r on r.order_id = o.id
    group by o.id
) t
group by recipients_cnt
order by recipients_cnt desc;

-- 2. «Статусы у нас такие: новый, оплачен, отгружен, закрыт» — проверяем перечисление.
--    Регулярно обнаруживаются статусы-призраки из давних миграций и опечатки.
select status, count(*) as cnt, min(created_at) as first_seen, max(created_at) as last_seen
from orders
group by status
order by cnt desc;

-- 3. «Исключение бывает крайне редко» — переводим «редко» в проценты.
--    12% — это не исключение, а второй основной сценарий.
select
    count(*) filter (where paid_at < shipped_at) as normal_flow,
    count(*) filter (where paid_at is null and shipped_at is not null) as ship_before_pay,
    round(100.0 * count(*) filter (where paid_at is null and shipped_at is not null)
          / nullif(count(*), 0), 1) as ship_before_pay_pct
from orders
where created_at >= date '2026-01-01';

Что искать в данных систематически:

• Нарушения заявленных инвариантов — «дата закрытия всегда больше даты создания», «сумма строк равна сумме документа». Нарушения означают либо забытый сценарий, либо кривые данные, которые придётся мигрировать; и то и другое — требования.
• Реальные распределения — сколько позиций в заказе типично, а сколько в максимуме (это сразу нефункциональное требование, см. Нефункциональные требования).
• Мёртвые и обязательные-необязательные поля — поле обязательно по документации и пустое в 40% строк: значит, правило появилось позже, и вам нужен ответ, что делать со старыми данными.
• Дубли справочников — три записи «ООО Ромашка» с разными ИНН: за этим стоит процесс, который никто не описывал.

Приёмы поиска граничных значений и классов эквивалентности одинаковы у аналитика и тестировщика; готовый арсенал — в Тест-дизайне.

Воркшопы: когда решение должно родиться в комнате

Воркшоп дороже всех остальных техник (часы нескольких дорогих людей одновременно), поэтому у него узкое, но незаменимое применение: когда знание распределено между несколькими сторонами и/или когда нужно принять решение, которое ни одна сторона не может принять в одиночку.

Показания к воркшопу:

• процесс проходит через 3+ отдела, и каждый знает свой кусок;
• есть противоречие между стейкхолдерами, которое переписка не разрешает третью неделю;
• нужно синхронно договориться о терминах и границах системы;
• надо быстро развернуть карту сценариев или процесса «как есть» и «как надо».

Противопоказания: сбор фактов, который дешевле сделать интервью; ситуация, где решение уже принято и воркшоп нужен «для вовлечения» (участники это чувствуют мгновенно); отсутствие человека, который вправе решать.

Дизайн сессии

• Одна цель, сформулированная как результат. Не «обсудить процесс возвратов», а «согласовать схему процесса возврата до склада и список решений по расхождениям».
• Материалы заранее. Черновая схема «как есть» и список вопросов рассылаются за день. Не для утверждения — чтобы люди пришли с возражениями.
• Роли разделены. Фасилитатор ведёт процесс и не спорит по сути; писарь фиксирует; аналитик задаёт вопросы по содержанию. Совмещать фасилитацию и содержание можно, но качество обоих падает; на конфликтных сессиях лучше не совмещать.
• Техники против «побеждает самый громкий»: сначала молча на стикеры (brainwriting), потом группировка, потом голосование точками. Это единственный дешёвый способ услышать младших участников, когда в комнате есть начальник.
• Три стены. «Как есть» — модель. «Вопросы» — всё, на что нет ответа в комнате, каждый с владельцем и сроком. «Решено» — решения с автором и датой.
• Таймбокс и парковка. Спор дольше 5 минут без нового аргумента — на стену вопросов с владельцем. Иначе одна ветка съест сессию.
• Сухой остаток вслух. Последние 10 минут: писарь зачитывает решения и вопросы. Половина «недопониманий» вылезает именно здесь.

Полезные форматы внутри воркшопа: событийный штурм (event storming) — выкладываем события домена по времени, находим пробелы и роли; карта историй (story mapping) — раскладываем сценарий по шагам и слоям релизов; «как есть / как надо» на одной стене — видно, какие шаги исчезают, а какие остаются ручными. Модель процесса, полученная на стене, потом перерисовывается набело в нотации — см. Моделирование процессов.

Антипаттерны воркшопа

• Нет решения — нет воркшопа. Три часа обсуждений без записанных решений и владельцев вопросов = потраченные деньги. Это главная проверка.
• HiPPO-режим (highest paid person’s opinion): руководитель высказывается первым, дискуссия закончилась. Лечится молчаливым сбором и правилом «начальник говорит последним».
• Слишком много людей. Больше 8–9 участников — уже не рабочая сессия, а совещание. Разбивайте по подпроцессам.
• Фасилитатор с мнением. Если ведущий продвигает вариант, участники начинают торговаться с ведущим, а не искать решение.
• Схема, нарисованная заранее и «согласованная». Люди правят чужую схему хуже, чем строят свою; целиком готовая картинка убивает вклад.

Практика фасилитации и работы с конфликтом в команде разбирается в Команде и коммуникации.

Остальные техники: что берут и чем платят

Комбинация, которая закрывает почти любой корпоративный кейс за 1–2 недели: документы и данные (день) → 3–5 интервью с разными ролями (2–3 дня) → наблюдение за 2 операторами (день) → воркшоп на спорные места (полдня) → прототип на неочевидный интерфейс (2–3 дня).

Фиксация: четыре ведра и один журнал

Самая частая техническая ошибка новичка — писать всё в один конспект. Через две недели невозможно понять, что было фактом, что вашей догадкой, а что чьим-то пожеланием. Разделяйте на входе:

1. Факт — как есть сейчас, с источником: кто сказал / где увидел / какой запрос показал.
2. Кандидат в требование — как должно быть. Ещё не согласовано, ещё не проверяемо.
3. Открытый вопрос — чего не знаем. Обязательно: владелец и срок ответа.
4. Решение — что выбрали, кто выбрал, когда, что это меняет в объёме.

Минимальный машинно-читаемый формат журнала (годится и как файл в репозитории, и как таблица):

# elicitation-log.yaml — журнал выявления по фиче «Возврат по маркетплейсу»
- id: F-014
  kind: fact                      # факт «как есть»
  statement: "Срок возврата считается от даты вручения, а не от даты заказа"
  source:
    who: "Иванова, руководитель клиентского сервиса"
    when: 2026-07-02
    how: interview
  confirmed_by:                   # правило неочевидное => обязателен второй источник
    - "Регламент КС-12, п. 4.3 (ред. 2025-11)"
    - "SQL: 0 заявок с deadline от created_at за 6 мес"
  affects: [BR-07, US-31]

- id: F-015
  kind: fact
  statement: "Для маркетплейсных заказов срок 30 дней, правило задано договором площадки"
  source: { who: "Петров, юрист", when: 2026-07-03, how: document_analysis }
  conflicts_with: F-014           # не «противоречие», а разные контуры: нужен явный признак
  resolved_by: D-003

- id: Q-021
  kind: open_question
  statement: "Что делать, если товар вручён курьером без отметки о дате вручения?"
  owner: "Иванова"                # без владельца вопрос не существует
  due: 2026-07-09
  blocks: [US-31]
  workaround_if_unanswered: "Считаем от даты последнего статуса трекинга; допущение A-005"

- id: D-003
  kind: decision
  statement: "Срок хранится в заявке как значение, источник срока — тип канала продаж"
  decided_by: "Сидоров, владелец продукта"
  decided_at: 2026-07-04
  scope_impact: "+ справочник каналов, + миграция исторических заявок"

Почему это стоит усилий: у каждого требования должен быть прослеживаемый источник. Через три месяца кто-то спросит «а почему 14 дней?» — и без журнала начнётся новый круг выявления. Модель трассировки минимальна и хорошо ложится в таблицы трекера:

Открытый вопрос — сущность с жизненным циклом, и большинство проектных провалов видно именно в его статистике: вопросы копятся, никто не владеет, ответы приходят после разработки.

Переход Assumed --> Answered — самый недооценённый: если ответ разошёлся с допущением, а код уже написан по допущению, это не «внезапное изменение требований», а закономерный результат. Поэтому у каждого допущения должна быть пометка «что переделываем, если окажется иначе».

Проверка: как убедиться, что вы не выдумали требование

Пять приёмов по возрастанию силы:

1. Пересказ обратно (playback). Своими словами, эксперт поправляет. Ловит 80% недопониманий за 5 минут.
2. Пример с конкретными числами. «Заказ на 12 000, доставлен 3 марта, возврат оформлен 17 марта — принимаем?» Абстрактные формулировки согласуют легко, конкретные — только правильно. Систематизация этого приёма — Specification by Example, ср. TDD и BDD.
3. Контрпример. «А если товар вручён, но чек не выдан?» Ищите случай, который ломает формулировку. Если не находите — вы недостаточно старались.
4. Проверка данными. Правило либо подтверждается в базе, либо у вас появилась дырка.
5. Три пары глаз. Разработчик смотрит на реализуемость, тестировщик — на проверяемость, эксперт — на соответствие домену. Три разных класса дыр находятся тремя разными людьми.

Быстрый фильтр «это требование или ещё нет» — три вопроса:

• Кто источник и подтверждено ли это вторым источником?
• Как мы проверим выполнение (кто и что нажмёт, какой результат ждём)?
• Какую задачу или цель это закрывает?

Нет ответа на любой из трёх — это пока факт, пожелание или вопрос, но не требование. Форматы записи — в Документировании, классификация уровней — в Видах требований.

Что ломается чаще всего

1. Неявные требования: «ну это же очевидно»

Симптом: на демо звучит «а куда делся расчёт с учётом скидки, мы же всегда так считаем». Причина: правило существует только в чьей-то голове, а вы его не спросили, потому что не знали, что оно есть.

Работающие приёмы:

• Проверять исключения на каждом шаге: «а бывает, что этого нет / приходит дважды / приходит с опозданием / приходит от другой стороны?»
• Крайние значения. Ноль, один, максимум, отрицательное, дубль, отмена после отмены. Каждое часто вытаскивает правило.
• Разбор последнего сбоя. Инциденты — концентрат неявных правил.
• Наблюдение вместо расспросов. Обходной путь виден глазами и не виден в ответах.
• Данные. Правило, действующее в базе, проступит в распределениях, даже если про него забыли.

2. Противоречия между стейкхолдерами

Симптом: два ответа на один вопрос, оба уверенные. Опасность не в самом противоречии, а в том, что аналитик берёт последнее услышанное, и решение принимается по случайному признаку.

Что делать:

• Не «усреднять» и не решать самому. Ваша задача — сделать противоречие видимым, а не выбрать красивее.
• Проверить, не разные ли это контуры. Часто оба правы: в рознице 14 дней, на маркетплейсе 30. Тогда «противоречие» — это пропущенный признак-различитель (тип канала, регион, сегмент).
• Оформить как выбор с ценой. Таблица: вариант A / вариант B, что получает каждая сторона, что стоит в разработке, что ломается. Решение принимает владелец решения, не самый громкий.
• Записать решение с автором и датой. Без этого через месяц спор повторится с нуля.

3. «Хотелки» без задачи

Симптом: «нужна кнопка выгрузки в Excel», «нужен дашборд», «сделайте как в другой системе». Это решения, поданные как требования, и в них уже вшито чужое проектирование.

Приём — лестница вверх, три шага:

— Нужна выгрузка заказов в Excel.
— Что вы делаете с файлом после выгрузки?
— Считаю в сводной сумму по регионам и отправляю руководителю в пятницу.
— Что произойдёт, если письмо не отправить?
— Не увидим просадку по региону до конца месяца.

Настоящее требование — «региональный менеджер видит недельную динамику в понедельник утром». Выгрузка в Excel — один из способов, и обычно не лучший. Дальше приоритизация по ценности, инструменты — в Приоритизации.

Обратная ошибка тоже существует: не всякая просьба нуждается в раскопках. Если человек просит переименовать колонку, лестница вверх выглядит как издевательство. Раскапывать стоит то, что дорого, и то, что тянет за собой архитектуру.

4. Требования, которые невозможно проверить

Симптом: «должно быть удобно», «работать быстро», «интуитивно понятно», «не должно ломаться». Формально согласовано, фактически несогласуемо — принять такое нельзя, оспорить тоже.

Единственный надёжный вопрос: «как мы узнаем, что это выполнено?» Дальше — перевод:

Способы измерения качества — в Нефункциональных требованиях, проверка на людях — в Юзабилити-тестировании.

5. Выявление у прокси вместо реального исполнителя

Руководитель искренне описывает процесс, которым не занимается два года. Полученная модель описывает регламент, а не работу. Лечение простое и почти всегда доступное: полчаса рядом с оператором. Одно наблюдение обычно опровергает 2–3 пункта «согласованного» описания.

6. Ложная полнота

Симптом: «требования собраны» после трёх встреч и документа на 40 страниц. Объём документа маскирует дыры: описаны основные сценарии, отсутствуют исключения, ошибки, ручные шаги, поведение при отказе смежных систем, миграция старых данных, права доступа.

Дешёвая страховка — чек-лист покрытия по каждому сценарию:

• альтернативные ветки и отказы (кто-то не подтвердил, лимит превышен, срок истёк);
• поведение при недоступности смежной системы и при повторном запросе;
• права: кто видит, кто меняет, кто согласует;
• отмена и откат: можно ли отменить, кто, до какого момента, что с деньгами;
• исторические данные: что делать с записями, созданными до нового правила;
• отчётность: кто и как узнает, что процесс работает;
• ручные шаги, которые остаются вне системы, и их владельцы.

Формальный документ или разговор у доски

Формальность выбирается не по вкусу, а по цене ошибки и числу сторон. Для техник выявления это выглядит так:

Три правила, которые снимают большинство споров про «нужен ли документ»:

1. Фиксируется не разговор, а решение. Тридцать страниц конспекта хуже пяти строк «решили так, решил такой-то, тогда-то, меняет вот это».
2. Стоимость документа сравнивается со стоимостью ошибки. Обратимая ошибка на день работы не оправдывает двух дней согласований.
3. Артефакт живёт, пока влияет на решения. Заброшенный протокол опаснее отсутствующего: по нему принимают решения, считая его актуальным.

Мини-итог

• Требования не собирают, а выявляют: люди не знают всего, что знают, не знают, чего хотят от несуществующего, и противоречат друг другу — это норма, а не патология проекта.
• Знание лежит на четырёх слоях. Документы дают записанное, интервью — осознаваемое, наблюдение и данные — автоматическое, прототип — реакцию на то, чего ещё нет. Комбинация обязательна.
• Интервью: одна цель, подготовка по документам, открытый заход, воронка до примера с числами, охота за исключениями, пересказ обратно, конспект в тот же день с просьбой «найдите ошибку».
• Наблюдение — единственный доступ к обходным путям, а обходной путь — это невыполненное требование в чистом виде.
• Документы описывают «как задумано», данные — «как есть». Три SQL-запроса (кардинальность, реальные перечисления, частота «исключений») экономят недели споров.
• Воркшоп нужен, когда знание распределено и требуется решение в комнате. Нет записанных решений с авторами и датами — воркшопа не было.
• Фиксируйте в четыре ведра: факт, кандидат в требование, открытый вопрос (владелец + срок), решение. У каждого требования — прослеживаемый источник.
• Критерий остановки — не «выяснили всё», а «не осталось вопросов, влияющих на ближайшее решение»; остальное оформляется допущениями с явной ценой.

Источники

• IIBA, BABOK Guide v3, раздел Elicitation and Collaboration — iiba.org.
• Karl Wiegers, Joy Beatty. Software Requirements, 3rd ed. — главы про elicitation и про «требования, которые нельзя проверить» — karlwiegers.com.
• Suzanne & James Robertson. Mastering the Requirements Process; шаблон и «требование-раковина» Volere — volere.org.
• Donald Gause, Gerald Weinberg. Exploring Requirements: Quality Before Design — leanpub.com/exploringrequirements (классика про неоднозначность формулировок и про вопросы к контексту).
• Rob Fitzpatrick. The Mom Test — momtestbook.com (как спрашивать про факты прошлого вместо мнений о будущем).
• Steve Portigal. Interviewing Users — portigal.com/books (техника ведения интервью, работа с молчанием и уточнениями).
• Hugh Beyer, Karen Holtzblatt. Contextual Design — модель «мастер и подмастерье»; обзор техники контекстного исследования: interaction-design.org.
• Ellen Gottesdiener. Requirements by Collaboration; Discover to Deliver — ebgconsulting.com (дизайн требовательных воркшопов).
• Alberto Brandolini. EventStorming — eventstorming.com.
• Gojko Adzic. Specification by Example — gojko.net (примеры с числами как способ согласования).
• Indi Young. Practical Empathy — indiyoung.com (слушать, не подсказывая ответ).
• ISO/IEC/IEEE 29148:2018, Requirements engineering — iso.org/standard/72089.html (характеристики хорошего требования, в том числе проверяемость и трассируемость).

Что дальше

Мы добыли сырьё: факты, кандидатов в требования, открытые вопросы и решения. Дальше сырьё надо разложить по уровням — иначе бизнес-цель, задача пользователя, поведение системы и ограничение качества смешаются в одном абзаце, и спорить о них будут одновременно.

Виды требований: бизнес, пользовательские, функциональные, нефункциональные