А теперь отвлечемся от USM и резко, бешено вспомним, как выглядит типовой CJM:
1. Берем сегмент ЦА/персону и определяем основные этапы его взаимодействия с продуктом (ну, там, Ознакомление->Поиск товара->Знакомство с товаром->Оформление покупки->Ожидание->Получение и обратная связь)
2. Расписываем для каждого этапа, что пользователь хочет делать (найти товар, заказать товар, поругаться по поводу товара)
3. Для каждой из хотелок пользователя указываем, какие решения нам надо разработать для того, чтобы пользователь максимально безболезненно прошел свой сценарий
4. Попутно выписываем проблемы/боли/конфликты, которые возникают на всем протяжении сценария.
В итоге у вас получится вот такая штука:
1. Берем сегмент ЦА/персону и определяем основные этапы его взаимодействия с продуктом (ну, там, Ознакомление->Поиск товара->Знакомство с товаром->Оформление покупки->Ожидание->Получение и обратная связь)
2. Расписываем для каждого этапа, что пользователь хочет делать (найти товар, заказать товар, поругаться по поводу товара)
3. Для каждой из хотелок пользователя указываем, какие решения нам надо разработать для того, чтобы пользователь максимально безболезненно прошел свой сценарий
4. Попутно выписываем проблемы/боли/конфликты, которые возникают на всем протяжении сценария.
В итоге у вас получится вот такая штука:
Тут у вас должно зашевелиться нехорошее ощущение - что USM и CJM, мягко говоря, слабо отличаются друг от друга:
1. В USM есть разбивка на релизы и может быть разбивка на технические таски для разработки
2. В CJM есть акцент на пользовательские проблемы
3. В CJM идет упор на «Что пользователь хочет» (т.е. мы исходим из желаний пользователя, а не его действий), в USM же допустимо указывать и то, что пользователь хочет - и что он непосредственно делает.
Поясню: в CJM недопустимо писать что-то вида «Пользователь хочет: зарегистрироваться» (ни один пользователь в своем уме не хочет этого делать, это мы от него хотим), а вот при заполнении USM можно в User Tasks спокойно написать «Пользователь регистрируется» - и дальше писать фичи для реализации этой задачи.
«ОК ОК ОК CJM И USM ПОХОЖИ НО ВСЕ ТАКИ РАЗНЫЕ,» - скажете вы, а я в ответ дьявольски захохочу и предложу вам выполнить вот такое мысленное упражнение:
1. Берем наш CJM.
2. Как мы помним, CJM - это пластичная штука-конструктор, которая позволяет навешивать любые дополнительные уточнения. Поэтому дополним CJM графой «Что пользователь должен делать», чтобы мы могли более явно провести логическую цепочку «Пользователь хочет заказать товар - значит, пользователь должен зарегистрироваться»
3. Берем графу «Чем мы помогаем» (которая с фичами) и разбиваем ее на релизы.
Получаем вот такого супермутанта - который при этом формально остается вполне себе CJM, пусть и с дополнительными обвесами:
1. В USM есть разбивка на релизы и может быть разбивка на технические таски для разработки
2. В CJM есть акцент на пользовательские проблемы
3. В CJM идет упор на «Что пользователь хочет» (т.е. мы исходим из желаний пользователя, а не его действий), в USM же допустимо указывать и то, что пользователь хочет - и что он непосредственно делает.
Поясню: в CJM недопустимо писать что-то вида «Пользователь хочет: зарегистрироваться» (ни один пользователь в своем уме не хочет этого делать, это мы от него хотим), а вот при заполнении USM можно в User Tasks спокойно написать «Пользователь регистрируется» - и дальше писать фичи для реализации этой задачи.
«ОК ОК ОК CJM И USM ПОХОЖИ НО ВСЕ ТАКИ РАЗНЫЕ,» - скажете вы, а я в ответ дьявольски захохочу и предложу вам выполнить вот такое мысленное упражнение:
1. Берем наш CJM.
2. Как мы помним, CJM - это пластичная штука-конструктор, которая позволяет навешивать любые дополнительные уточнения. Поэтому дополним CJM графой «Что пользователь должен делать», чтобы мы могли более явно провести логическую цепочку «Пользователь хочет заказать товар - значит, пользователь должен зарегистрироваться»
3. Берем графу «Чем мы помогаем» (которая с фичами) и разбиваем ее на релизы.
Получаем вот такого супермутанта - который при этом формально остается вполне себе CJM, пусть и с дополнительными обвесами:
🔥3
И в итоге получается, что CJM путем пинков и нехитрых расширений можно превратить в полноценный User Story Mapping! Публика в шоке, фокусник вытащил шляпу из кролика и засунул льва к себе в пасть.
То есть можно спокойно считать, что USM - это подкрученный и детализированный CJM, и это не какие-то там отдаленно схожие, но разные форматы, а вообще одно и то же. Это сценарное представление, которое просто ставит разные акценты: классическое представление CJM больше нацелено на проработку пользовательского сценария, а представление USM скорее необходимо для технической детализации и приоритизации.
Но корневая суть их едина и неделима. Это все один и тот же сценарий.
P.S. В качестве десерта закидываю вам вопрос «А что же тогда такое Service Blueprint» - вы не поверите ответу!
#сжм
То есть можно спокойно считать, что USM - это подкрученный и детализированный CJM, и это не какие-то там отдаленно схожие, но разные форматы, а вообще одно и то же. Это сценарное представление, которое просто ставит разные акценты: классическое представление CJM больше нацелено на проработку пользовательского сценария, а представление USM скорее необходимо для технической детализации и приоритизации.
Но корневая суть их едина и неделима. Это все один и тот же сценарий.
P.S. В качестве десерта закидываю вам вопрос «А что же тогда такое Service Blueprint» - вы не поверите ответу!
#сжм
🔥1
Сижу я, мирно пишу для вас давно обещанную телегу по ICE и RICE, и тут мои хрустальные, нежные мысли прерывает вот такое БОМБАЛЕЙЛО ЛЁХА ОТКЛАДЫВАЙ ПЕРО В СТОРОНУ ВСТАВАЙ ВОЙНА НАЧАЛАСЬ В ВОРОТА НЕВЕДОМАЯ ХЕРНЯ ЛЕЗЕТ ГДЕ ТВОЙ ЛАЗЕРНЫЙ МЕЧ АГА ПОЕХАЛИ!!!!
В чем суть картинки: вот эти уважаемые господа, неуловимо похожие на актера Джека Николсона из кинофильма «Сияние», прилюдно сравнивают Jobs To Be Done с CustDev и приходят к сладострастному выводу, что JTBD лучше жалкого, обрубочного кастдева и помогает строить полновесные продуктовые стратегии.
Когда мне прислали эту картинку, я поперхнулся не то что чаем - собственным мозгом, и решил сделать вам прививку мудрости, чтобы вы, не дай Бог, не подхватили газовую гангрену хуикс-цыганщины и не окончили свою жизнь в позоре, под мостом, в коробке из-под телевизора.
Начнем с базы.
Что такое JTBD? Это способ разложить возможности вашего продукта по полочкам, где каждая возможность формулируется в духе «Находясь в таком-то контексте, я хочу делать что-то, чтобы достичь чего-то».
Например: «Находясь в пьяном состоянии пятничным вечером, я хочу быстро и просто вызвать такси, чтобы безопасно попасть домой и не уехать на алкоприключения»
Или: «Находясь в состоянии бомбалейло, я хочу навалять лещей инфоцыганам, чтобы успокоиться и хоть как-то восстановить гармонию в мире».
Мы изучаем нашу аудиторию и ее потребности, на этой основе составляем кучу джобов - и, вуаля, готов список потребностей наших клиентов, на котором мы можем построить продукт.
При этом не важно, кем ты являешься (архаровец, тургеневская барышня, негр преклонных лет) - важен только контекст, в котором ты находишься, твои задачи и конечные цели. По своей сути JTBD представляет собой упрощенный, огрубленный и упрощенный кусок Goal-Directed подхода дедушки Алана Купера, который отталкивается от глубокого знания аудитории, ее особенностей и множества конкретных деталей, выражаемых в персонах, User Story, CJM и прочих нажористых штуках и артефактах.
Когда мне прислали эту картинку, я поперхнулся не то что чаем - собственным мозгом, и решил сделать вам прививку мудрости, чтобы вы, не дай Бог, не подхватили газовую гангрену хуикс-цыганщины и не окончили свою жизнь в позоре, под мостом, в коробке из-под телевизора.
Начнем с базы.
Что такое JTBD? Это способ разложить возможности вашего продукта по полочкам, где каждая возможность формулируется в духе «Находясь в таком-то контексте, я хочу делать что-то, чтобы достичь чего-то».
Например: «Находясь в пьяном состоянии пятничным вечером, я хочу быстро и просто вызвать такси, чтобы безопасно попасть домой и не уехать на алкоприключения»
Или: «Находясь в состоянии бомбалейло, я хочу навалять лещей инфоцыганам, чтобы успокоиться и хоть как-то восстановить гармонию в мире».
Мы изучаем нашу аудиторию и ее потребности, на этой основе составляем кучу джобов - и, вуаля, готов список потребностей наших клиентов, на котором мы можем построить продукт.
При этом не важно, кем ты являешься (архаровец, тургеневская барышня, негр преклонных лет) - важен только контекст, в котором ты находишься, твои задачи и конечные цели. По своей сути JTBD представляет собой упрощенный, огрубленный и упрощенный кусок Goal-Directed подхода дедушки Алана Купера, который отталкивается от глубокого знания аудитории, ее особенностей и множества конкретных деталей, выражаемых в персонах, User Story, CJM и прочих нажористых штуках и артефактах.
👍7🔥5❤3
Не подумайте плохо - я не называю JTBD лютой херней, но твердо считаю, что эта методика сильно упрощает реальное положение вещей, а потому применима не во всех случаях. Это не какое-то Божье Откровение или универсальная Модель Всего - это методика, применимая для сильно разлапистых продуктов с размытой аудиторией в условиях лютого дефицита информации. Она в разы проще, чем погружение в аудиторию по Куперу - и в этом ее сила и слабость. И за это ее, как подозреваю, особо любят разные цыгане - если про что-то проще затереть, то это и проще продать.
Теперь ответим на вопрос - а что же такое CustDev? Кастдев - это сложный, многоступенчатый процесс выявления и подтверждения потребностей и инсайтов у аудитории с целью улучшения продукта. Этот процесс включает в себя и проведение исследований (как качественных, так и количественных, от глубинных интервью до опросов), и формулирование гипотез, и их проверку, и охватывает, по сути, всю пользовательскую сторону продукта - от «У нас тут есть идея, давайте сходим к аудитории и проверим» до «Кажется, наш продукт идет не туда, давайте менять курс».
Иногда кастдевом называют глубинные (и не очень) интервью где-то перед этапом дизайна - но так нельзя делать. Это или некорректный жаргонизм (я и сам, каюсь, им в свое время злоупотреблял), или признак интеллектуального увечья. Кастдев куда сложнее.
И вот возвращаемся к моему бомбалейло. Хлопцы с обаянием Джека Николсона предлагают сравнить между собой перекрашенный кусок Алана Купера, предназначенный для первичного разбора состава вашего продукта, и сложную методологию, которая включает в себя безумное количество активностей вокруг вашего продукта - и, сука, приходят к выводу, что JTBD формирует РЫНОЧНУЮ СТРАТЕГИЮ ПРОДУКТА, а CustDev видится ОБРУБОЧНЫМ решением, после чего на серьезных щах делают вывод «Полезно узнавать информацию даже у тех клиентов, у которых, казалось бы, и нечего спрашивать». Серьезно?!
Обрубленная, узкоспециализированная метода объявляется охереть каким планомерным подходом, а сложная, как космос, методика подхода к аудитории - кутылым обрубком. Война - это мир, свобода - это рабство.
Не говоря уже о том, что между собой сравнивается не то что теплое с мягким - а порнография с варежкой. JBTD - фактически, жонглирование списком специфически сформулированных задач - ставят во главу продуктовой, маркетинговой и рыночной стратегии. Не пользователей, их потребности, конкурентную специфику, экономическую ситуацию - а набор тезисов, который предназначен вообще не для этого. Сука, давайте теперь продуктовую стратегию на базе дизайн-макета малевать, чего уж мелочиться.
Теперь ответим на вопрос - а что же такое CustDev? Кастдев - это сложный, многоступенчатый процесс выявления и подтверждения потребностей и инсайтов у аудитории с целью улучшения продукта. Этот процесс включает в себя и проведение исследований (как качественных, так и количественных, от глубинных интервью до опросов), и формулирование гипотез, и их проверку, и охватывает, по сути, всю пользовательскую сторону продукта - от «У нас тут есть идея, давайте сходим к аудитории и проверим» до «Кажется, наш продукт идет не туда, давайте менять курс».
Иногда кастдевом называют глубинные (и не очень) интервью где-то перед этапом дизайна - но так нельзя делать. Это или некорректный жаргонизм (я и сам, каюсь, им в свое время злоупотреблял), или признак интеллектуального увечья. Кастдев куда сложнее.
И вот возвращаемся к моему бомбалейло. Хлопцы с обаянием Джека Николсона предлагают сравнить между собой перекрашенный кусок Алана Купера, предназначенный для первичного разбора состава вашего продукта, и сложную методологию, которая включает в себя безумное количество активностей вокруг вашего продукта - и, сука, приходят к выводу, что JTBD формирует РЫНОЧНУЮ СТРАТЕГИЮ ПРОДУКТА, а CustDev видится ОБРУБОЧНЫМ решением, после чего на серьезных щах делают вывод «Полезно узнавать информацию даже у тех клиентов, у которых, казалось бы, и нечего спрашивать». Серьезно?!
Обрубленная, узкоспециализированная метода объявляется охереть каким планомерным подходом, а сложная, как космос, методика подхода к аудитории - кутылым обрубком. Война - это мир, свобода - это рабство.
Не говоря уже о том, что между собой сравнивается не то что теплое с мягким - а порнография с варежкой. JBTD - фактически, жонглирование списком специфически сформулированных задач - ставят во главу продуктовой, маркетинговой и рыночной стратегии. Не пользователей, их потребности, конкурентную специфику, экономическую ситуацию - а набор тезисов, который предназначен вообще не для этого. Сука, давайте теперь продуктовую стратегию на базе дизайн-макета малевать, чего уж мелочиться.
🔥18👍9❤1
Все настолько слеплено в кошмарный тухлый блин, что я всерьез размышляю о проведении серии митапов, где расскажу:
- Что лучше - метод персонажей или screen flow?
- Что полезнее для продукта - глубинные интервью или метрики?
- Что сделать первым - прототип или вайрфрейм?
- Что важнее - прибыль или юнит-экономика?
Хотя нет, не расскажу. Я даже шутить на эту тему не могу, мозг сразу сводит от бешенства.
Ну и в заключение вот вам несколько золотых твитов от дедушки Купера, где он отвечает на схожий вброс «СМОТРИТЕ-КА JTBD ЭТО ЛУЧШАЯ ЗАМЕНА ВАШЕМУ МЕТОДУ ПЕРСОН». На этом, пожалуй, и остановимся.
#бомбаж
- Что лучше - метод персонажей или screen flow?
- Что полезнее для продукта - глубинные интервью или метрики?
- Что сделать первым - прототип или вайрфрейм?
- Что важнее - прибыль или юнит-экономика?
Хотя нет, не расскажу. Я даже шутить на эту тему не могу, мозг сразу сводит от бешенства.
Ну и в заключение вот вам несколько золотых твитов от дедушки Купера, где он отвечает на схожий вброс «СМОТРИТЕ-КА JTBD ЭТО ЛУЧШАЯ ЗАМЕНА ВАШЕМУ МЕТОДУ ПЕРСОН». На этом, пожалуй, и остановимся.
#бомбаж
👍4
Ну што, котаны, пацан сказал - пацан сделал. Продолжаем разговор за приоритизацию!
Щас будет жирно, запасайтесь едой и захватите одеяло.
В прошлые разы мы говорили с вами про простейшую раскладку идей по полкам (которой позавидовала бы и иная Галина Петровна из «Пятерочки»), а сейчас переходим к более замысловатым инструментам.
Представьте себе такую ситуацию - у вас дохера продуктовых идей: больших, маленьких, перспективных, тухлых и совсем золотых разряда «ИВАН МАКСИМЫЧ ДАВЕЧА ОЧЕНЬ ПРОСИЛИ СДЕЛАТЬ». Задачи разные и, что хуже всего, никак не совмещаются друг с другом. Одно дело решать, сделать ли в продукте первым каталог товаров или корзину, а другое - выбирать между «Сделать кнопку КУПИТЬ заметнее» и «Внедрить систему персональных рекомендаций в зависимости от вкусов покупателя, фаз Луны и наличия ретроградного Меркурия в Уране». Что делать - непонятно.
В этот момент на горизонте обычно появляется веселый усач из коммерции и, похохатывая, одаривает золотой идеей: «ПЕТРУША СЧИТАЙ БАБЛО».
ОК, считаем бабло. Вы садитесь за абак и подсчитываете, что самой баблоносной идеей будет вышеупомянутая система рекомендаций Ретроградного Меркурия. Веселый усач из коммерции одобрительно кивает и уходит по своим купеческим делам, а вы чешете репу: бабло баблом, но, во-первых, разработка этой фичи займет дохренища времени и влетит в адскую копеечку, а во-вторых - вы просто не верите, что эта история в принципе взлетит. То есть метод веселого усача «СЧИТАЙ БАБЛО» грозит загнать вас в натуральную продуктовую могилу.
И тут, друзья мои, на арену нашего хуистического цирка выкатываются два родственных метода, которые спасут ваши нервы - это ICE и RICE. На глазах у шокированной публики мы подробно разберем, в чем они заключаются - и какой жопой грозят, если с ними плохо работать.
Метод ICE прост как ледянка (оценили, а?), но требует определенной сноровки. Смотрите:
1. Сперва мозгуем, какую сверхзадачу мы хотим решить и какая метрика для нас является ключевой - рост определенной конверсии, лояльной аудитории, среднего чека, оборота и т.п. Мы пытаемся выявить Царь-Метрику, которая будет для нас главной на данном этапе. Очень важно не выбирать несколько показателей (типа, хотим и конверсию повыше, и рост аудитории, и…) - базовый ICE этого не любит и начинает давать на выходе лажу. Выбирайте по возможности что-то одно, основное.
2. Дальше мы берем наши идеи (сиречь гипотезы, зачатки будущих задач) и аккуратно заносим их в таблицу.
3. Для каждой идеи/гипотезы прикидываем три цифры - каждая от 1 до 10:
Щас будет жирно, запасайтесь едой и захватите одеяло.
В прошлые разы мы говорили с вами про простейшую раскладку идей по полкам (которой позавидовала бы и иная Галина Петровна из «Пятерочки»), а сейчас переходим к более замысловатым инструментам.
Представьте себе такую ситуацию - у вас дохера продуктовых идей: больших, маленьких, перспективных, тухлых и совсем золотых разряда «ИВАН МАКСИМЫЧ ДАВЕЧА ОЧЕНЬ ПРОСИЛИ СДЕЛАТЬ». Задачи разные и, что хуже всего, никак не совмещаются друг с другом. Одно дело решать, сделать ли в продукте первым каталог товаров или корзину, а другое - выбирать между «Сделать кнопку КУПИТЬ заметнее» и «Внедрить систему персональных рекомендаций в зависимости от вкусов покупателя, фаз Луны и наличия ретроградного Меркурия в Уране». Что делать - непонятно.
В этот момент на горизонте обычно появляется веселый усач из коммерции и, похохатывая, одаривает золотой идеей: «ПЕТРУША СЧИТАЙ БАБЛО».
ОК, считаем бабло. Вы садитесь за абак и подсчитываете, что самой баблоносной идеей будет вышеупомянутая система рекомендаций Ретроградного Меркурия. Веселый усач из коммерции одобрительно кивает и уходит по своим купеческим делам, а вы чешете репу: бабло баблом, но, во-первых, разработка этой фичи займет дохренища времени и влетит в адскую копеечку, а во-вторых - вы просто не верите, что эта история в принципе взлетит. То есть метод веселого усача «СЧИТАЙ БАБЛО» грозит загнать вас в натуральную продуктовую могилу.
И тут, друзья мои, на арену нашего хуистического цирка выкатываются два родственных метода, которые спасут ваши нервы - это ICE и RICE. На глазах у шокированной публики мы подробно разберем, в чем они заключаются - и какой жопой грозят, если с ними плохо работать.
Метод ICE прост как ледянка (оценили, а?), но требует определенной сноровки. Смотрите:
1. Сперва мозгуем, какую сверхзадачу мы хотим решить и какая метрика для нас является ключевой - рост определенной конверсии, лояльной аудитории, среднего чека, оборота и т.п. Мы пытаемся выявить Царь-Метрику, которая будет для нас главной на данном этапе. Очень важно не выбирать несколько показателей (типа, хотим и конверсию повыше, и рост аудитории, и…) - базовый ICE этого не любит и начинает давать на выходе лажу. Выбирайте по возможности что-то одно, основное.
2. Дальше мы берем наши идеи (сиречь гипотезы, зачатки будущих задач) и аккуратно заносим их в таблицу.
3. Для каждой идеи/гипотезы прикидываем три цифры - каждая от 1 до 10:
👍17❤2
- Impact (эффект) - насколько реализация гипотезы повлияет на Царь-Метрику. 10 - повлияет максимально, 1 - не повлияет ваще никак. Что именно считать за 10 - вопрос не всегда простой, но старайтесь определять потолок по самой мощной в плане метрик задаче с запасом сверху.
- Confidence (уверенность) - насколько вы и ваша команда верите в то, что ваша идея действительно выстрелит, а не превратится в тыкву (что в продукте совершенно нормальная история). 10 - МАМОЙ КЛЯНУСЬ СРАБОТАЕТ, 1 - ОТКУДА ВЫ ВООБЩЕ ЭТОТ МУСОР ВЗЯЛИ. Важный момент: веру в гипотезу оценивайте узким осведомленным продуктовым кругом. Чем больше левых людей будут вовлечено в оценку Confidence, тем выше шанс, что вы получите на выходе вялую пятерку по всем вашим гипотезам. Правило простое: кто берет ответственность за задачу, тот в нее и верит.
Еще важный момент - включайте в понятие "уверенность" не только вашу эмоциональную веру, но и наличие обоснований вашей гипотезы - есть ли аналитика, подтверждение со стороны конкурентов и так далее. Вера не должна быть слепой.
- Easiness (простота) - насколько легко эту задачу сделать. 10 - «можно сделать настолько быстро, что оно уже готово, пока вы записывали название задачи», 1 - «ОТ ПОЛУГОДА ДО ГОДА» (вспомнилось: был у меня когда-то техдир Серега по прозвищу Магадан, у него и его тимлида по кличке «Кожаная Балерина» все оценки такие были. Но не будем об этом сейчас). Тут, как и при оценке Impact, за 10 можно брать самую простенькую задач.
Общее правило при просчете всех трех параметров - не зарывайтесь слишком в детали. Сила ICE - в скорости и простоте, и если вы оцените какую-то задачу не на 6, а на, о Боже мой, 8 - никто вас ругать не будет, метод от этого не развалится.
4. Далее считаем для каждой идеи главный параметр ICE Score - просто перемножая Impact, Confidence и Easiness. Этот параметр и будет показывать, какая задача у вас главная.
5. Теперь осталось отсортировать список задач по ICE Score в порядке убывания - и, вуаля, вот он ваш отприоритизированный бэклог (в примере мы влияем типа на конверсию):
- Confidence (уверенность) - насколько вы и ваша команда верите в то, что ваша идея действительно выстрелит, а не превратится в тыкву (что в продукте совершенно нормальная история). 10 - МАМОЙ КЛЯНУСЬ СРАБОТАЕТ, 1 - ОТКУДА ВЫ ВООБЩЕ ЭТОТ МУСОР ВЗЯЛИ. Важный момент: веру в гипотезу оценивайте узким осведомленным продуктовым кругом. Чем больше левых людей будут вовлечено в оценку Confidence, тем выше шанс, что вы получите на выходе вялую пятерку по всем вашим гипотезам. Правило простое: кто берет ответственность за задачу, тот в нее и верит.
Еще важный момент - включайте в понятие "уверенность" не только вашу эмоциональную веру, но и наличие обоснований вашей гипотезы - есть ли аналитика, подтверждение со стороны конкурентов и так далее. Вера не должна быть слепой.
- Easiness (простота) - насколько легко эту задачу сделать. 10 - «можно сделать настолько быстро, что оно уже готово, пока вы записывали название задачи», 1 - «ОТ ПОЛУГОДА ДО ГОДА» (вспомнилось: был у меня когда-то техдир Серега по прозвищу Магадан, у него и его тимлида по кличке «Кожаная Балерина» все оценки такие были. Но не будем об этом сейчас). Тут, как и при оценке Impact, за 10 можно брать самую простенькую задач.
Общее правило при просчете всех трех параметров - не зарывайтесь слишком в детали. Сила ICE - в скорости и простоте, и если вы оцените какую-то задачу не на 6, а на, о Боже мой, 8 - никто вас ругать не будет, метод от этого не развалится.
4. Далее считаем для каждой идеи главный параметр ICE Score - просто перемножая Impact, Confidence и Easiness. Этот параметр и будет показывать, какая задача у вас главная.
5. Теперь осталось отсортировать список задач по ICE Score в порядке убывания - и, вуаля, вот он ваш отприоритизированный бэклог (в примере мы влияем типа на конверсию):
👍16
Ссылка на табличку: https://docs.google.com/spreadsheets/d/1PON1VgQV7snIDTicT1QpBivKlGsL_yebcURBBWyZt_o/edit?usp=sharing
Я люблю ICE за его простоту и способность работать даже в обстановке полного ХЗ, но у него есть свои ограничения. Первое - он с трудом срабатывает в случае, если ваши идеи нацелены на разные сегменты аудитории и охватывают разные числа пользователей. Да, это можно включать в нашу оценку Impact, но иногда это приводит к вывиху мозга. В таком случае лучше воспользоваться второй родственной методикой - RICE.
Общая логика RICE ОЧЕНЬ похожа на ICE, но у него есть свои прибабахи. Вот что нужно сделать:
1. Выделить Царь-Метрику, на которую мы хотим повлиять. Тут см. п.1 в ICE - все то же самое.
2. Заносим идеи в табличку. Опять-таки, как в ICE.
3. Для каждой гипотезы оцениваем четыре параметра:
- Reach - это охват аудитории. Он может выражаться как в абсолютных цифрах (типа, 300), так и в относительных (например, 40% аудитории). Что вы выберете - не важно, но критично, чтобы Reach ВСЕХ задач оценивался одинаковым способом.
- Impact - все то же, что и в ICE, оцениваем от 1 (никак не влияет) до 10 (жирнейше влияет).
- Confidence - привет, ICE. От 1 (не верим) до 10 (верим как Оби-Ван - в Йоду).
- Effort - трудоемкость. Тут есть ОПАСНОЕ отличие от ICE, потому что в данном случае мы оцениваем не легкость разработки, а, наоборот, сложность. Шкала - от 1 (все элементарно) до 10 (от полугода до года, привет, Серега Магадан). Тут важно не перепутать.
4. Считаем RICE Score. Его формула отличается от ICE и считается более хитро: мы должны перемножить Reach, Impact и Confidence и поделить на Effort.
5. Сортируем по убыванию, получаем вот такую табличку:
Я люблю ICE за его простоту и способность работать даже в обстановке полного ХЗ, но у него есть свои ограничения. Первое - он с трудом срабатывает в случае, если ваши идеи нацелены на разные сегменты аудитории и охватывают разные числа пользователей. Да, это можно включать в нашу оценку Impact, но иногда это приводит к вывиху мозга. В таком случае лучше воспользоваться второй родственной методикой - RICE.
Общая логика RICE ОЧЕНЬ похожа на ICE, но у него есть свои прибабахи. Вот что нужно сделать:
1. Выделить Царь-Метрику, на которую мы хотим повлиять. Тут см. п.1 в ICE - все то же самое.
2. Заносим идеи в табличку. Опять-таки, как в ICE.
3. Для каждой гипотезы оцениваем четыре параметра:
- Reach - это охват аудитории. Он может выражаться как в абсолютных цифрах (типа, 300), так и в относительных (например, 40% аудитории). Что вы выберете - не важно, но критично, чтобы Reach ВСЕХ задач оценивался одинаковым способом.
- Impact - все то же, что и в ICE, оцениваем от 1 (никак не влияет) до 10 (жирнейше влияет).
- Confidence - привет, ICE. От 1 (не верим) до 10 (верим как Оби-Ван - в Йоду).
- Effort - трудоемкость. Тут есть ОПАСНОЕ отличие от ICE, потому что в данном случае мы оцениваем не легкость разработки, а, наоборот, сложность. Шкала - от 1 (все элементарно) до 10 (от полугода до года, привет, Серега Магадан). Тут важно не перепутать.
4. Считаем RICE Score. Его формула отличается от ICE и считается более хитро: мы должны перемножить Reach, Impact и Confidence и поделить на Effort.
5. Сортируем по убыванию, получаем вот такую табличку:
👍11
Ссылка: https://docs.google.com/spreadsheets/d/1PON1VgQV7snIDTicT1QpBivKlGsL_yebcURBBWyZt_o/edit#gid=675548540
Как видите, RICE тоже показывает любопытные результаты.
Теперь скажу про несколько подводных камней, свойственных обоим методам.
1. Воспринимайте скоринг не как указание к действию, но как пищу для ума - ICE и RICE сильно упрощают действительность и требуют дополнительного осмысления бэклога на выходе. Это не баба Ванга, не волшебная шляпа из Хогвартса и даже не Дмитрий Анатольевич Медведев; будущего методика не знает, и лишь помогает вам отдалиться и посмотреть спокойно на все ваши задачи.
2. ICE и RICE не учитывают взаимосвязи задач - поэтому вполне может сложиться ситуация, что в вашем списке телега всплывет впереди лошади и функция восстановления пароля окажется приоритетнее регистрации. Это нормально, но такие случаи надо прорабатывать отдельно (например, тупо отмечать заблокированные задачи серым цветом в таблице)
3. Не закапывайтесь в оценки, оценивайте по-быстрому. Если вас тянет для просчета Impact выстроить какую-то священную методологию и в ней глубоко закопаться - вы, конечно, можете это сделать, но это снижает пользу от инструмента. Короче, держите свой перфекционизм на коротком поводке.
4. Не забывайте регулярно возвращаться к оценкам - продуктовая ситуация и ваше понимание проблемы может измениться, и тогда надо будет перепроверить ваши параметры.
5. Наконец, самое важное. Если у вас идет ледовое побоище за продукт (оценили каламбур, а? а?), и вы хотите в разной мере влиять и на посещаемость, и на конверсию, и на выручку, то оба метода крякают и перестают работать. Выход из ситуации - использовать чуть более хитрую методику ICE+, которую вы вряд ли загуглите, потому что я ее придумал сам и редко про нее говорю. Вам расскажу - но в следующих постах. Пока запомните - если у вас куча Царь-метрик, то ICE и RICE лучше не трогать (и в принципе стоит хорошенько задуматься - для продукта обилие Царь-метрик не всегда хорошо).
Вот такие пироги. Оба инструмента хороши, хотя лично я предпочитаю ICE (и помянутый выше ICE+), а RICE использую только в том случае, если приоритизация у меня вызывает сомнения. С другой стороны, я знаю хороших продактов, которые, наоборот, до хруста костей любят RICE. Тут уже каждому свое.
На этом наша передача «РИС СО ЛЬДОМ» подходит к концу, не хворайте.
#батинамудрость
Как видите, RICE тоже показывает любопытные результаты.
Теперь скажу про несколько подводных камней, свойственных обоим методам.
1. Воспринимайте скоринг не как указание к действию, но как пищу для ума - ICE и RICE сильно упрощают действительность и требуют дополнительного осмысления бэклога на выходе. Это не баба Ванга, не волшебная шляпа из Хогвартса и даже не Дмитрий Анатольевич Медведев; будущего методика не знает, и лишь помогает вам отдалиться и посмотреть спокойно на все ваши задачи.
2. ICE и RICE не учитывают взаимосвязи задач - поэтому вполне может сложиться ситуация, что в вашем списке телега всплывет впереди лошади и функция восстановления пароля окажется приоритетнее регистрации. Это нормально, но такие случаи надо прорабатывать отдельно (например, тупо отмечать заблокированные задачи серым цветом в таблице)
3. Не закапывайтесь в оценки, оценивайте по-быстрому. Если вас тянет для просчета Impact выстроить какую-то священную методологию и в ней глубоко закопаться - вы, конечно, можете это сделать, но это снижает пользу от инструмента. Короче, держите свой перфекционизм на коротком поводке.
4. Не забывайте регулярно возвращаться к оценкам - продуктовая ситуация и ваше понимание проблемы может измениться, и тогда надо будет перепроверить ваши параметры.
5. Наконец, самое важное. Если у вас идет ледовое побоище за продукт (оценили каламбур, а? а?), и вы хотите в разной мере влиять и на посещаемость, и на конверсию, и на выручку, то оба метода крякают и перестают работать. Выход из ситуации - использовать чуть более хитрую методику ICE+, которую вы вряд ли загуглите, потому что я ее придумал сам и редко про нее говорю. Вам расскажу - но в следующих постах. Пока запомните - если у вас куча Царь-метрик, то ICE и RICE лучше не трогать (и в принципе стоит хорошенько задуматься - для продукта обилие Царь-метрик не всегда хорошо).
Вот такие пироги. Оба инструмента хороши, хотя лично я предпочитаю ICE (и помянутый выше ICE+), а RICE использую только в том случае, если приоритизация у меня вызывает сомнения. С другой стороны, я знаю хороших продактов, которые, наоборот, до хруста костей любят RICE. Тут уже каждому свое.
На этом наша передача «РИС СО ЛЬДОМ» подходит к концу, не хворайте.
#батинамудрость
👏29❤17🔥8👍3
Как вы знаете, дорогие котаны, у нас есть рубрика БИСКВИТНЫЙ ДВОР, волны которой выносят в наш край чистого разума впечатляющие образцы UX-навоза.
Героями БИСКВИТНОГО ДВОРА, как правило, становятся интерфейсы - кривые жертвы безголовых обезьян-дизайнеров, всем своим видом умоляющие, чтобы их пристрелили.
Иногда это правило нарушается, и тогда к нам в руки попадают нормальные, полезные и даже хорошие продукты. Они стоят среди копошащихся хуикс-мутантов подобно Траволте из мема с Траволтой, тревожно оглядываются, чувствуют себя не в своей тарелке. В какой-то момент их взгляд пересекается с нашим, и они, просияв, протягивают к нам свои белоснежные руки и говорят: «ВОТ ОНО ПРИШЛО МОЕ СПАСЕНЬЕ ВЕДЬ Я В БИСКВИТНОМ ДВОРЕ ОКАЗАЛСЯ ПО ОШИБКЕ ВЫРУЧИ МЕНЯ ЛЁХА ТЫ МОЯ ПОСЛЕДНЯЯ НАДЕЖДА».
А мы им такие: нет, братец, ты здесь не по ошибке, а по делу; получай-ка веслом по жопе!
И вот сегодня у нас как раз такой праздничный случай: к нам в гости пожаловал сам Spotify. Казалось бы, какой хороший сервис и продукт - пользуйся да радуйся!
Но есть у него один момент, который меня неизменно вымораживает. Вот он:
Героями БИСКВИТНОГО ДВОРА, как правило, становятся интерфейсы - кривые жертвы безголовых обезьян-дизайнеров, всем своим видом умоляющие, чтобы их пристрелили.
Иногда это правило нарушается, и тогда к нам в руки попадают нормальные, полезные и даже хорошие продукты. Они стоят среди копошащихся хуикс-мутантов подобно Траволте из мема с Траволтой, тревожно оглядываются, чувствуют себя не в своей тарелке. В какой-то момент их взгляд пересекается с нашим, и они, просияв, протягивают к нам свои белоснежные руки и говорят: «ВОТ ОНО ПРИШЛО МОЕ СПАСЕНЬЕ ВЕДЬ Я В БИСКВИТНОМ ДВОРЕ ОКАЗАЛСЯ ПО ОШИБКЕ ВЫРУЧИ МЕНЯ ЛЁХА ТЫ МОЯ ПОСЛЕДНЯЯ НАДЕЖДА».
А мы им такие: нет, братец, ты здесь не по ошибке, а по делу; получай-ка веслом по жопе!
И вот сегодня у нас как раз такой праздничный случай: к нам в гости пожаловал сам Spotify. Казалось бы, какой хороший сервис и продукт - пользуйся да радуйся!
Но есть у него один момент, который меня неизменно вымораживает. Вот он: