Если спросить продакта про data-driven (ок-ок, data-informed) подход, то конечно он скажет, что это правильно и надо все считать. На практике же перейти от подхода “делаем, что сердечко попросит” к “смотрим на числа, а потом делаем” сложно (и не всегда нужно).
Резкий переход от “выбора сердцем” к выбору фич только через расчеты или сломает работающие текущие процессы или же родит бюрократические кафкианские таблицы с кучей полей и баллов. А на деле по прежнему выбор будет делаться как и раньше (если продакт хочет фичу — он без задней мысли нарисует там столько баллов, что таблица скажет делать эту фичу первой), только теперь надо кучу таблиц заполнять.
Переход должен быть осмысленный. Поэтому если сейчас вы совсем не смотрите на данные при выборе фич, но хотите начать — может подойти вот такой вот путь.
- Шаг 1: считаем данные после выпуска. Ничего не меняем в выборе фич. Выбираем как и раньше. Но после того, как каждое новое изменение выпущено, cчитаем его метрики использования: как часто использовали эту фичу, как именно (базовые штуки).
Этот первый шаг уже заставить сделать две вещи: начать считать хоть что-то (то есть построить базовую инфраструктуру аналитики) и смотреть на реальное использование фичи в жизни (сюрпризы вида “я думал будет популярная штука, а использовало три человека” бодрят).
- Шаг 2: делаем предсказания перед началом разработки и считаем данные после выпуска. Ничего не меняем в выборе фич. Выбираем как и раньше. Но теперь после выбора фичи делаем предсказание про ее использование, например “как много народу ее будет использовать?”. Предсказание записываем. После выпуска собираем аналитику (мы это научились уже делать в шаге 1) и сравниваем.
Этот шаг заставляет нас научится делать базовую оценку ДО выпуска фичи и сравнивать потом предсказание с реальным результатом, давая обратную связь. Это учит делать лучшие предсказания и учит, что наши предсказания часто ошибочны.
- Шаг 3: делаем предсказания перед началом разработки, они влияют на выбор. У нас уже есть backlog изменений. Делаем предсказания (по сути строим модель или прикидываем будущее использование) про каждое изменение. Предсказания с максимальным результатом имеют сильное влияние на наш выбор, что делать.
На этом шаге мы уже используем оценку для лучшего выбора. В следующий шагах уже можно делать более сложные оценки (например уже считать влияние на деньги и учитывать затраты на разработку).
Важное замечание: я (пока) противник использования подхода, когда для выбора “что делать” используются только расчеты: ввел в кучу колонок данные и оно сказало, что делать. На мой взгляд такой подход не дает выйти из локального максимума, заставляет игнорировать области, влияние которых сложновычислимо (дизайн и скорость, например), не учитывают стратегические вещи и так или иначе не убирают субъективный выбор человека (баллы же он там сам проставляет). Поэтому я за подход “данные помогают принять решение что делать”, когда они влияют на выбор и помогают избавится от ошибок решений, но не задают выбор сами.