Прототипирование и проверка гипотез до разработки

Самая дорогая строка в бэклоге — та, про которую все уверены, что она понятна. Её оценили, взяли в спринт, сделали за три недели, выкатили — и выяснили, что операторы поддержки этой кнопкой не пользуются, потому что по регламенту они обязаны сначала позвонить клиенту. Требование было записано, согласовано, покрыто тестами и полностью бесполезно.

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

Эта статья — про аналитическую часть работы. Дизайнерскую сторону — сетки, вайрфреймы, состояния экрана, инструменты — разбирает вайрфреймы и прототипы; продуктовую сторону — статистику экспериментов, A/B и MVP — MVP и эксперименты. Здесь — как проверка гипотез встраивается в работу с требованиями: что она находит, как оформляется результат и куда он девается потом.

1. Зачем аналитику прототип: он ловит те же четыре поломки

В обзоре трека мы выделили четыре класса поломок в требованиях. Прототип бьёт по каждому из них, и это главная причина им заниматься.

1.1. Неявные требования: прототип нельзя нарисовать наполовину

Текст требования умеет быть неполным незаметно. «Пользователь видит список своих заявок» — предложение выглядит законченным. Как только вы рисуете этот список, приходится ответить: что видно, когда заявок ноль; что при 4000 заявок; что при ошибке загрузки; что видит сотрудник поддержки, открывший чужой список; какие колонки, в каком порядке сортировка, где даты. Прототип — форма, которая не терпит пустых мест. Каждое пустое место превращается в вопрос, и это самый дешёвый в индустрии генератор неявных требований.

1.2. Противоречия стейкхолдеров: текст читают по-разному, картинку — одинаково

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

1.3. «Хотелка» без задачи: прототип требует сценария

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

1.4. Непроверяемые требования: прототип даёт им единицу измерения

«Интерфейс должен быть удобным» непроверяемо. Но на прототипе можно измерить конкретно: «четыре из пяти операторов оформляют возврат без подсказок за время не больше 90 секунд, не более одной ошибки на сценарий». Это уже критерий, который можно проверить дважды и получить тот же ответ. Так расплывчатое пожелание превращается в нефункциональное требование с методом проверки.

1.5. Ловушка: прототип ничего не доказывает

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

Про экономику раннего обнаружения обычно цитируют «ошибка в требованиях стоит в 100 раз дороже на проде». Относитесь к числу осторожно: происхождение этих коэффициентов подробно разобрано у Лорана Боссави в The Leprechauns of Software Engineering — это индустриальный фольклор, а не измеренный закон. Направление, впрочем, верное и без цифры: переделать схему на доске стоит полчаса, переделать выкаченную интеграцию с внешним банком — недели и переговоры. Чем позже вы узнаёте, тем больше уже построено поверх ошибки.

2. Гипотеза как единица работы

2.1. Формулировка

Гипотеза — это утверждение, которое можно опровергнуть заранее заданным наблюдением. Рабочий шаблон:

Мы считаем, что <изменение>
для <кто именно, какой сегмент>
приведёт к <наблюдаемый эффект>.
Мы признаем гипотезу опровергнутой, если <конкретное наблюдение / порог метрики>.
Проверим это <метод> за <срок и бюджет>, решение принимаем <дата>.

Разбор на живом примере.

Ключевая часть — условие опровержения, записанное до проверки. Если критерий формулируется после того, как вы посмотрели результат, вы не проверяли гипотезу, вы её иллюстрировали.

2.2. Четыре риска и кто ими владеет

Марти Каган в Inspired делит риски новой функциональности на четыре вида. Разделение полезно аналитику практически: оно показывает, какой риск вы обязаны снять сами, а какой — не ваш.

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

2.3. Что проверять первым

Проверять всё подряд — способ потратить месяц до старта. Порядок задаёт простое правило: первым проверяется предположение, которое дороже всего ошибиться и дешевле всего проверить. В литературе это называют RAT — riskiest assumption test (термин популяризировал Рик Хайэм, статья).

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

3. Лестница точности: чем платят за каждый следующий ответ

Fidelity («точность» прототипа) — не одна шкала, а несколько независимых:

• визуальная: скетч → вайрфрейм → пиксель-перфект;
• функциональная: статичная картинка → кликабельные переходы → работающая логика;
• содержательная: «Lorem ipsum» → правдоподобные данные → выгрузка из прода;
• охват: один счастливый путь → альтернативы → ошибки и краевые случаи.

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

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

Разные способы проверки закрывают разные слои системы, и путаница здесь стоит дорого: команда две недели полирует кликабельный прототип, а падает всё потом на объёме данных, который этот прототип в принципе не мог показать.

4. Каталог методов: что проверяет, о чём врёт, сколько стоит

4.1. Разговор и схема на доске

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

Формат, который стоит завести: walkthrough по кейсу. Не «согласуем схему», а «возьмём заявку №4417 из прошлой недели и пройдём по схеме, шаг за шагом, что произошло». Три реальных кейса на схему находят больше дыр, чем час обсуждения в общем виде.

4.2. Бумажный прототип / скетч экрана

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

О чём врёт: ничего не говорит о том, найдёт ли человек нужный элемент в реальном интерфейсе.

4.3. Кликабельный прототип

Связанные экраны с переходами (Figma, Axure, Balsamiq — инструмент вторичен). Проверяет последовательность шагов, формулировки, понятность статусов. Для аналитика важны две вещи: класть в прототип настоящие тексты (названия статусов из системы, реальные ошибки от API) и обязательно провести хотя бы один несчастливый путь.

О чём врёт: скорость, объёмы, права доступа, поведение при отказе интеграции. Всё, что за пределами картинки.

4.4. Прототип по данным: самый недооценённый

Это чисто аналитический инструмент, и он окупается чаще всех остальных. Прежде чем обсуждать, как работает автоматическое правило, проверьте по данным, применимо ли оно вообще.

-- Гипотеза: большинство возвратов можно закрывать автоматически.
-- Считаем, какая доля заявок за квартал удовлетворяет всем условиям автовозврата.
WITH claims AS (
    SELECT r.id,
           r.amount,
           r.reason_code,
           r.created_at,
           o.paid_at,
           o.delivered_at,
           o.payment_method,
           -- заявка пришла в срок 14 дней от вручения
           (r.created_at <= o.delivered_at + INTERVAL '14 days') AS in_window,
           -- оплата картой: возврат тем же способом технически возможен
           (o.payment_method = 'card') AS refundable_channel,
           -- сумма ниже порога ручной проверки
           (r.amount <= 3000) AS small_amount,
           -- причина не требует экспертизы товара
           (r.reason_code IN ('changed_mind', 'wrong_size')) AS no_inspection
    FROM refund_requests r
    JOIN orders o ON o.id = r.order_id
    WHERE r.created_at >= date_trunc('quarter', now()) - INTERVAL '3 months'
)
SELECT count(*)                                                     AS total,
       count(*) FILTER (WHERE in_window)                            AS ok_window,
       count(*) FILTER (WHERE refundable_channel)                   AS ok_channel,
       count(*) FILTER (WHERE small_amount)                         AS ok_amount,
       count(*) FILTER (WHERE no_inspection)                        AS ok_reason,
       count(*) FILTER (WHERE in_window AND refundable_channel
                          AND small_amount AND no_inspection)       AS fully_auto
FROM claims;

Результат такого запроса меняет разговор радикально:

Автоматизировать удастся 19% заявок, а не «почти все», как звучало на встрече. Причём главный ограничитель — не сумма, а способ оплаты: 38% возвратов приходят по заказам, оплаченным наложенным платежом и через СБП, где «вернуть тем же способом» не работает без реквизитов. Это неявное требование, которое всплыло за два часа и изменило и оценку, и приоритет фичи.

Три вопроса, которые аналитик задаёт данным перед любой автоматизацией:

1. Как часто вообще случается сценарий? (Может, ноль раз за год.)
2. Есть ли в данных признак, по которому правило вообще различает случаи? (Если брак и «передумал» приходят одним кодом — правило неосуществимо.)
3. Каков хвост распределения? (Средний заказ — 3 позиции, максимум — 1840; экран и выгрузка должны пережить максимум.)

Разбор структуры данных — в моделировании данных.

4.5. Таблица решений как прототип логики

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

Прогон по выгрузке проверяет две вещи: покрытие (все ли реальные заявки попали хоть в одно правило) и пересечения (не попала ли заявка в два конфликтующих правила).

from datetime import timedelta

