Користувач і JTBD
JTBD описує не демографічний портрет, а ситуацію, у якій користувач «наймає» продукт для певної роботи. Добрий job містить trigger, контекст, бажаний progress і обмеження. Формулювання «користувач хоче AI» не пояснює, що має змінитися.
Відокремлюйте observed fact, assumption і desired outcome. Навіть дуже конкретний JTBD у capstone залишається навчальною гіпотезою, доки не має підтвердженого дослідження або фактичного usage evidence.
JTBD у перевірюваному форматі
| Поле | Приклад documented example |
|---|---|
| When | Коли reviewer отримує малу, але неоднозначну зміну |
| I want to | Швидко зрозуміти scope, перевірки й залишкові Unknowns |
| So I can | Прийняти наступний review decision без повторного discovery |
| Constraint | Немає доступу до непідтверджених production claims |
| Success signal | Потрібні evidence anchors знайдені в одному review pass |
Метрика успіху та межі інтерпретації
Метрика має назву, одиницю вимірювання, baseline, target, observation window і спосіб збору. Для early MVP не підміняйте outcome metric vanity metric на кшталт кількості AI-викликів. Якщо baseline або реальний observation window відсутні, це потрібно записати явно.
Одна leading metric може показувати проходження flow, а одна outcome metric — чи став результат кориснішим для користувача. Guardrail metric потрібна, якщо оптимізація швидкості може погіршити якість або безпеку.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush