Evaluate · Чеклист · Продуктовый план · Прозрачность · PTOS

Один лист оценки: обязательный артефакт для честной Evaluate

Как составить одностраничный 'Лист оценки' — обязательный артефакт Evaluate, который фиксирует цель, метрики, пороги, факты, guardrails и принятое решение.

Один лист оценки: обязательный артефакт для честной Evaluate

Фаза Evaluate — это момент истины для любого продуктового изменения. Но очень часто она превращается в хаотичное обсуждение, где мнения и эмоции заглушают данные. Чтобы избежать этого, в PTOS используется простой, но мощный инструмент — «Один лист оценки».

Если результаты вашего запуска нельзя уместить на один лист, скорее всего, вы не оцениваете, а оправдываетесь.

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

Зачем нужен «Один лист оценки»?

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

Структура «Одного листа оценки»

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

1. Цель изменения: Какую проблему мы решали и какое поведение хотели изменить?

• Пример: «Мы хотели увеличить долю пользователей, успешно создающих свой первый отчёт, так как заметили высокий отвал на этом шаге».

2. Целевая метрика (Outcome Metric): Какая одна метрика лучше всего отражает желаемое изменение поведения?

• Пример: «Процент новых пользователей, создавших первый отчёт в течение 24 часов после регистрации».

3. Окно измерения: В течение какого периода мы оцениваем результат?

• Пример: «14 дней после 100% раскатки изменения».

4. Пороги (Success / Fail / Grey): Какие значения метрики будут означать успех, провал или «серую зону»? (Фиксируются до старта)

• Пример:
  • Success: Рост метрики на 5 п.п. и более.
  • Fail: Рост менее 1 п.п. или падение.
  • Grey: Рост от 1 до 5 п.п. (сигнал есть, но слабый, нужна диагностика).

5. Факты (Данные + Наблюдения): Что мы увидели по факту?

• Пример:
  • Данные: «Целевая метрика выросла на 7 п.п. (с 15% до 22%)».
  • Наблюдения: «Из тикетов поддержки видим, что вопросы по созданию отчётов сократились на 30%».

6. Guardrails (Охранные метрики): Что мы не должны были сломать, и что с этим по факту?

• Пример:
  • Guardrail: «Среднее время создания отчёта». Факт: Не изменилось.
  • Guardrail: «Количество ошибок при создании отчёта». Факт: Снизилось на 15%.

7. Решение: Что мы делаем дальше: Scale, Iterate, Rollback или Kill?

• Пример: «Решение: Scale. Изменение признано успешным. Включаем его в основной флоу продукта и переходим к следующей гипотезе по улучшению редактора отчётов».

Как это работает на практике?

• До запуска: Заполняются пункты 1, 2, 3, 4 и 6 (только названия guardrail-метрик). Этот документ становится частью Launch Brief.
• После запуска: В установленное «окно измерения» (пункт 3) команда собирает данные и заполняет пункты 5 и 6 (фактические значения).
• На Evaluate-сессии: Команда смотрит на лист и принимает решение (пункт 7), основываясь на заранее определённых порогах. Никаких споров, никаких «мне кажется». Только факты и принятое на их основе решение.

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