3. Иду в карту. Что я вижу? А ничего я не вижу. Нету никакой истории операций. Мухи унесли.

4. Я перехожу в режим бешеного кабанчика и начинаю носиться кругами по всему приложению, похрюкивая от напряжения. Истории операций нигде нету. Ни на главной, ни где-то еще. Я нахожу даже какое-то невообразимое говнище, которое мне никогда не понадобится - но истории операций нигде нету.
5. Я начинаю грустно выть, будто и не бешеный кабанчик я, а волк, который, как известно, даже когда кабанчик - волк. История операций от этого не появляется.
6. А потом я ее, сука, нахожу. И знаете где?
7. Я еле удерживаюсь от рифмы, но отвечу культурно: ПОД КНОПКОЙ, МАТЬ ЕЕ, «НЕТ ТРАТ В ДЕКАБРЕ»

8. Я гляжу на ноябрьскую операцию под заголовком «Траты за декабрь» и мой ор поднимается выше гор.

Пользовательская задача выполнена, пользователь в ауте и посылает лучи омерзения тому, кто придумал такое дьявольское по удобству решение.

Обратите внимание, что эти хобгоблины и поступления денег таким же макаром прячут под "Траты за декабрь" (за замечание спасибо дорогому читателю @replaner). Я долго думал, что здесь пошутить - и не смог. Это дно, которое стучит об тебя.

Меня люто, бешено трясет от такого идиотизма, но рубрика БИСКВИТНЫЙ ДВОР обязывает меня вынести из кейса какую-то хуикс-мораль. Мораль такая: пользователь должен корректно предугадывать, где скрывается та или иная функция и к чему приведет нажатие на ту или иную кнопку. Если продукт помогает пользователю это угадать - в голове у клиента легко формируется логичная ментальная модель интерфейса, и пользователь воспринимает продукт как что-то близкое и понятное.

Если продукт этому не то что даже помогает, а мешает неправильными ожиданиями (как с этой сраной кнопкой «НЕТ ТРАТ В ДЕКАБРЕ», которая значит что угодно, но не историю операций за ноябрь), то пользователь начинает беситься, бомбить и всерьез подумывать свалить к конкурентам.

«МЫ НЕ ДЕЛАЕМ UX-ТЕСТИРОВАНИЯ ПОТОМУ ЧТО В НИХ НЕ ВЕРИМ» Вот же срань какая, а.

P.S. Хотите вишенку на торте? Я снимал скрины с Тинькова, при этом слушая музыку через наушники. Так вот: при открытии приложения Тинек за каким-то чертом останавливает музыку и перехватывает аудиопоток. Да что мне там у вас слушать, медведь вас задери?!

#бисквитныйдвор

Давно хотел вам рассказать про приоритизацию продуктовых задач.

Поскольку у нас с вами респектабельное научно-популярное издание, построенное на дохренища серьезных щах, я просто обязан сперва дать вам определение приоритизации.

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

А еще приоритезация - это скотское слово, в котором я постоянно опечатываюсь (сейчас, например).

Вообще говоря, в цифровой разработке нужно приоритизировать разные задачи - и большие продуктовые решения/фичи/гипотезы наподобие «Сделать автозаказ товара в полнолуние», и мелкие технические задачи вида «Сделать версточку для лэндосика», которые вы с командой нарезали на ближайший спринт.

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

Мой рассказ про преоритизацию (ну вот, опять) будет разбит на 2 части:

1. Сперва мы поговорим про говяжьи методы приоритизации, когда и думать не надо - сел и разложил все по полочкам. Тут все будет очень просто.

2. Потом мы оттопырим мизинчик и поговорим про более задротские методы разделаться с вашими задачами. Мы поговорим про ICE, RICE и ICE+ (вряд ли вы про него слышали - это мой домотканый способ приоритизировать задачи в особо запущенных случаях).

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

Итак, поехали.

Сегодня у нас в программе говяжьи методы приоритизации - то, что поможет вам быстро распределить задачи в полевых условиях.

Суть этой группы методов проста - садимся с умными людьми и давай задачи по полкам раскладывать. Тут я выделяю 3 основных метода работы:

1. Хуман-центеред. Мы резко вспоминаем, что не просто так таскаем приписку «хуикс» к своей профессии, первым делом проводим исследования и составляем CJM нашего продукта (про CJM сына маминой подруги можно почитать у меня вот тут).

Этот CJM мы делаем не просто так, но чтобы прикинуть, какие фичи нам потребуются для прохождения пользователем сценария - и насколько они вообще критичны.

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

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

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

