Работа с приоритетами — задача, требующая подготовки, опыта и рассмотрения множества технологий, научных подходов, а также авторских методов.
Эта статья – перевод материала с сайта Hackernoon.com. Ее автор предлагает применение собственного инструмента оценки приоритетов в рамках метода ICE Scoring. В этой статье детально описан подход и разобран простой и доступный пример, понятный любому менеджеру продукта.
Itamar Gilad — известный консультант в области управления продуктами и успешный спикер. В его многолетнем опыте — руководящие должности по управлению продуктами в Google, Microsoft и других известных компаниях. Мы предлагаем перевод его статьи:
Допустим, вы управляете продуктом для малого бизнеса и его клиентов. Ваша цель — улучшить степень вовлеченности и удержания клиентов. У вас на повестке две идеи:
Идея с панелью инструментов возникала несколько раз в переговорах с клиентами, и вы чувствуете, что она имеет хороший потенциал, но существует риск того, что ее будут использовать только опытные пользователи.
Идея с чатботом нравится всей компании, и руководство довольно оптимистично воспринимает ее. Также фича выглядит выигрышной и для клиентов.
Что бы вы выбрали?
Этот вопросы приоритизации лежат в основе управления продуктом. Плата за неправильный выбор может оказаться весьма большой и включать стоимость разработки, деплоймента, обслуживания, а также другие внеплановые затраты.
Мы часто испытываем соблазн принять решение на основе неубедительных сигналов: мнения большинства, мнения начальников, отраслевых тенденций и т. д. Но время показывает, что эти сигналы по точности находятся на уровне генератора случайных чисел.
Этот пост о том, как, на мой взгляд, находить лучшие идеи. Он состоит из трех частей:
ICE Scoring — это метод определения приоритетов, который впервые использовал Шон Эллис, известный своим активным участием в становлении таких компаний, как DropBox и Eventbrite, и продвижении термина Growth Hacking. ICE первоначально был предназначен для определения приоритетов в growth экспериментах, но вскоре стал использоваться для оценки любых идей.
В ICE вы оцениваете идеи таким образом:
Значения в ICE оцениваются по шкале от 1 до 10, чтобы все факторы сбалансировано повлияли на итоговое число. Под значениями 1-10 можно подразумевать все что угодно, главное, чтобы значения были согласованы между собой.
Теперь давайте на примере посмотрим, как это работает.
Итак, вы решили рассчитать баллы по ICE для двух идей: dashboard и чатбота. На этом раннем этапе вы используете грубые значения исключительно на основе собственной интуиции.
Влияние — вы предполагаете, что дэшборд значительно увеличит удержание пользователей, но только опытных, — вы даете 5 из 10. Чатбот, с другой стороны, может стать инновационным решением для многих клиентов, поэтому вы даете ему 8 из 10.
Легкость реализации — вы оцениваете, что для dashboard потребуется 10 человеко-недель, а для чат-бота — 20. Позже от команды вы получите более качественные оценки. Вы используете эту простую таблицу (выбранную вами и вашей командой) для преобразования вашей оценки в Ease:
Таким образом, панель инструментов получает значение Ease 4 из 10 и чатбот — значение 2.
Существует только один способ рассчитать уверенность — это поиск подтверждающих доказательств. Для этого я создал инструмент, который можно увидеть ниже. В нем перечислены общие типы тестов и доказательств, которые могут быть у вас, и уровень уверенности, который они предоставляют: результаты тестов, дата лонча, собственная уверенность, тематическая поддержка, мнение других людей, данные рынка и др.
При использовании инструмента учитывайте, какие показатели у вас уже есть, сколько из них и что вам нужно, чтобы получить больше уверенности.
Если в вашем продукте или в отрасли возможна другая проверка доказательств, не стесняйтесь создавать свою собственную версию этого инструмента.
Вернемся к примеру, чтобы оценить инструмент в действии.
Поддержка доказательств для чатбота: личная уверенность (вы думаете, что это хорошая идея), тематическая поддержка (в индустрии также считают, что это хорошая идея) и мнение других (ваше начальство и коллеги считают это хорошей идеей). Это дает ему общее доверительное значение 0,1 из 10 или Near Zero Confidence. Инструмент явно не считает мнения надежным индикатором.
Что по поводу dashboard? Здесь личная уверенность (вы думаете, что это хорошая идея) и эпизодическая поддержка (несколько клиентов попросили об этом). Это фактически повышает его доверительное значение до 0,5 из 10, что является низким доверием. К сожалению, клиенты плохо прогнозируют свое будущее поведение.
ICE scoring в этом случае:
К этому моменту панель инструментов выглядит как лучшая идея, но наш инструмент показывает, что вы не вышли за пределы низкой уверенности. Для принятия решения пока просто недостаточно информации.
Далее вы встречаетесь со своими коллегами, ответственными за разработку и UX, и вместе начинаете оценивать обе идеи. Оба проекта кажутся выполнимыми на первый взгляд. Главный разработчик предлагает грубую оценку трудозатрат: работа с панелью инструментов займет 12 человеко-недель для релиза, а с чатботом — 16 человеко-недель. В соответствии с вашей шкалой Ease это дает легкость реализации в 4 и 3 соответственно.
Параллельно вы делаете детальные вычисления. При более пристальном рассмотрении, дэшборд выглядит немного менее перспективной и получает 3. Чатбот по-прежнему выглядит на 8.
Использование инструмента доверия показывает, что обе идеи теперь проходят тест Estimates & Plans и получают некоторую уверенность. Теперь панель инструментов перемещается на 0,8 и чат-бот на 0,4.
Чатбот немного реабилитировался. Тем не менее, уровень доверия низкий по уважительной причине — это, в основном числа из ниоткуда, и вы понимаете, что нужно собрать больше доказательств.
Вы отправляете существующим клиентам опросник, предлагая им выбрать одну из 5 возможных новых функций, включая чатбот и панель инструментов. Получаете сотни ответов. Результаты очень позитивны для чатбота — это функция №1 в опроснике, и 38% респондентов выбирают ее. Dashboard занимает 3-е место с 17% голосов.
Это дает обеим функциям поддержку рынка, но показатель чатбота выше на 1,5. Для панель управления уверенность также повысилась, однако лишь до 1.
Очевидно, что чатбот сильно продвинулся вперед. Кажется, что ваши коллеги и данные индустрии доказали свою правоту. Следует ли принять эти данные как 100%? Наверное, нет — проект довольно дорогостоящий, и мы имеем всего то среднюю уверенность. К сожалению, результаты опроса не дают очень показательного сигнала. Продолжаем работать.
Чтобы узнать больше, вы запускаете пользовательское исследование на 10 существующих клиентов, показывая им интерактивные прототипы обеих фич. Параллельно вы проводите телефонные интервью с 20 участниками опроса, которые выбрали одну из двух предложенных фич.
Исследование показывает более интересную картину:
Это качественное исследование дает вам больше пищи для размышлений. Панель инструментов кажется более популярной, чем вы ожидали. Чатбот теперь больше напоминает проект с высоким уровнем риска и высокой ценой. Рассматривая наш инструмент доверия, вы присваиваете панели инструментов и чатботу значения доверия 3 и 2.5 соответственно.
Вы настраиваете влияние так: 6 для дэшборд и 9 для чатбота. Наконец, основываясь на исследовании юзабилити, вы понимаете, что получение качественного UI для чатбота потребует больше работы — вы уменьшаете Ease до 2.
Таблица снова претерпела изменения, и теперь лидирует панель инструментов.
Вы приносите результаты своей команде и вашему руководству. По результатам ICE, панель инструментов должна быть объявлена победителем, однако, с другой стороны, показатели доверия у обеих фич далеки от высоких. Не желая отпускать потенциально хорошую фичу, команда решает продолжить тестирование обеих.
Вы решаете начать с создания версии чатбота для минимально жизнеспособного продукта (MVP). Разработка занимает 6 недель, и вы запускаете MVP на 200 респондентов, которые согласились принять участие в тестировании. 167 человек активизируют фичу, но ее использование резко падает с каждым днем, и к концу второй недели у вас остается всего 24 активных пользователя.
В последующих опросах вырисовывается четкая картина — чатбот сложнее использовать, он гораздо менее полезен, чем ожидали участники, и, что еще хуже, он создает негатив у клиентов, которые ценят личный контакт.
Вы можете доработать MVP чатбота и сделать его намного полезнее для ваших клиентов, но на это нужно порядка 40-50 человеко-недель.
Также очевидно, что гораздо меньше клиентов, чем ожидалось ранее, назовут фичу полезной. Поэтому вы уменьшаете влияние с 9 до 2. Это существенно изменяет фичу, поэтому вы можете больше не доверять результатам исследования пользователей, поэтому уменьшаете доверие до 0,5 с помощью инструмента доверия.
Вы запускаете MVP панели инструментов на 200 других клиентов в течение 5 недель. Результаты очень хорошие: 87% участников используют эту фичу, многие из них ежедневно. Обратная связь в подавляющем большинстве позитивна. Вы понимаете, что влияние выше, чем вы ожидали, — 8 баллов вместо 6. Команда разработчиков оценивает, что потребуется еще 10 человеко-недель, чтобы запустить панель инструментов в полном объеме, поэтому легкость реализации получает 4. В итоге вы повышаете оценку доверия с 3 до 6,5.
К этому моменту приоритизация становится совсем простой. Теперь все согласны, что dashboard — правильная фича для развития продукта. Вы сохраняете фичу чатбота в своем банке идей, но она, естественно, будет оставаться «на дне», учитывая низкий показатель ICE.
1. Прекратите инвестировать в плохие идеи
Наш пример показывает, насколько рискованно делать ставки на фичи, которые требуют больших усилий и основаны на чувствах, мнениях, данных индустрии, тенденциях рынка и т. д. Большинство идей по факту оказываются намного менее полезными и более дорогими, чем мы думаем перед разработкой. Единственный реальный способ найти лучшие идеи — это протестировать их и снизить уровень неопределенности.
2. Беспокойтесь о выгодах, а не о результатах
Добавление этапа приоритизации фичей уменьшает скорость разработки продуктов — так кажется на первый взгляд. Но на самом деле это не уменьшает, а увеличивает скорость. Благодаря оценке уверенности вы попросту не делаете некоторые плохие фичи. Также это фокусирует команду на конкретных краткосрочных целях и увеличивает производительность команды. Этот процесс позволяет нам узнать о продукте, потребителях, рынке и в конечном итоге получить более качественный продукт, который уже был протестирован на реальных пользователями. Поэтому нас ждет меньше сюрпризов в день запуска.
3. Поощряйте многообразие подходов
На самом деле, нам часто приходится выбирать не между двумя идеями, а между десятками. Мы уменьшаем затраты на разработку идеи исходя из уверенности в ней. Это позволяет нам тестировать параллельно много разных идей и избегать ловушек, связанных с традиционным долгосрочным планированием.
В этом примере команда тестирует 4 идеи параллельно, выполняя несколько проектов (желтые квадратики), каждый из которых постепенно дорабатывает идею и тестирует ее для повышения уверенности.
4. Получите расположение руководства и заинтересованных сторон
Обычно, когда я объясняю этот метод, людей больше всего беспокоит то, как получить согласие их руководства и заинтересованных лиц на внедрение такого процесса приоритизации.
Можем ли мы ограничить их власть над продуктом? Вы удивитесь. Я много слышал от менеджеров о том, что они вынуждены погружаться в процесс принятия продуктовых решений из-за отсутствия сильных вариантов. Слабый или сильный вариант — это, конечно, понятие субъективное, но до тех пор, пока вы не увидите реальное положение дел с реальными доказательствами и четким уровнем уверенности в оценке фичи.
С другой стороны, в следующий раз, когда CEO заставит вас делать свою супер-идею, покажите ему, как оценивается идея с помощью факторов влияния, усилий и уверенности, как показатели ICE по этой идее сопоставляются с показателями других идей, и как мы можем протестировать ее для уточнения фактора уверенности.
Про недостатки метода ICE, а также про альтернативный способ приоритизации вы можете прочитать в нашей прошлой статье «RICE и ICE Scoring: простые техники приоритизации для продвинутых менеджеров продукта».
Была ли эта статья полезной для вас? Хотели бы ли вы еще прочитать материалы данного автора? Пожалуйста, расскажите об этом в комментариях.
Эта статья – перевод материала с сайта Hackernoon.com. Ее автор предлагает применение собственного инструмента оценки приоритетов в рамках метода ICE Scoring. В этой статье детально описан подход и разобран простой и доступный пример, понятный любому менеджеру продукта.
Itamar Gilad — известный консультант в области управления продуктами и успешный спикер. В его многолетнем опыте — руководящие должности по управлению продуктами в Google, Microsoft и других известных компаниях. Мы предлагаем перевод его статьи:
Допустим, вы управляете продуктом для малого бизнеса и его клиентов. Ваша цель — улучшить степень вовлеченности и удержания клиентов. У вас на повестке две идеи:
- Внедрение главной панели инструментов (dashboard), позволяющей владельцу бизнеса отслеживать статистику вовлечения и все тренды.
- Чатбот (chatbot) для автоматизации общения с клиентами.
Идея с панелью инструментов возникала несколько раз в переговорах с клиентами, и вы чувствуете, что она имеет хороший потенциал, но существует риск того, что ее будут использовать только опытные пользователи.
Идея с чатботом нравится всей компании, и руководство довольно оптимистично воспринимает ее. Также фича выглядит выигрышной и для клиентов.
Что бы вы выбрали?
Этот вопросы приоритизации лежат в основе управления продуктом. Плата за неправильный выбор может оказаться весьма большой и включать стоимость разработки, деплоймента, обслуживания, а также другие внеплановые затраты.
Мы часто испытываем соблазн принять решение на основе неубедительных сигналов: мнения большинства, мнения начальников, отраслевых тенденций и т. д. Но время показывает, что эти сигналы по точности находятся на уровне генератора случайных чисел.
Этот пост о том, как, на мой взгляд, находить лучшие идеи. Он состоит из трех частей:
- Показатели ICE
- Уровни доверия
- Дополнительная проверка
ICE Scoring
ICE Scoring — это метод определения приоритетов, который впервые использовал Шон Эллис, известный своим активным участием в становлении таких компаний, как DropBox и Eventbrite, и продвижении термина Growth Hacking. ICE первоначально был предназначен для определения приоритетов в growth экспериментах, но вскоре стал использоваться для оценки любых идей.
В ICE вы оцениваете идеи таким образом:
- Влияние демонстрирует, насколько идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.
- Легкость реализации или простота — это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
- Уверенность демонстрирует, насколько вы уверены в оценках влияния и легкости реализации.
Значения в ICE оцениваются по шкале от 1 до 10, чтобы все факторы сбалансировано повлияли на итоговое число. Под значениями 1-10 можно подразумевать все что угодно, главное, чтобы значения были согласованы между собой.
Теперь давайте на примере посмотрим, как это работает.
Сперва ICE
Итак, вы решили рассчитать баллы по ICE для двух идей: dashboard и чатбота. На этом раннем этапе вы используете грубые значения исключительно на основе собственной интуиции.
Влияние — вы предполагаете, что дэшборд значительно увеличит удержание пользователей, но только опытных, — вы даете 5 из 10. Чатбот, с другой стороны, может стать инновационным решением для многих клиентов, поэтому вы даете ему 8 из 10.
Легкость реализации — вы оцениваете, что для dashboard потребуется 10 человеко-недель, а для чат-бота — 20. Позже от команды вы получите более качественные оценки. Вы используете эту простую таблицу (выбранную вами и вашей командой) для преобразования вашей оценки в Ease:
Таким образом, панель инструментов получает значение Ease 4 из 10 и чатбот — значение 2.
Вычисление уверенности
Существует только один способ рассчитать уверенность — это поиск подтверждающих доказательств. Для этого я создал инструмент, который можно увидеть ниже. В нем перечислены общие типы тестов и доказательств, которые могут быть у вас, и уровень уверенности, который они предоставляют: результаты тестов, дата лонча, собственная уверенность, тематическая поддержка, мнение других людей, данные рынка и др.
При использовании инструмента учитывайте, какие показатели у вас уже есть, сколько из них и что вам нужно, чтобы получить больше уверенности.
Если в вашем продукте или в отрасли возможна другая проверка доказательств, не стесняйтесь создавать свою собственную версию этого инструмента.
Вернемся к примеру, чтобы оценить инструмент в действии.
Поддержка доказательств для чатбота: личная уверенность (вы думаете, что это хорошая идея), тематическая поддержка (в индустрии также считают, что это хорошая идея) и мнение других (ваше начальство и коллеги считают это хорошей идеей). Это дает ему общее доверительное значение 0,1 из 10 или Near Zero Confidence. Инструмент явно не считает мнения надежным индикатором.
Что по поводу dashboard? Здесь личная уверенность (вы думаете, что это хорошая идея) и эпизодическая поддержка (несколько клиентов попросили об этом). Это фактически повышает его доверительное значение до 0,5 из 10, что является низким доверием. К сожалению, клиенты плохо прогнозируют свое будущее поведение.
ICE scoring в этом случае:
К этому моменту панель инструментов выглядит как лучшая идея, но наш инструмент показывает, что вы не вышли за пределы низкой уверенности. Для принятия решения пока просто недостаточно информации.
Проверка оценки и осуществимости
Далее вы встречаетесь со своими коллегами, ответственными за разработку и UX, и вместе начинаете оценивать обе идеи. Оба проекта кажутся выполнимыми на первый взгляд. Главный разработчик предлагает грубую оценку трудозатрат: работа с панелью инструментов займет 12 человеко-недель для релиза, а с чатботом — 16 человеко-недель. В соответствии с вашей шкалой Ease это дает легкость реализации в 4 и 3 соответственно.
Параллельно вы делаете детальные вычисления. При более пристальном рассмотрении, дэшборд выглядит немного менее перспективной и получает 3. Чатбот по-прежнему выглядит на 8.
Использование инструмента доверия показывает, что обе идеи теперь проходят тест Estimates & Plans и получают некоторую уверенность. Теперь панель инструментов перемещается на 0,8 и чат-бот на 0,4.
Чатбот немного реабилитировался. Тем не менее, уровень доверия низкий по уважительной причине — это, в основном числа из ниоткуда, и вы понимаете, что нужно собрать больше доказательств.
Данные рынка
Вы отправляете существующим клиентам опросник, предлагая им выбрать одну из 5 возможных новых функций, включая чатбот и панель инструментов. Получаете сотни ответов. Результаты очень позитивны для чатбота — это функция №1 в опроснике, и 38% респондентов выбирают ее. Dashboard занимает 3-е место с 17% голосов.
Это дает обеим функциям поддержку рынка, но показатель чатбота выше на 1,5. Для панель управления уверенность также повысилась, однако лишь до 1.
Очевидно, что чатбот сильно продвинулся вперед. Кажется, что ваши коллеги и данные индустрии доказали свою правоту. Следует ли принять эти данные как 100%? Наверное, нет — проект довольно дорогостоящий, и мы имеем всего то среднюю уверенность. К сожалению, результаты опроса не дают очень показательного сигнала. Продолжаем работать.
Слово клиентам
Чтобы узнать больше, вы запускаете пользовательское исследование на 10 существующих клиентов, показывая им интерактивные прототипы обеих фич. Параллельно вы проводите телефонные интервью с 20 участниками опроса, которые выбрали одну из двух предложенных фич.
Исследование показывает более интересную картину:
- 8 из 10 участников исследования нашли полезной dashboard и сказали, что будут использовать ее не реже одного раза в неделю. Их понимание этой функции хорошо коррелировало с тем, что вы имели ввиду изначально, и у них не было проблем с ее использованием. Телефонные интервью подтвердили понимание и желание использовать фичу в среднем один раз в неделю.
- 9 из 10 участников исследования сказали, что они будут охотно использовать чатбот. Их уровень энтузиазма был очень высоким — каждый сразу понял, почему это может быть полезно и многие попросили его как можно скорее. Однако были проблемы с удобством использования, а некоторые клиенты высказывали озабоченность по поводу того, что их клиентам не понравятся повторяющиеся и «заезженные» ответы бота.
Это качественное исследование дает вам больше пищи для размышлений. Панель инструментов кажется более популярной, чем вы ожидали. Чатбот теперь больше напоминает проект с высоким уровнем риска и высокой ценой. Рассматривая наш инструмент доверия, вы присваиваете панели инструментов и чатботу значения доверия 3 и 2.5 соответственно.
Вы настраиваете влияние так: 6 для дэшборд и 9 для чатбота. Наконец, основываясь на исследовании юзабилити, вы понимаете, что получение качественного UI для чатбота потребует больше работы — вы уменьшаете Ease до 2.
Таблица снова претерпела изменения, и теперь лидирует панель инструментов.
Вы приносите результаты своей команде и вашему руководству. По результатам ICE, панель инструментов должна быть объявлена победителем, однако, с другой стороны, показатели доверия у обеих фич далеки от высоких. Не желая отпускать потенциально хорошую фичу, команда решает продолжить тестирование обеих.
Заключительные тесты и победитель!
Вы решаете начать с создания версии чатбота для минимально жизнеспособного продукта (MVP). Разработка занимает 6 недель, и вы запускаете MVP на 200 респондентов, которые согласились принять участие в тестировании. 167 человек активизируют фичу, но ее использование резко падает с каждым днем, и к концу второй недели у вас остается всего 24 активных пользователя.
В последующих опросах вырисовывается четкая картина — чатбот сложнее использовать, он гораздо менее полезен, чем ожидали участники, и, что еще хуже, он создает негатив у клиентов, которые ценят личный контакт.
Вы можете доработать MVP чатбота и сделать его намного полезнее для ваших клиентов, но на это нужно порядка 40-50 человеко-недель.
Также очевидно, что гораздо меньше клиентов, чем ожидалось ранее, назовут фичу полезной. Поэтому вы уменьшаете влияние с 9 до 2. Это существенно изменяет фичу, поэтому вы можете больше не доверять результатам исследования пользователей, поэтому уменьшаете доверие до 0,5 с помощью инструмента доверия.
Вы запускаете MVP панели инструментов на 200 других клиентов в течение 5 недель. Результаты очень хорошие: 87% участников используют эту фичу, многие из них ежедневно. Обратная связь в подавляющем большинстве позитивна. Вы понимаете, что влияние выше, чем вы ожидали, — 8 баллов вместо 6. Команда разработчиков оценивает, что потребуется еще 10 человеко-недель, чтобы запустить панель инструментов в полном объеме, поэтому легкость реализации получает 4. В итоге вы повышаете оценку доверия с 3 до 6,5.
К этому моменту приоритизация становится совсем простой. Теперь все согласны, что dashboard — правильная фича для развития продукта. Вы сохраняете фичу чатбота в своем банке идей, но она, естественно, будет оставаться «на дне», учитывая низкий показатель ICE.
Выводы
1. Прекратите инвестировать в плохие идеи
Наш пример показывает, насколько рискованно делать ставки на фичи, которые требуют больших усилий и основаны на чувствах, мнениях, данных индустрии, тенденциях рынка и т. д. Большинство идей по факту оказываются намного менее полезными и более дорогими, чем мы думаем перед разработкой. Единственный реальный способ найти лучшие идеи — это протестировать их и снизить уровень неопределенности.
2. Беспокойтесь о выгодах, а не о результатах
Добавление этапа приоритизации фичей уменьшает скорость разработки продуктов — так кажется на первый взгляд. Но на самом деле это не уменьшает, а увеличивает скорость. Благодаря оценке уверенности вы попросту не делаете некоторые плохие фичи. Также это фокусирует команду на конкретных краткосрочных целях и увеличивает производительность команды. Этот процесс позволяет нам узнать о продукте, потребителях, рынке и в конечном итоге получить более качественный продукт, который уже был протестирован на реальных пользователями. Поэтому нас ждет меньше сюрпризов в день запуска.
3. Поощряйте многообразие подходов
На самом деле, нам часто приходится выбирать не между двумя идеями, а между десятками. Мы уменьшаем затраты на разработку идеи исходя из уверенности в ней. Это позволяет нам тестировать параллельно много разных идей и избегать ловушек, связанных с традиционным долгосрочным планированием.
В этом примере команда тестирует 4 идеи параллельно, выполняя несколько проектов (желтые квадратики), каждый из которых постепенно дорабатывает идею и тестирует ее для повышения уверенности.
4. Получите расположение руководства и заинтересованных сторон
Обычно, когда я объясняю этот метод, людей больше всего беспокоит то, как получить согласие их руководства и заинтересованных лиц на внедрение такого процесса приоритизации.
Можем ли мы ограничить их власть над продуктом? Вы удивитесь. Я много слышал от менеджеров о том, что они вынуждены погружаться в процесс принятия продуктовых решений из-за отсутствия сильных вариантов. Слабый или сильный вариант — это, конечно, понятие субъективное, но до тех пор, пока вы не увидите реальное положение дел с реальными доказательствами и четким уровнем уверенности в оценке фичи.
С другой стороны, в следующий раз, когда CEO заставит вас делать свою супер-идею, покажите ему, как оценивается идея с помощью факторов влияния, усилий и уверенности, как показатели ICE по этой идее сопоставляются с показателями других идей, и как мы можем протестировать ее для уточнения фактора уверенности.
Про недостатки метода ICE, а также про альтернативный способ приоритизации вы можете прочитать в нашей прошлой статье «RICE и ICE Scoring: простые техники приоритизации для продвинутых менеджеров продукта».
Была ли эта статья полезной для вас? Хотели бы ли вы еще прочитать материалы данного автора? Пожалуйста, расскажите об этом в комментариях.
