Пользователь, JTBD и метрика успеха

1. Идея без пользователя не работает

На старте очень легко увлечься красивой формулировкой. «Сделаю AI-помощника для поддержки», «умный сервис для ecommerce», «систему, которая улучшает клиентский опыт». Солидно — и для разработки бесполезно. Это как написать на посылке не адрес, а вдохновляющую фразу: курьер расчувствуется, но везти её некуда.

До этого user, pain, result и scope работали фильтрами идеи: они помогали понять, есть ли у проекта вообще рабочий угол. Теперь их надо зафиксировать жёстче — как поля спецификации. Назовите конкретного пользователя — и проект приземляется: появляются рабочая ситуация, ограничения, язык интерфейса, критерии пользы, будущие guardrails. Оператору поддержки нужен inbox, быстрый разбор тикетов и безопасная работа с возвратами; менеджеру магазина — dashboard, сводка, тренды. Снаружи одно «AI для поддержки». Внутри — два разных продукта.

Небольшая таблица это очень быстро показывает:

Очень полезно держать в голове простую цепочку:

flowchart TD
    A[Идея] --> B[Конкретный пользователь]
    B --> C[Конкретная боль]
    C --> D[JTBD]
    D --> E[Метрика успеха]
    E --> F[Demo-сценарий]

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

2. Persona — рабочая карточка, а не роман

Описание пользователя в MVP — не биография и не анкета из отдела маркетинга. Любимый цвет, знак зодиака и отношение к авокадо-тостам вам не нужны. Нужно то, что двигает инженерные решения: где он работает, что делает каждый день, каким инструментом пользуется сейчас, в какой момент начинается боль. Проверка: можете после persona назвать нужный интерфейс, данные и выигрыш — текст полезный. Хочется сказать только «интересный человек» — текст симпатичный, но бесполезный.

Вот какие поля обычно дают наибольшую пользу:

Такой фрагмент уже можно положить в текущую спецификацию:

## Пользователь

Роль: оператор поддержки небольшого интернет-магазина  
Рабочий день: 60–100 тикетов в день  
Инструменты: inbox магазина, почта, заметки с шаблонами  
Текущий обходной путь: копирует типовые ответы вручную  
Главная боль: типовые обращения забирают время у сложных кейсов

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

3. Старт — с workaround, а не с AI

Пользователь не просыпается с мыслью «как жаль, что у меня нет классификатора обращений на базе LLM». Он просыпается с мыслью «переполнен inbox, половина смены уходит на копипаст, а рискованный refund утонет среди вопросов про доставку». С этого и начинайте.

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

Для нашего примера это можно оформить так:

## Проблема

Оператор тратит значительную часть смены на типовые вопросы
про статус заказа, доставку и правила возврата.

## Текущий обходной путь

Оператор копирует готовые ответы из заметок и вручную ищет
refund-кейсы, которые требуют отдельного внимания.

Почему это так важно? Потому что без обходного пути проблема остаётся слишком гладкой — «поддержка работает медленно». Опишите текущий способ — пойдут практические вопросы: что опаснее, медленный ответ или пропущенный дорогой возврат? И выясняется: продукт нужен не для «автоматизации ответов», а для разделения типовых и рискованных случаев. Здесь же впервые появляется human-in-the-loop, хотя многие ждут его позже: с типовыми тикетами система помогает, а refund > $100 нельзя отдавать AI на автопилот. Границу указала сама проблема.

Очень частая ошибка на этом шаге — писать проблему уже языком решения. «Система должна автоматически классифицировать тикеты и генерировать ответы» — это не проблема, это кусок implementation. Проблема звучит со стороны пользователя; решение появится потом. Перепутаете слои — влюбитесь в фичу раньше, чем докажете, что она кому-то нужна.

4. JTBD: одна формула, которая убирает туман

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

Каноническая формула выглядит так:

Когда [ситуация],
я хочу [сделать работу],
чтобы [получить результат].

В нашем примере это может звучать так:

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

Секрет силы этой формулы в том, что она очень быстро ловит фальшь. Пустой «когда» — не понимаете момент использования. В «я хочу» вылезла AI-фича — снова уехали в решение. В «чтобы» стоит «чтобы всё было лучше» — результат не сформулирован.

Удобно проверять JTBD по такой маленькой таблице:

Есть ещё один полезный трюк. Попробуйте подставить в JTBD другого пользователя — и посмотреть, как поедет продукт:

Это очень отрезвляет. Внешне тема одна — поддержка интернет-магазина, — а продукт каждый раз другой. JTBD полезен не для красоты документа: он вовремя ловит момент, когда вы незаметно строите уже не тот MVP.

5. Метрика успеха: видимая польза MVP

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

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

Сравните формулировки:

Для AI Support Agent хороший набор метрик может выглядеть так:

## Метрика успеха

- На 10 sample tickets точность классификации не ниже 80%
- На типовых вопросах AI draft требует не более 2 правок оператором
- Возврат выше $100 не может быть отправлен без ручного approval
- В audit trail видно, что предложил AI и что сделал оператор

Здесь важно, что метрика проверяет не только «умность» модели, но и пользу, безопасность и наблюдаемость результата. Это важно, потому что начинающие разработчики очень любят сводить success metric к одной цифре качества модели. Но MVP редко проваливается из-за точности классификации — чаще потому, что не вписался в рабочий день, не дал безопасного сценария или не показал понятный результат на demo.

Именно отсюда потом естественно вырастает демонстрация. Метрика про 10 sample tickets — их и показываете; метрика про блокировку возврата выше порога — в demo обязательно кейс с таким возвратом. Хорошая метрика экономит силы дважды: при проектировании и при показе.

6. Сборка фрагмента MVP_SPEC.md

Когда пользователь, проблема, JTBD и метрика описаны по отдельности, их уже легко собрать в рабочий фрагмент документа. Ещё не весь MVP_SPEC.md, но уже его самая живая середина: часть, после которой идея перестаёт быть красивым облаком и становится понятным продуктовым срезом.

Вот как это может выглядеть для нашего AI Support Agent:

## Пользователь
Оператор поддержки небольшого интернет-магазина.
За смену обрабатывает 60–100 обращений и работает в inbox магазина.

## Проблема
Типовые вопросы о доставке и статусе заказа занимают слишком много времени,
из-за чего сложные и дорогие refund-кейсы можно пропустить.

## Текущий обходной путь
Оператор копирует ответы из заметок и вручную просматривает тикеты,
пытаясь не пропустить рискованные случаи.

## JTBD
Когда я утром открываю inbox с десятками обращений,
я хочу быстро закрывать типовые тикеты,
чтобы у меня оставалось время на сложные и рискованные кейсы.

## Метрика успеха
На 10 sample tickets система верно классифицирует не менее 8,
а refund выше $100 всегда требует ручного approval.

Если ваш capstone — чистый MVP, фрагмент живёт в MVP_SPEC.md. Если нет — не выносите его в отдельный параллельный файл: встройте тот же блок в существующий SPEC.md как уточнение продуктовой части. Логика не меняется: честно ответьте, кто получает пользу, в какой ситуации и по какому наблюдаемому признаку вы поймёте, что проект облегчает жизнь.

И тут приятная магия без всякой мистики. Четыре блока написаны нормально — и дальше проще решать: какие данные нужны, что входит в проект, что лишнее, где нужен человек в контуре, что показывать на demo. Claude Code тоже работает лучше — перестаёт гадать, о каком «улучшении поддержки» шла речь, и помогает в рамках понятной задачи с конкретным пользователем и земным результатом.