#оценка_гипотез #ICEscore
Денис Осипов, продакт менеджер ABBYY рассказал, как в их отделе Mobile App оценивали гипотезы на базе методологии ICE Score.
Вот стандартная формула подсчета ICE Score: Impact (влияние на продукт) * Confidence (уверенность, что это произойдет) * Ease (простота внедрения фичи).
Что пытались решить?
В ABBYY хотели, чтобы у каждого члена команды, в том числе у разработчиков, было понимание, как оценивается продукт. Также методология должна была повысить качество решений, чтобы не терять по полгода на фичу, которая изначально казалась крутой, а на деле — нерабочей. Улучшить прозрачность в команде и ускорить решения.
В компании начали не со скоринга, а с поиска проблем продуктов с помощью качественных исследований (интервью, опросы, отзывы) и поиска узких мест воронки (аналитика, Usability-исследования). Обычно оказывалось около пяти пользовательских проблем. И несколько «личных» проблем, вроде нехватки экономии, воронок в продуктах.
После этого формировалось не менее 10 гипотез решений на одну проблему.
Как вводили ICE Score?
Вот формула, которой пользовались в компании: аудитория продукта * сколько % увидят * сколько % воспользуется * сколько заплатит.
Здесь цель ICE Score — определить самые денежные фичи.
В чем смысл?
Когда ты придумываешь задачу, исследуешь рынок, слушаешь пользователей, залезаешь в аналитику — тебе кажется, что все круто.
Но формула ICE Score делит твою гипотезу на 100 — и в итоге ставит на место. Эта методология заставляет тестировать гипотезы и выходить на более высокий уровень confidence.
С какими проблемами столкнулись?
У продуктов ABBYY не одна цель, а несколько, поэтому пришлось на каждую выстраивать свою ICE Score. Это оказался длительный и сложный процесс. В компании решили пользоваться оценкой гипотез только, если разработчик тратит больше трех дней на создание продукта. Также одной из проблем стали условия, влияющие на приоритеты разработки, но не вписывающиеся в модель.
Вдобавок ко всему, — сниженная объективность. Поэтому любая оценка проходит защиту перед всей командой, чтобы снять фильтр восприятия одного человека, который выстраивал ICE Score.
Итоги:
1) Поиск основных проблем
— Выделение самых срочных задач
— Формирование видения продукта
2) Оценка решений/гипотез
— Приоритезация
— Подтверждение
3) Груминг
— Избавления от фильтров восприятия
— Прозрачность
Подробности на видео митапа (с 47 мин): https://www.youtube.com/watch?v=B76mDTx2xnY&feature=youtu.be&fbclid=IwAR1kwC8_qsUexmJUHMVJiFhVYwFzqvpH2vJD7YInVWdTDH-HRVZZjIV_-xo
Денис Осипов, продакт менеджер ABBYY рассказал, как в их отделе Mobile App оценивали гипотезы на базе методологии ICE Score.
Вот стандартная формула подсчета ICE Score: Impact (влияние на продукт) * Confidence (уверенность, что это произойдет) * Ease (простота внедрения фичи).
Что пытались решить?
В ABBYY хотели, чтобы у каждого члена команды, в том числе у разработчиков, было понимание, как оценивается продукт. Также методология должна была повысить качество решений, чтобы не терять по полгода на фичу, которая изначально казалась крутой, а на деле — нерабочей. Улучшить прозрачность в команде и ускорить решения.
В компании начали не со скоринга, а с поиска проблем продуктов с помощью качественных исследований (интервью, опросы, отзывы) и поиска узких мест воронки (аналитика, Usability-исследования). Обычно оказывалось около пяти пользовательских проблем. И несколько «личных» проблем, вроде нехватки экономии, воронок в продуктах.
После этого формировалось не менее 10 гипотез решений на одну проблему.
Как вводили ICE Score?
Вот формула, которой пользовались в компании: аудитория продукта * сколько % увидят * сколько % воспользуется * сколько заплатит.
Здесь цель ICE Score — определить самые денежные фичи.
В чем смысл?
Когда ты придумываешь задачу, исследуешь рынок, слушаешь пользователей, залезаешь в аналитику — тебе кажется, что все круто.
Но формула ICE Score делит твою гипотезу на 100 — и в итоге ставит на место. Эта методология заставляет тестировать гипотезы и выходить на более высокий уровень confidence.
С какими проблемами столкнулись?
У продуктов ABBYY не одна цель, а несколько, поэтому пришлось на каждую выстраивать свою ICE Score. Это оказался длительный и сложный процесс. В компании решили пользоваться оценкой гипотез только, если разработчик тратит больше трех дней на создание продукта. Также одной из проблем стали условия, влияющие на приоритеты разработки, но не вписывающиеся в модель.
Вдобавок ко всему, — сниженная объективность. Поэтому любая оценка проходит защиту перед всей командой, чтобы снять фильтр восприятия одного человека, который выстраивал ICE Score.
Итоги:
1) Поиск основных проблем
— Выделение самых срочных задач
— Формирование видения продукта
2) Оценка решений/гипотез
— Приоритезация
— Подтверждение
3) Груминг
— Избавления от фильтров восприятия
— Прозрачность
Подробности на видео митапа (с 47 мин): https://www.youtube.com/watch?v=B76mDTx2xnY&feature=youtu.be&fbclid=IwAR1kwC8_qsUexmJUHMVJiFhVYwFzqvpH2vJD7YInVWdTDH-HRVZZjIV_-xo
YouTube
Гипотезы: команда, оценка, маленькие выборки
15:39 строим команду для быстрой проверки гипотез // Марина Арефьева
40:35 вопросы Марине
46:44 оценка гипотез и беклог на основе ICE Score // Денисо Осипов // ABYY
1:01:53 вопросы Денису
1:14:23 проверка на маленьких выборках // Искандер Мирмахмадов //…
40:35 вопросы Марине
46:44 оценка гипотез и беклог на основе ICE Score // Денисо Осипов // ABYY
1:01:53 вопросы Денису
1:14:23 проверка на маленьких выборках // Искандер Мирмахмадов //…