Самопроверка: от приоритета идеи до решения по эксперименту

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

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

Условие: две идеи в очереди

Команда оценивает два изменения в регистрации. Reach - уникальные клиенты, которых изменение затронет за квартал. Impact поставлен по общей шкале, Confidence записан долей, Effort - работа всех участников в человеко-месяцах.

Посчитайте RICE по формуле Reach × Impact × Confidence / Effort. Объясните, что значит преимущество одной строки над другой. Затем поменяйте условие: для B сначала нужна часть работы из A. Как это изменит выбор?

Разбор: приоритет опирается на оценки

У A выходит 1 000 × 1 × 0,8 / 2 = 400. У B: 500 × 2 × 0,5 / 1 = 500. По тем предположениям, которые команда записала, B стоит выше. Разница показывает ожидаемую пользу на единицу работы в выбранной модели. Измеренного эффекта за ней нет: изменение пока никто не сделал.

Метод RICE от Intercom объединяет охват, влияние, уверенность и трудозатраты. Чтобы сравнивать идеи, нужны общий горизонт и единица охвата, понятные основания для оценок и весь объём работы. Confidence 0,5 - это вес уверенности в исходных оценках, а не измеренная вероятность успеха в 50%.

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

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

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

Условие: победу объявляют по кликам

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

Что можно сообщить сейчас? Что должно было быть в плане до запуска? И как поступить, если команда нашла ошибку в протоколе?

Разбор: правило решения сохраняется

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

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

У напоминания о повторном заказе кофе такой план уже есть. Чтобы различить 25% и 33% при уровне значимости 5% и мощности 80%, нужно 473 человека на группу, 946 всего. Около 100 новичков в месяц соглашаются на сообщения, это 3,33 человека в день: 285 дней набора и ещё 60 дней ожидания, финальное чтение на 345-й день. Это тест магазина кофе, к регистрации из таблицы RICE он отношения не имеет.

В нём чётные ID получают напоминание, нечётные остаются в holdout. Группу назначают до того, как цепочка что-то сделает, и такой способ годится, только если чётность ID не связана с каналом, датой и филиалом. Если связана, до запуска нужен другой способ случайного назначения. В сравнении остаются все назначенные участники, в том числе те, кто сообщение не прочитал.

Промежуточные чтения запланированы примерно на пятый и восьмой месяц, когда закроются окна первых трёх и шести месяцев набора: около 150 и 300 человек на группу. Дату решения они не сдвигают, что бы на них ни увидели. Если к 345-му дню в группе меньше 473 участников с закрытым окном, в отчёте записывают недобор и неопределённость. Продлевать тест до удобного результата этот план не разрешает.

Ошибку измерения записывают отдельно: что нарушено, какие данные затронуты и какая новая проверка нужна. Исправленный протокол получает свою версию. Старые данные не становятся подтверждением новой гипотезы оттого, что переименовали колонку. Остановить тест по заранее заданному риску для клиентов можно, но это записывают как защитное решение, без объявления победителя.

Условие: оплаченных заказов больше, вклад ниже

В другом эксперименте магазина по 1 000 покупателей случайно назначили в A и в B. У каждого учитывают не больше одного заказа. Период набора и окно наблюдения одинаковые, оплаты и возвраты уже прошли согласованный срок. До запуска решили: если доля возвратов среди оплаченных заказов выше 8%, вариант не расширяют.

Каждый оставшийся заказ даёт 4 000 ₸ вклада после переменных расходов на товар и исполнение заказа. При полном возврате покупатель получает деньги назад, товар возвращается на склад, и его стоимость восстанавливается. Но 1 000 ₸ на всё, что в этом заказе не возмещается, включая исполнение и обработку возврата, магазин теряет. Других невозмещаемых расходов по возвращённому заказу в условии нет, это допущение задачи. Реклама, разработка и постоянные расходы пока исключены.

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

Разбор: ограничение входит в итог

Доля оплат у A - 100 / 1 000 = 10%, у B - 110 / 1 000 = 11%. Наблюдаемая разница - 1 процентный пункт. Насколько она надёжна, нужно оценить запланированным методом: одних процентов для объявления победителя мало.

Возвраты: 5 / 100 = 5% и 15 / 110, около 13,6%. У B заранее установленная граница 8% превышена, поэтому по этому правилу расширение откладывают. Если причина в учёте, сначала исправляют данные. Если возвраты настоящие, разбираются с товаром, обещанием и путём покупки и только потом решают, как менять вариант.

После возвратов в каждой группе остаётся по 95 заказов. Вклад A: 95 × 4 000 - 5 × 1 000 = 375 000 ₸. Вклад B: 95 × 4 000 - 15 × 1 000 = 365 000 ₸. Оплат у B больше, а вклада в границах задачи на 10 000 ₸ меньше. И это ещё не вся прибыль проекта: исключённые расходы добавляют следом.

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

Задание: составьте протокол своего эксперимента

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

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