Приоритизация гипотез служит главной цели – как можно быстрее достичь успеха. Если следовать этой логике, идеи, которые с большей вероятностью могут дать результат, должны быть первыми в списке на реализацию. Но у каждой гипотезы есть такая характеристика, как сложность ее реализации, – вот почему, приоритизируя гипотезы, важно оценивать их трудоемкость и стоимость инфраструктуры (сервера, наем дополнительного персонала). Допустим, первая гипотеза обещает принести примерно 10 млн рублей за год, при этом затраты на ее реализацию – это месяц работы двух разработчиков и одного аналитика данных. Вторая обещает 2 млн рублей за год, при этом реализовать ее смогут два человека за пять дней работы. Какую гипотезу выбрать первой? Это решение я оставляю за менеджментом, однозначного совета дать здесь не могу.
Что если гипотезы и их приоритизацию делать внутри отделов? С одной стороны, этот подход кажется правильным – минимум централизации, максимум скорости. Но давайте представим себе, что компания – это живой организм, а ее самый сильный отдел (например, IT) – это руки. У отдела хороший список гипотез, и приоритеты расставлены более правильно, чем у других отделов, – то есть руки прокачаны как следует. А теперь представим себе соревнования по триатлону – на олимпийской дистанции нужно проплыть 1500 метров, сразу после этого сесть на велосипед и проехать 40 км, а затем пробежать 10 км. Сильные руки пригодятся на первом этапе, но в двух других дисциплинах нужны уже сильные ноги. Если они не так хорошо натренированы, спортсмен проиграет гонку более сбалансированным соперникам или даже может сойти с дистанции. В бизнесе, как в спорте, невозможно сделать ставку на один отдел – нужен сбалансированный подход. Я сам проходил это в Retail Rocket – варился в собственном соку, приоритизировал свои гипотезы сам. Да, мы стали очень сильными в одной области, но остальные команды не успевали за нами. Если вернуться назад, я бы сделал ставку на совместную работу, продукт и рынок.
Все гипотезы из списка невозможно протестировать. Большинству уготовано так и остаться навеки гипотезами. Это нормально и даже хорошо – значит, более выгодные идеи реализуются раньше остальных. Каждая гипотеза потребляет ресурсы, они не бесконечны, поэтому невозможно протестировать все идеи. Скажу больше – 9 из 10 гипотез не принесут результата. Но понятно это может стать только на одном из многочисленных этапов ее тестирования. Моя теория заключается в том, что нужно убивать гипотезу как можно раньше, как только мы получим первый сигнал о том, что она не взлетит. Это сэкономит ресурсы – много ресурсов! – и даст шанс лучшим гипотезам, которые ожидают своей очереди.
Я сравнивал разные гипотезы и их отдачу. Эволюционные гипотезы, где один параметр слегка оптимизируется, в случае успеха дают меньший эффект по сравнению с революционными гипотезами, где подход принципиально иной. Но вероятность успеха как такового у эволюционной гипотезы выше.
Планируем тест гипотезы
Пусть у нас есть готовая гипотеза, которую бизнес признал самой горячей. У нас есть все ресурсы, и мы готовы взять ее в работу. Какая еще информация нужна? Во-первых, цель гипотезы – какую количественную метрику она будет оптимизировать? Мы уже понимаем, что количественные метрики неидеальны, но нам она нужна для отслеживания изменений. Здесь метрика – это то число, значимо улучшив которое можно покупать ящик шампанского.
Во-вторых, нужно понимать, как мы будем тестировать гипотезу и где. В машинном обучении есть два вида тестирования: офлайн и онлайн. Офлайн дает метрики на уже существующих данных – о них я писал в главе 8 «Алгоритмы машинного обучения». В онлайн-тестировании нужно получить интересующие метрики и сравнить их с помощью статистических тестов.