В этом процессе не обойтись без системного архитектора - того самого хмурого деда, который в обычное время глушит водку в углу, не мигая смотрит на календарь с голыми женщинами и всякие клиентские проблемы-CJM-UJM-методы персон видит в лучшем случае в гробу, а то и где похуже.

Этот дед вынимает сигару изо рта, шевелит густыми усами, смотрит на ваши планы, говорит хмуро «ВОТ ЭТО БЛЪ ДЕЛАЕМ В САМОМ НАЧАЛЕ ЭТО БЛЪ ДЕЛАЕМ В САМОМ КОНЦЕ А ПРО ЭТО БЛЪ ЗАБЫЛ СРОЧНО ЭТО НЕ РЕАЛИЗУЕМО ОПЯТЬ НАПРИДУМЫВАЛИ БЛЪ ХИМОТУ А НАМ ДЕЛАЙ».

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

Это не очень хорошо - таким макаром вы быстро пользовательское решение не получите. Тогда вас выручит следующий метод.

3. Суперстракчед-хуман-аркитекча-центеред-2000 эдишон-ПЛЮС. Как можно догадаться из названия, этот метод приоритизации объединяет предыдущие два - и предполагает, что вы усаживаете за стол переговоров и UX-специалистов, и архитектурных дедов. Спустя несколько часов споров, выпитых бутылок водки и порванных - нет, вы не так поняли, подождите - листов бумаги вы получите план по разработке, который будет сбалансирован и с системной, и с пользовательской точки зрения. Его можно брать в работу и не беспокоиться, что вы где-то сядете в лужу.

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

Если же перед вами лежит ворох задач, которые несут разную ценность для пользователя, отличаются по трудозатратам и при этом должны разрабатываться одной командой - у меня для вас есть плохая и хорошая новость.

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

(или не спасут, но я не буду пугать вас раньше времени)

#батинамудрость

А вот вам небольшое интермеццо, вызванное комментариями к посту про преоре... преори... приоре... короче, к моему прошлому посту.

Дорогие читатели подняли резонный вопрос - а на кой чорт ты, Лёха, CJM используешь для расстановке приоритетов, когда четкие пацаны для этого издавна используют другой инструмент - User Story Mapping? Это что же выходит, четкие пацаны попутали?

Четкие пацаны абсолютно правы. User Story Mapping - это правильный, хороший и четкий инструмент для быстрой первичной приоритизации. Но! В нем есть один крайне занятный нюанс, ради которого нам надо вспомнить, как же выглядит формат User Story Mapping.

Любой User Story Mapping строится в четыре основных шага:

1. Берем сегмент ЦА/персону и определяем основные этапы его взаимодействия с продуктом (ну, там, Ознакомление->Поиск товара->Знакомство с товаром->Оформление покупки->Ожидание->Получение и обратная связь)

2. Для каждого из этапов выписываем, что пользователь будет делать - фильтровать каталог, класть товар в корзину, смотреть бессмысленным взглядом на иконку «Ожидание доставки»;

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

4. Решения (они же фичи) разбиваем на релизы в зависимости от целесообразности и критичности с точки зрения прохождения основного сценария.

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

А теперь отвлечемся от USM и резко, бешено вспомним, как выглядит типовой CJM:

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, пусть и с дополнительными обвесами:

И в итоге получается, что CJM путем пинков и нехитрых расширений можно превратить в полноценный User Story Mapping! Публика в шоке, фокусник вытащил шляпу из кролика и засунул льва к себе в пасть.

То есть можно спокойно считать, что USM - это подкрученный и детализированный CJM, и это не какие-то там отдаленно схожие, но разные форматы, а вообще одно и то же. Это сценарное представление, которое просто ставит разные акценты: классическое представление CJM больше нацелено на проработку пользовательского сценария, а представление USM скорее необходимо для технической детализации и приоритизации.

Но корневая суть их едина и неделима. Это все один и тот же сценарий.

P.S. В качестве десерта закидываю вам вопрос «А что же тогда такое Service Blueprint» - вы не поверите ответу!

#сжм

Сижу я, мирно пишу для вас давно обещанную телегу по ICE и RICE, и тут мои хрустальные, нежные мысли прерывает вот такое БОМБАЛЕЙЛО ЛЁХА ОТКЛАДЫВАЙ ПЕРО В СТОРОНУ ВСТАВАЙ ВОЙНА НАЧАЛАСЬ В ВОРОТА НЕВЕДОМАЯ ХЕРНЯ ЛЕЗЕТ ГДЕ ТВОЙ ЛАЗЕРНЫЙ МЕЧ АГА ПОЕХАЛИ!!!!

