Эксперименты и A/B-подход: чему учат цифровые продукты
Не все решения требуют годового проекта. Часть из них стоит проверять быстрыми опытами - даже в промышленной среде.
В технологических компаниях, которые делают продукты для массового потребителя, сложилась культура, которая давно стала нормой: прежде чем внедрить изменение глобально, его проверяют на небольшой части пользователей. Кнопка справа или слева. Новый алгоритм ранжирования или старый. Письмо с одной темой или с другой. Сравниваешь результат - принимаешь решение.
Это называют A/B-тестированием, или шире - культурой экспериментов. И у меня давно есть вопрос: почему эта логика так редко применяется за пределами цифровых продуктов?
Почему это кажется неприменимым
Стандартный ответ - "у нас другая специфика". В производстве нельзя параллельно запустить два процесса. В сервисном бизнесе клиенты заметят разницу. В b2b слишком мало транзакций, чтобы получить статистически значимый результат.
Часть этих возражений обоснована. Но часть - просто привычка думать в формате больших проектов.
Когда я разговариваю с руководителями компаний не из технологического сектора, я часто замечаю, что они принимают решения одним из двух способов. Либо на основе интуиции и прошлого опыта, либо запускают полноценный проект с обоснованием, согласованием и внедрением, который занимает месяцы. Среднего - быстрой, дешёвой проверки гипотезы - почти нет.
Что такое эксперимент в нецифровой среде
Эксперимент в промышленном или сервисном контексте не обязательно выглядит как классический A/B-тест с контрольной и тестовой группой. Это может быть:
- пилот на одном участке производства перед тиражированием;
- пробное изменение скрипта продаж для одной из команд;
- тест нового формата отчёта на одном подразделении перед внедрением во всей компании;
- запуск нового процесса приёмки на одном складе.
Общий принцип: изменение применяется к части системы, результат измеряется, вывод делается до масштабирования. Это не наука в строгом смысле - но это куда лучше, чем "запустим и посмотрим" в масштабе всей организации.
Что нужно, чтобы это работало
Три условия, без которых эксперимент не имеет смысла.
Первое - формулировка гипотезы до начала. Что именно мы проверяем? Какой результат будет считаться подтверждением, какой - опровержением? Если гипотезу формулируют после получения результатов, это уже не эксперимент, а объяснение того, что случилось.
Второе - метрика, которую можно измерить. Не "стало лучше", а "выход годных изделий вырос с X до Y" или "время обработки одного заказа снизилось с A до B". Без измеримого результата нет эксперимента - есть впечатление.
Третье - готовность принять отрицательный результат. Это самое сложное. Культура, в которой "отрицательный результат - это провал", убивает эксперименты быстрее любого технического ограничения. Если команда знает, что результат "не работает" будет воспринят как личная ошибка - она не будет проверять гипотезы, которые могут не подтвердиться.
Где это не работает
Честный разговор требует признать ограничения.
Там, где изменение нельзя обратить - эксперимент опасен. Там, где выборка слишком мала и любое случайное колебание будет выглядеть как результат - выводы ненадёжны. Там, где цена подготовки пилота сопоставима с ценой полного внедрения - смысла нет.
Но таких ситуаций меньше, чем обычно думают. Большинство операционных гипотез можно проверить быстро, дёшево и обратимо - если сделать это намеренно.
Несколько вопросов для старта
Перед следующим крупным изменением в компании стоит задать себе:
- Можно ли это проверить сначала на части системы?
- Что именно мы хотим узнать - и как мы поймём, что узнали?
- Есть ли у нас базовые показатели, с которыми можно сравнивать результат?
- Кто принимает решение по итогам эксперимента, и по каким критериям?
- Если результат будет отрицательным - что мы сделаем?
Иногда ответ на первый вопрос - нет, невозможно. Но чаще, чем кажется, ответ - да, если немного перестроить подход.