Буквы, которые «знать надо», 5 примеров

HADI, CJM, JTBD, RICE/ICE, RAT. Разработка и методы, чтобы не впадать в ступор, когда/если вас о них спросят. Привязываем сокращения к смыслу.

Из практики: человека, моего знакомого, начали закидывать акронимами, и человек очень смутился — потому что подходы элементарные, а с вот этими сокращениями не сталкивался.

Ничего сложного, на самом деле, просто вот вам краткая шпаргалка «а, вот это — это вот оно», я его узнал.

HADI (Hypothesis — Action — Data — Insights)

Это костяк из научного метода, применительно к практике реальной жизни и исследованию всякой, пока нам непонятной фигни. В англоязычной литературе выделили подход как самостоятельный метод, и дали ему название. Просто цикл постановки и проверки гипотез. Базовый метод итеративной работы, над чем-нибудь. Например, над программным продуктом, или что у вас там.

Везде, где есть неопределенность, можно его применять и сделать пафосный вид, во какие буквы знаю.

Ключевое отличие у него практическое и важное только одно, по сути: мы опираемся на гипотезы и факты (данные) из наших действий — а не на чьи-то мнения.

И чаще всего гоняем цепочку циклично:
— что-то придумали (сформулировали гипотезу),
— произвели набор действий
— получили данные, результаты, метрики
— сделали выводы, пошли дальше

Применяется он как метод, на практике — много где, на различных изменениях-улучшенияъ, сравнениях (тестах), в маркетинге. На проектировании изменений. Везде где лучше померить и сравнить. Подход же очевидный как два рубля.

PDCA и HADI можно комбинировать. Например, крупные циклы итераций это PDCA, а внутри крупных итераций все непонятки проясняем через HADI-циклы.
Календарно о HADI как о самостоятельном явлении начали активно говорить в 2000-2010 в разрезе agile-практик (потому что это, часто считается, одна из них).

CJM (Customer Journey Map)

Карта пути клиента/пользователя. По шагам — но с фокусировкой не на действия, как таковые, а на ожидания, эмоции, поставленные вопросы, проблематику/боли.

Используется при разработке сценариев, при анализе и улучшении взаимодействия. Основной критерий всегда — наличие какой-то цепочки действий или этапов, ключевых точек (т.е, путь).

Шаги удобно визуализировать. Дальше на каждом шаге анализируем происходящее; основной вопрос, обычно = где затыки, где проблемы, которые могут мешать всей цепочке выполняться до конца.

Встречается россыпью во взаимодействиях и интерфейсах (UI/UX), в маркетинге в воронках продаж, в сценариях поддержки, в проектировании user story (очевидно) итп.

По истории не подскажу, гуглить надо, мне лень. OReilly пишет что это Брюс Темкин и 1994. Но как метод в 2000-е о подходе активно начали говорить (и когда стали нормально разделять UI/UX/Flows/User Stories).

JTBD (Jobs To Be Done)

Концепция целевого действия. Об этом я уже упоминал, человеку нужно не сверло, а дырка в стене.

Часто используют в формировании ценностного предложения (маркетинг), в приоритезации фич (как мы пооптимальнее даем пользователю достигать результата, и какого конкретно), очевидно внутри маркетинга, при оптимизации цепочек (чтобы фрикций и трения меньше, а пользы больше/очевиднее).

Важно еще, что фокус здесь только на контекст задач, без портрета пользователя. Категорически пофиг, кому конкретно понадобится дырка в стене, слесарю Васе или секретарше Маше. Важно, что в ней есть необходимость, как стартовое условие (контекст).

Позволяет в этом смысле отделять мух от котлет, не замыкаться на портретах и аудиториях. Кристенсен за это как раз топил — его считают не «изобретателем», но популяризатором метода. И буковки JTBD кажется тоже его.

Про детали и историю можно почитать тут. Там же есть разделение Jobs-As-Progress и Jobs-As-Activities, хотя на практике отличия часто размываются.

RICE/ICE (Reach — Impact — Confidence — Effort)

RICE его младший брат ICE (Impact — Confidence — Ease).

Это метод оценки затрат и геморроя. Насколько то или иное решение нам полезно и оправданно, в сравнении с другими вариантами путей развития.

Часть RIC или ICE — это наш положительный коэффициент,
— Reach это какую аудиторию затрагивает, скольким принесет полезность
— Impact влияние, насколько крут и важен для задачи конкретный рассматриваемый (потенциально решенный) момент
— Confidence насколько велика наша уверенность, есть ли непонятки и общие сомнения
— Ease насколько легко решается

И в большой модели заявлен отрицательный коэффициент Effort — это затраты разнообразные (время, работа, бюджеты, сроки итп). В мелкой его нет.

Используется чаще всего и малый, и большой методы для понимания, чего делать и куда копать — чтобы вложений и затрат поменьше, а пользы побольше.
RICE обычно считается в каком-то нормализованном показателе, ICE, чтобы попроще, тупо «в попугаях», на глаз.

Некоторые делают из него прямо agile-практику, аналогичную poker planning.
Понавыставляли оценок на глаз, отсортировали, посмотрели чего там попроще-повкуснее, выбрали самое вкусное, пошли делать.

Исторически у истоков стояли вроде как Intercom (Sean McBride) и GrowthHackers (Sean Ellis) в 2010-х. Причем там забавно, если ICE позиционируется как наглухо субъективный (но зато простой), то Макбрайд в RICE как раз хотел от субъективщины уйти, и получить взвешенную нейтральную оценку, с претензией на объективность. Но потом забил, «само работает и ладно».

RAT (Riskiest Assumptions Test)

Методика быстрой борьбы с непонятными моментами, и потенциальными бутылочными горлышками. То есть, поиск и проверка слабых мест в предлагаемой модели.

Используется чаще всего в прототипировании, построении всяких MVP, внутри HADI для поиска самых слабых гипотез и их проверки в первую очередь.

Практический смысл — лучше по-быстрому проверить все свои допущения и дальше уже действовать на основании проверки, чем влить кучу ресурсов и потом наткнуться на непроработанный риск или глобальную нестыковку (которая все равно всё похоронит).

Ноги растут исторически от Eric Ries, который в Lean Startup (2011) метод RAT озвучил как противопоставление подходу «ну, вот мы сделаем MVP».

Rick Hiam (SkyScanner) следом эту идею неплохо популяризовал, именно как самостоятельный метод — не только для MVP каких-то и стартаперства, а просто внутри продукта и для рабочих гипотез.

Hope that helps.