# Правило: (предикат, имя решения). Порядок важен — первое сработавшее выигрывает,
# но для проверки мы намеренно собираем ВСЕ сработавшие, чтобы увидеть пересечения.
RULES = [
    (lambda c: c["reason"] in ("changed_mind", "wrong_size")
               and c["amount"] <= 3000 and c["method"] == "card" and c["in_window"],
     "auto_refund"),
    (lambda c: c["reason"] in ("changed_mind", "wrong_size")
               and c["amount"] > 3000 and c["method"] == "card" and c["in_window"],
     "manual_review"),
    (lambda c: c["reason"] == "defect" and c["in_window"], "warehouse_check"),
    (lambda c: c["method"] in ("sbp", "cash") and c["in_window"], "ask_bank_details"),
    (lambda c: not c["in_window"], "reject_expired"),
]


def audit(claims):
    """Прогон таблицы решений по историческим заявкам.
    Возвращает (покрытие по решениям, непокрытые заявки, конфликтующие заявки)."""
    coverage, uncovered, conflicts = {}, [], []
    for c in claims:
        hits = [name for pred, name in RULES if pred(c)]
        if not hits:                      # ни одно правило не сработало — дыра в логике
            uncovered.append(c["id"])
        if len(hits) > 1:                 # сработало несколько — нужен явный приоритет
            conflicts.append((c["id"], hits))
        for name in hits:
            coverage[name] = coverage.get(name, 0) + 1
    return coverage, uncovered, conflicts

# Сложность: O(n * r) по времени (n заявок, r правил), O(r + k) по памяти,
# где k — число найденных проблемных заявок. На 8412 заявках и 5 правилах — доли секунды.

Реальный результат такого прогона почти всегда: 40–200 непокрытых заявок (частичный возврат, заказ с промокодом, возврат подарочной карты) и десятки конфликтов на строках 3 и 4 — брак, оплаченный через СБП. Каждая такая находка — требование, которое иначе всплыло бы на тестировании. Формальный стандарт для таких таблиц — DMN (OMG, спецификация); он же даёт готовые политики разрешения конфликтов (unique, first, priority).

4.6. Мок контракта API

Если фича живёт на интеграции, самый ценный прототип — не экран, а контракт. Пишете фрагмент OpenAPI, поднимаете мок-сервер и прогоняете сценарий обмена ещё до того, как кто-то начал разработку.

# refund-api.yaml — черновик контракта, поднимается моком за пять минут:
#   prism mock refund-api.yaml
openapi: 3.1.0
info: { title: Refund API (черновик для проверки гипотезы), version: 0.1.0 }
paths:
  /refunds:
    post:
      summary: Создать возврат по заявке
      parameters:
        - name: Idempotency-Key           # повтор запроса не должен вернуть деньги дважды
          in: header
          required: true
          schema: { type: string, format: uuid }
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [claim_id, amount_minor, currency, method]
              properties:
                claim_id:     { type: string, format: uuid }
                amount_minor: { type: integer, minimum: 1 }   # копейки, не рубли
                currency:     { type: string, enum: [RUB] }
                method:       { type: string, enum: [card, sbp, manual] }
                bank_details: { type: object, nullable: true } # обязателен при sbp/manual
      responses:
        "202": { description: Возврат принят в обработку, статус придёт вебхуком }
        "409": { description: Возврат по этой заявке уже создан }
        "422": { description: Способ возврата недоступен для заказа }

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

Четыре вопроса на одном прогоне мока — типичный улов. Каждый из них превращается в требование: статус «в обработке», SLA с таймаутом, правило обработки повтора, сценарий отложенного отказа. Подробно про контракты — в анализе интеграций и API, про тестирование контрактов — в тестировании API.

Инструменты: Prism (мок по OpenAPI одной командой), WireMock, моки в Postman. Затраты — часы, находки — недели.

4.7. Wizard of Oz и concierge

Пользователь думает, что работает автоматика, а внутри сидит человек и делает работу руками. Метод старый и уважаемый: так в IBM в 1983-м проверяли распознавание речи (Дж. Ф. Келли, «An iterative design methodology…»).

Когда применять аналитику: логика дорогая, а спрос неясен. Автовозврат можно неделю выполнять вручную по правилам из таблицы решений — и это одновременно проверит спрос, полноту правил и даст реальный лог решений. Concierge — честная версия: клиент знает, что с ним работает человек.

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

4.8. Fake door: осторожно