В чем суть картинки: вот эти уважаемые господа, неуловимо похожие на актера Джека Николсона из кинофильма «Сияние», прилюдно сравнивают Jobs To Be Done с CustDev и приходят к сладострастному выводу, что JTBD лучше жалкого, обрубочного кастдева и помогает строить полновесные продуктовые стратегии.

Когда мне прислали эту картинку, я поперхнулся не то что чаем - собственным мозгом, и решил сделать вам прививку мудрости, чтобы вы, не дай Бог, не подхватили газовую гангрену хуикс-цыганщины и не окончили свою жизнь в позоре, под мостом, в коробке из-под телевизора.

Начнем с базы.

Что такое JTBD? Это способ разложить возможности вашего продукта по полочкам, где каждая возможность формулируется в духе «Находясь в таком-то контексте, я хочу делать что-то, чтобы достичь чего-то».

Например: «Находясь в пьяном состоянии пятничным вечером, я хочу быстро и просто вызвать такси, чтобы безопасно попасть домой и не уехать на алкоприключения»

Или: «Находясь в состоянии бомбалейло, я хочу навалять лещей инфоцыганам, чтобы успокоиться и хоть как-то восстановить гармонию в мире».

Мы изучаем нашу аудиторию и ее потребности, на этой основе составляем кучу джобов - и, вуаля, готов список потребностей наших клиентов, на котором мы можем построить продукт.

При этом не важно, кем ты являешься (архаровец, тургеневская барышня, негр преклонных лет) - важен только контекст, в котором ты находишься, твои задачи и конечные цели. По своей сути JTBD представляет собой упрощенный, огрубленный и упрощенный кусок Goal-Directed подхода дедушки Алана Купера, который отталкивается от глубокого знания аудитории, ее особенностей и множества конкретных деталей, выражаемых в персонах, User Story, CJM и прочих нажористых штуках и артефактах.

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

Теперь ответим на вопрос - а что же такое CustDev? Кастдев - это сложный, многоступенчатый процесс выявления и подтверждения потребностей и инсайтов у аудитории с целью улучшения продукта. Этот процесс включает в себя и проведение исследований (как качественных, так и количественных, от глубинных интервью до опросов), и формулирование гипотез, и их проверку, и охватывает, по сути, всю пользовательскую сторону продукта - от «У нас тут есть идея, давайте сходим к аудитории и проверим» до «Кажется, наш продукт идет не туда, давайте менять курс».

Иногда кастдевом называют глубинные (и не очень) интервью где-то перед этапом дизайна - но так нельзя делать. Это или некорректный жаргонизм (я и сам, каюсь, им в свое время злоупотреблял), или признак интеллектуального увечья. Кастдев куда сложнее.

И вот возвращаемся к моему бомбалейло. Хлопцы с обаянием Джека Николсона предлагают сравнить между собой перекрашенный кусок Алана Купера, предназначенный для первичного разбора состава вашего продукта, и сложную методологию, которая включает в себя безумное количество активностей вокруг вашего продукта - и, сука, приходят к выводу, что JTBD формирует РЫНОЧНУЮ СТРАТЕГИЮ ПРОДУКТА, а CustDev видится ОБРУБОЧНЫМ решением, после чего на серьезных щах делают вывод «Полезно узнавать информацию даже у тех клиентов, у которых, казалось бы, и нечего спрашивать». Серьезно?!

Обрубленная, узкоспециализированная метода объявляется охереть каким планомерным подходом, а сложная, как космос, методика подхода к аудитории - кутылым обрубком. Война - это мир, свобода - это рабство.

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

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

- Что лучше - метод персонажей или screen flow?
- Что полезнее для продукта - глубинные интервью или метрики?
- Что сделать первым - прототип или вайрфрейм?
- Что важнее - прибыль или юнит-экономика?

Хотя нет, не расскажу. Я даже шутить на эту тему не могу, мозг сразу сводит от бешенства.

Ну и в заключение вот вам несколько золотых твитов от дедушки Купера, где он отвечает на схожий вброс «СМОТРИТЕ-КА JTBD ЭТО ЛУЧШАЯ ЗАМЕНА ВАШЕМУ МЕТОДУ ПЕРСОН». На этом, пожалуй, и остановимся.

#бомбаж