Аркадий Рушкевич, Lead Product Manager в Wrike
Я искренне верю, что в достаточно сложном продукте невозможно использовать одну методологию для приоритизации всей работы команды. Мало того, слепое следование любым численным подходам — это опасный способ избавить себя от ответственности, делегировав решение числам. В любой методологии очень высок уровень субъективности, особенно в «универсальных» моделях типа RICE или любого кастомного scorecard. Очень легко либо пропустить что-то важное, неверно выбрав критерии и веса, либо наоборот — подстроить модель под то решение, которое и так есть у вас в голове. В первом случае — вы просто будете строить не тот продукт, который нужен, во-втором — потратите время и усилия на получение результата, который у вас и так есть.
Для понимания моего мнения стоит чуть-чуть разобраться со спецификой Wrike. У нас достаточно сложный B2B продукт для широкого рынка, причем продукт разрабатывается одновременно несколькими командами, работающими в разных направлениях. Уже нельзя оценить, сколько клиентов и денег нам принесет то или иное улучшение, уже можно работать с аналитикой и метриками, но при этом клиентов все же недостаточно, чтобы применять чисто экспериментальные подходы крупных B2C-проектов.
Основной и главный способ приоритизации для меня лично — это ориентация на текущие бизнес-цели. Есть несколько проектов (фичей, улучшений), которые можно было бы реализовать, есть цели компании или направления на год, и каждый из проектов можно прогнать по ряду простых вопросов.
Первый — поможет ли этот проект достичь поставленной цели? Если мой личный ответ — «нет», то, наверное, стоит вычеркнуть его сразу. И давайте откровенно: если вы не можете дать ответ на этот вопрос ни для одной из фичей, не расписав таблицу с оценками, то, вероятно, вы хреновый менеджер продукта. Если ответ — «да», то идем дальше.
Второй — какую метрику я смогу улучшить этим проектом и насколько? Опять же, на уровне экспертного мнения обычно просто понять, на что может повлиять то или иное улучшение. Если при попытке ответить на этот вопрос я понимаю, что либо этот проект ни на что не повлияет, либо если улучшение будет маргинальным (2%, а нужно 25%), то опять же — стоит отложить эту идею.
Ну и последний, скорее фильтр, а не вопрос — попытаться продать фичу коллегам или руководству. Для этого надо собрать какие-то количественные и качественные доводы и выразить все лаконичным и понятным языком презентации. Если сделать это несложно — значит скорее всего и проект подходящий. Но если информацию приходится высасывать из пальца, а нить повествования не складывается — возможно, дело не в навыках подготовки презентаций, а в том, что выбор какой-то неправильный?
Ну и наконец, когда приходит время планировать отдельный проект и приоритизировать функционал в нем, тогда можно использовать какую-то простую методику для определения MVP и порядка реализации отдельных функций. Это может быть просто story mapping, что-то вроде MoSCoW или же модель Кано, информации для которой обычно уже будет достаточно собрано на интервью с клиентами.
Я искренне верю, что в достаточно сложном продукте невозможно использовать одну методологию для приоритизации всей работы команды. Мало того, слепое следование любым численным подходам — это опасный способ избавить себя от ответственности, делегировав решение числам. В любой методологии очень высок уровень субъективности, особенно в «универсальных» моделях типа RICE или любого кастомного scorecard. Очень легко либо пропустить что-то важное, неверно выбрав критерии и веса, либо наоборот — подстроить модель под то решение, которое и так есть у вас в голове. В первом случае — вы просто будете строить не тот продукт, который нужен, во-втором — потратите время и усилия на получение результата, который у вас и так есть.
Для понимания моего мнения стоит чуть-чуть разобраться со спецификой Wrike. У нас достаточно сложный B2B продукт для широкого рынка, причем продукт разрабатывается одновременно несколькими командами, работающими в разных направлениях. Уже нельзя оценить, сколько клиентов и денег нам принесет то или иное улучшение, уже можно работать с аналитикой и метриками, но при этом клиентов все же недостаточно, чтобы применять чисто экспериментальные подходы крупных B2C-проектов.
Основной и главный способ приоритизации для меня лично — это ориентация на текущие бизнес-цели. Есть несколько проектов (фичей, улучшений), которые можно было бы реализовать, есть цели компании или направления на год, и каждый из проектов можно прогнать по ряду простых вопросов.
Первый — поможет ли этот проект достичь поставленной цели? Если мой личный ответ — «нет», то, наверное, стоит вычеркнуть его сразу. И давайте откровенно: если вы не можете дать ответ на этот вопрос ни для одной из фичей, не расписав таблицу с оценками, то, вероятно, вы хреновый менеджер продукта. Если ответ — «да», то идем дальше.
Второй — какую метрику я смогу улучшить этим проектом и насколько? Опять же, на уровне экспертного мнения обычно просто понять, на что может повлиять то или иное улучшение. Если при попытке ответить на этот вопрос я понимаю, что либо этот проект ни на что не повлияет, либо если улучшение будет маргинальным (2%, а нужно 25%), то опять же — стоит отложить эту идею.
Ну и последний, скорее фильтр, а не вопрос — попытаться продать фичу коллегам или руководству. Для этого надо собрать какие-то количественные и качественные доводы и выразить все лаконичным и понятным языком презентации. Если сделать это несложно — значит скорее всего и проект подходящий. Но если информацию приходится высасывать из пальца, а нить повествования не складывается — возможно, дело не в навыках подготовки презентаций, а в том, что выбор какой-то неправильный?
Ну и наконец, когда приходит время планировать отдельный проект и приоритизировать функционал в нем, тогда можно использовать какую-то простую методику для определения MVP и порядка реализации отдельных функций. Это может быть просто story mapping, что-то вроде MoSCoW или же модель Кано, информации для которой обычно уже будет достаточно собрано на интервью с клиентами.