Кнопка, которая ведёт на «скоро будет», меряет спрос. Аналитику стоит помнить о двух вещах. Во-первых, этика: обманывать платящих клиентов и корпоративных пользователей нельзя — это стоит доверия дороже, чем стоит инсайт. Приемлемая форма — честное «функция в разработке, оставьте адрес, позовём первыми». Во-вторых, интерпретация: клик по кнопке измеряет интерес к формулировке, а не готовность пользоваться. Это сигнал для приоритизации, а не основание для требований.

4.9. Спайк и PoC: как аналитик ставит вопрос разработчику

Спайк — из XP: короткая техническая проверка с жёстким таймбоксом. Аналитик тут не пишет код, но обязан правильно поставить задачу, иначе спайк превращается в бесконечное исследование.

Формулировка спайка должна содержать четыре вещи:

1. Вопрос, у которого есть ответ «да/нет»: «можно ли через API банка сделать частичный возврат по заказу, оплаченному СБП?»
2. Таймбокс: 3 дня, не «пока не разберёмся».
3. Что считается ответом: успешный вызов в песочнице с логом или письменный отказ с указанием пункта документации.
4. Что будет с кодом: выбрасывается. Спайк — не начало реализации.

Итог спайка — не «мы посмотрели», а запись в реестр гипотез: подтверждено / опровергнуто / не хватило времени, и что решаем дальше.

4.10. Как выбрать метод

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

5. Разбор: «сделайте автовозврат в один клик»

Запрос пришёл от руководителя поддержки, звучит как решение, а не как задача. Полный прогон.

Шаг 1. Восстановить задачу. Пять вопросов, каждый — про проблему, а не про кнопку: что сейчас происходит без этой кнопки; сколько времени это занимает; сколько таких случаев в неделю; что случается плохого; почему именно сейчас. Ответы: 8400 заявок в квартал, средняя обработка 26 минут, очередь в конце месяца до трёх дней, жалобы клиентов и штрафы по закону о защите прав потребителей за просрочку возврата.

Шаг 2. Выписать предположения, скрытые в запросе.

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

Шаг 3. Разложить по риску и стоимости проверки (это и есть quadrantChart из раздела 2.3). Первыми идут «данных для решения нет» и «регламент запрещает» — дёшево и смертельно.

Шаг 4. Проверить.

• Регламент: полчаса чтения внутреннего документа плюс десять минут с юристом. Результат: звонок обязателен только при сумме свыше 20 000 руб. Первое предположение выжило частично.
• Данные: SQL из раздела 4.4. Результат: 19% заявок пригодны, ограничитель — способ оплаты.
• Контракт банка: прогон мока и чтение документации. Результат: частичный возврат по СБП требует реквизитов от клиента — это отдельный сценарий с ожиданием ответа.
• Прототип экрана: сеанс с тремя операторами. Результат: главный страх — «автомат вернёт деньги мошеннику, а спросят с меня». Требование, которого не было в запросе: журнал решений автомата и возможность оператора отменить решение в течение часа.

Шаг 5. Переписать требование. Из «автовозврат в один клик» получилось:

• автоматическое решение только для карточных оплат, суммы до 3000 руб., причин «передумал»/«не подошёл размер», в пределах 14 дней от вручения (19% потока);
• для СБП и наличных — сценарий запроса реквизитов с ожиданием и напоминанием;
• журнал решений с указанием сработавшего правила и кнопкой отмены (окно 60 минут);
• SLA: деньги отправлены не позже 30 минут после решения, статус виден оператору;
• метрика успеха: доля заявок, закрытых без участия человека, не ниже 15% через месяц.

Сравните с исходной формулировкой. Три дня проверок против трёх недель разработки не того. Оформление такого результата в user story и критерии приёмки — в документировании, проверка результата на приёмке — в приёмке.

6. Сеанс проверки: протокол, который работает

Половина неудачных прототипов проваливается не из-за прототипа, а из-за того, как его показывали. Демонстрация — не проверка.

Что делать нельзя:

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

Что делать нужно: дать задание в терминах пользователя и молчать.

Протокол сеанса (20–30 минут, один участник)

0. Цель сеанса (для себя, не озвучивается):
   проверить, что оператор находит и понимает механизм отмены автоматического решения.
   Опровергнуто, если 2 из 5 участников не находят отмену за 60 секунд.

