Я не писал в канал больше месяца и это, конечно плохо. Это время было очень насыщенным на изменения и новые знания. Мы делаем самое большое изменение флагманского продукта PDF Expert за всю историю компании, создали Growth Team для Documents, ввели A/B tracker и начали не просто проводить эксперименты, а учиться на них, так, что даже самые неудачные эксперименты (а их большенство) дают нам достаточное количество инсайтов, чтобы следующий эксперимент был успешным. Во всей этой суете я не имел возможность наполнять канал качественным контентом, а писать о том, как у меня прошел день и надеяться, что вам это будет интересно, не очень сочетается с моим представлением канале.
Сегодня хочу рассказать вам об одном из фреймоврков приоритезации задач, которым я иногда пользуюсь. Называется от RICE:
R - reach (Охват). Предполагаемое количество пользователей увидят/узнают эту функциональность в продукте. Можно посмотреть по, например, MAU экрана, на котором будет находится эта функция.
I - impact (Влияние). Влияние на нужную метрику (деньги, возвращаемость, активация и т.д.). Достаточно грубой оценки: несколько процентных пунктов, десятки процентных пунктов, разы. Можно сделать свой скоринг: 5 (огромное влияние); 4 (высокое); 3 (среднее); 2 (низкое); 1 (минимальное)
С - Confidence (Уверенность). На сколько вы уверены в правильности оценки Охвата и, самое главное, Влияние. Например: 100% полная уверенность, 80% средняя вероятность, 50% низкая вероятность. Все, что ниже 50% – полная не уверенность.
E - Effort (Усилия). Какие ресурсы (например, человеко-месяцев) вам нужны для реализации функциональности. В отличии от остальных, этот показатель хорош, когда он низкий.
Можно использовать этот фреймоворк для “примерной” оценки, если беклог очень большой, можно даже Google таблицу сделать и считать формулой приоритет (P), ранжируя задачи по уменьшению числа RICE. Такая формула могла бы выглядеть, так:
P= (RIC)/E
Разумеется, так нельзя считать все задачи, есть еще рынок, пользователи, развитие продукта, плюс скорринг в Impact антинаучный, но в спорных моментах, при обсуждении с командой, это может быть неплохим решением.
Давайте наполнять канал смыслом вместе. Расскажите, с какими сложностями/вопросами сталкиваетесь, работая над продуктом (любым, даже оффлайн), а я постараюсь поделиться своими мыслями на этот счет