1. Разогрев (3 мин): чем занимаетесь, как выглядит обычный день, сколько заявок за смену.
2. Дисклеймер: мы проверяем макет, а не вас; ошибки в макете — то, что нам нужно.
   Думайте вслух.
3. Задание 1: «Пришла заявка на возврат 1200 руб. Оформите её так, как сделали бы сегодня».
4. Наблюдение: где остановился, что произнёс вслух, куда кликнул первым, что перечитал дважды.
   Не помогать до 60 секунд молчания.
5. Задание 2: «Вы поняли, что решение принято ошибочно. Ваши действия».
6. Вопросы после (не «нравится?», а): что здесь произойдёт после нажатия?
   как вы поймёте, что деньги ушли? чего здесь не хватает по сравнению с вашей работой?
7. Фиксация: три главных наблюдения, дословные цитаты, вердикт по критерию из п.0.

Про число участников: широко известное «пяти достаточно» идёт из работы Якоба Нильсена и Тома Ландауэра 1993 года (nngroup.com). Оговорка важна: пять — на один однородный сегмент и один сценарий. Если у вас операторы первой линии и юристы — это два сегмента, и пять на каждый. И это работает для поиска проблем удобства, но не для оценки величины эффекта: там нужны выборки и статистика, см. аналитику и решения.

Техника наблюдения и опроса — общая с интервью, детально в выявлении требований; проведение полноценных юзабилити-сессий — в юзабилити-тестировании.

7. Из прототипа в требования: трассировка и жизненный цикл

7.1. Прототип — не спецификация

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

Правило: прототип фиксирует то, что проверили; всё остальное фиксируется текстом. Прототип живёт как приложение к требованию со ссылкой на конкретную версию макета, а не вместо требования.

7.2. Жизненный цикл гипотезы

Ключевой переход — testing --> refuted. Опровергнутая гипотеза не провал, а сэкономленные недели; команды, где опровержение считается неудачей аналитика, быстро перестают проверять что-либо всерьёз.

7.3. Реестр гипотез и трассировка

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

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

- id: H-14
  goal: сократить время обработки возврата в первой линии
  assumption: решение о возврате можно принять по данным заявки, без человека
  risk: высокий — на этом построена вся оценка фичи (3 спринта)
  falsifier: доля заявок, пригодных к автоматическому решению, ниже 30%
  method: sql
  timebox: 4 часа
  run_at: 2026-07-14
  result: refuted
  finding: пригодны 19%; ограничитель — способ оплаты (СБП и наличные — 38% потока)
  decision: автоматизируем только карточные оплаты; для СБП — сценарий запроса реквизитов
  artifacts:
    - queries/refund_auto_coverage.sql
    - wiki/RA-118 протокол обсуждения с юристом
  requirements: [REQ-231, REQ-232, NFR-17]

7.4. Как результат меняет критерии приёмки

До проверки:

Система автоматически возвращает деньги по заявке. Критерий: заявка закрыта, деньги возвращены.

После проверки:

• Если причина ∈ {передумал, не подошёл размер}, сумма ≤ 3000 руб., оплата картой, заявка создана не позже 14 дней от даты вручения — система создаёт возврат без участия оператора и записывает в журнал сработавшее правило.
• Если оплата СБП или наличными — система создаёт заявку на реквизиты и напоминает клиенту через 24 и 72 часа; по истечении 7 дней заявка уходит оператору.
• Оператор может отменить автоматическое решение в течение 60 минут; после отмены заявка возвращается в очередь ручной обработки со статусом «отменено оператором».
• Возврат считается отправленным, когда получен ответ 202 от платёжного сервиса; итоговый статус приходит вебхуком, срок ожидания — до 72 часов, после чего заявка попадает в отчёт «зависшие возвраты».
• При повторном создании возврата с тем же ключом идемпотентности система показывает оператору существующий возврат, а не ошибку.

Второй вариант написан не потому, что аналитик умнее, а потому что каждый пункт добыт конкретной проверкой: SQL, регламент, мок, сеанс с операторами.

8. Где нужен формальный документ, а где хватит доски

Прототипирование не отменяет документов — оно меняет их объём. Ориентиры:

Практическое правило: рисуйте на доске, фиксируйте письменно решение. Фото схемы в чате — не документация: через три недели никто не восстановит, почему стрелка идёт туда. Три строки в задаче («решили X, потому что проверка H-14 показала Y, альтернатива Z отклонена из-за W») стоят пяти минут и экономят повторное согласование. Подробнее о выборе уровня формальности — в UML для аналитика и документировании.

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

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

1. Демо вместо проверки. Прототип показывают и рассказывают, как всё будет здорово. Признак: говорит аналитик, а не участник. Лечится заданием и молчанием.
2. Критерий успеха придуман после результата. Тогда любой исход подтверждает гипотезу. Пишите условие опровержения до сеанса, в задаче, при свидетелях.
3. Фальшивые данные. Три заказа в списке, суммы «1000», имена «Тест Тестов». Такой прототип систематически прячет требования к фильтрам, сортировке, пагинации, длинным строкам и деньгам с копейками. Берите анонимизированную выгрузку.
4. Только счастливый путь. Прототип без экрана ошибки, без «нет прав» и без «ничего не найдено» проверяет самый безопасный сценарий и создаёт ложную уверенность.
5. Проверяли не тот риск. Две недели полировали интерфейс, а фича умерла из-за того, что банк не поддерживает нужную операцию. Начинайте с левого верхнего угла квадранта.
6. Тест на коллегах. Команда знает систему и терминологию; она пройдёт любой сценарий. Нужны те, кто будет пользоваться, а если совсем никак — хотя бы люди из соседнего отдела.
7. Прототип стал продом. Особенно опасно с Wizard of Oz и «временными» скриптами: ручной процесс без даты выключения становится вечным. Ставьте дату и критерий выхода сразу.
8. Спайк без таймбокса. Исследование расширяется до бесконечности; через две недели ответа всё ещё нет. Три дня и письменный вердикт.
9. Результат нигде не записан. Через месяц вопрос «а почему не автоматизируем СБП?» приходит снова, и цикл повторяется. Реестр гипотез стоит десяти минут в неделю.
10. Прототип как способ избежать разговора. Иногда достаточно спросить эксперта; вместо этого делают макет на два дня. Дешевле — не всегда прототип.
11. Проверка после старта разработки. Команда уже пишет код, вы приносите результат теста — его либо игнорируют, либо переделывают с потерями. Проверка имеет смысл, только пока решение обратимо.
12. Опровержение воспринимается как провал. Если за «гипотеза не подтвердилась» ругают, через месяц все гипотезы будут подтверждаться. Считайте опровержение сэкономленным бюджетом и так и докладывайте: «проверка за 4 часа сняла 3 спринта работы не в ту сторону».

10. Мини-итог и чеклист

Прототип для аналитика — не картинка, а способ быстро и дёшево ошибиться. Он ловит неявные требования (форму нельзя нарисовать наполовину), вскрывает противоречия стейкхолдеров (на картинке несогласие видно сразу), отсеивает «хотелки» без задачи (нет сценария — нет прототипа) и даёт непроверяемым требованиям единицу измерения.

Чеклист перед тем, как отдавать требование в разработку:

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

Источники

• Marty Cagan. Inspired, 2nd ed. — svpg.com (четыре риска продукта: value, usability, feasibility, viability).
• Teresa Torres. Continuous Discovery Habits — producttalk.org (дерево возможностей, привычка проверять допущения непрерывно).
• Eric Ries. The Lean Startup — theleanstartup.com (цикл build–measure–learn, минимально достаточный эксперимент).
• Rik Higham. The MVP is dead, long live the RAT — medium.
• Jake Knapp. Sprint — thesprintbook.com (пятидневный формат проверки идеи прототипом).
• J. F. Kelley. An iterative design methodology for user-friendly natural language office information applications, ACM TOIS, 1984 — dl.acm.org (первоисточник Wizard of Oz).
• Jakob Nielsen. Why you only need to test with 5 users — nngroup.com.
• Steve Krug. Rocket Surgery Made Easy — sensible.com (как вести сеанс, если вы не исследователь).
• Karl Wiegers, Joy Beatty. Software Requirements, 3rd ed. — karlwiegers.com (глава о прототипировании требований и о рисках «прототип стал спецификацией»).
• OMG DMN — omg.org/spec/DMN (таблицы решений и политики разрешения конфликтов).
• OpenAPI Specification — spec.openapis.org; Prism — github.com/stoplightio/prism.
• Laurent Bossavit. The Leprechauns of Software Engineering — leanpub.com/leprechauns (почему «ошибка на проде дороже в 100 раз» — фольклор, а не измерение).

Что дальше

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

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