Сложные и размытые задачки — фреймворки, ч.1

В прошлых постах в тележке мы уже рассмотрели «почему туплю, когда начинаю сложные задачи» и в самых общих чертах — «как приступать к их решению»

Сейчас хочется нырнуть в мясо, разобрать много разных фреймворков, инструментов, подходов и пр.

Но сходу упираемся в первую мысль

Фреймворки — не главное

Бег за фреймворками и инструментами без понимания смысла = карго-культ. В портфолио и на собеседовании это быстро выявляется. Дизайнер не может ответить, зачем он рисовал, например, userflow; почему именно такой, почему именно на этом этапе проекта, почему именно для всей фичи. И легко опознаётся как джун (максимум миддл).

А как правильно? Правильно — понимать несколько главных вопросов, стоящих за всеми фреймворками. До них мы еще доберемся :)

AI нам подскажет, что к UX/UI/продукту относятся, помогают в работе над ним, или могут быть притянуты за уши:

1. Design Thinking
2. Double Diamond
3. Atomic Design
4. HCD
5. JTBD
6. Lean UX
7. Service Blueprint
8. Gestalt Principles
9. User Story Mapping
10. HEART Framework
11. Mental Models
12. User Story Mapping
13. Kano Model
14. Fogg Behavior Model
15. The Hook Model

Более, того, я сам изобрел один фреймворк, скрестив AARRR-воронку (она же «пиратские метрики») и CJM и выкинув лишнее. Я обучил этому фремворку как минимум несколько сотен людей, но до сих пор не придумал название :)

Без понимания «зачем и в каких случаях», фреймворки работают плохо

Если не понимать сути и смысла фреймворков, их ограничений, их применимости — в них просто теряешься.

У миддлов «в запущенной стадии» или у «фрагментарных синьоров» часто бывает переизбыток знаний и техник и недостаток их систематизации. Знаешь много, умеешь вроде бы тоже, но каша в голове нарастает и работать ты начинаешь все медленнее и с бОльшим скрипом.

Что делать?

Главное — императивы

Все фреймворки отвечают на несколько «простых» вопросов: Зачем, Кто, Что, Как, Когда. Они же императивы менеджмента.

В каждом из этих вопросов кроется бездна:) Например «кто» — это и про стейкхолдеров, и про пользователей, и про команду, инфлюенсеров, и кого угодно еще. Про их портреты-хотелки-тараканы-профдеформации и любые другие, важные для дела особенности.

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

Если захочется углубиться в тему — читаем Адизеса (он пишет про менеджмент в целом).

То есть, каждый дизайнерско-продуктово-исследовательский фреймворк отвечает на один или несколько этих императивов. Причем есть нюансы.

Например, Mental Models отвечает на «Кто наши пользователи?». Но не отвечает на «Кто наши стейкхолдеры и как мне с ними работать» — для этого уже нужна Stakeholders map.

В рабочих задачах императивы можно покрывать в плюс-минус любом порядке. В среднем, лучше всего начинать с «Зачем». Но, я часто начинаю с «Кто» (надо же понимать, у кого спрашивать «Зачем»). А еще в начале может прилететь какое-нибудь ТЗ (и это будет уже информация про «Что»).

Погрузимся же в эти Зачем, Кто, Что, Как/Когда — и потом наложим на них продуктоводизайнерско-исследовательские фреймворки.

Рассмотрим каждый императив

1. Зачем. Фильтр для всего, что мы делаем. OKR, цели спринта, метрики и пр.

Этот вопрос/императив помогает понять, куда сейчас бежим, какова ближайшая цель — так легче «прицеливаться» и убирать лишнее.

Вот пример. В моем текущем проекте есть такая задача:

Задача большая, точно нужная и дает много ценности продукту. Ее очень любит наш CEO:) Но! Она относится далеко не к первому шагу воронки. А мы сейчас прорабатываем как раз первый шаг пути пользователя (иначе у нас тупо не будет продаж и команда сдуется через несколько месяцев. Значит, привлечение, первый платеж и первый месяц использования — на первом месте.

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

А на уровне дизайна — можно пока не прорабатывать много сценариев, в навигации достаточно базово прикинуть, где в будущем будет встроен коммуникатор, и пр.

Еще один плюс — бизнес (если это нормальный зрелый руководитель) хорошо принимает аргументы на уровне «зачем». Только надо донести, что вы не пытаетесь подорвать его авторитет и право на управление, а хотите понять, на чем у нас фокус, и какие цели мы преследуем (чтобы помочь их достичь). Тогда не будет борьбы, а будет сотрудничество.

2. Что. Производство

Этот вопрос/императив — про готовый самокат/самолет, который мы вытачиваем в гараже/на заводе и отдаем пользователю.

От дизайнера это обычно или макеты, или макеты+сопровождение разработки, или вообще — конечный UX пользователя (зависит от зрелости команды и кучи других факторов).

Но если подетальней, то:

• Описания фичей,
• userflow,
• макеты,
• интерфейсные тексты,
• код и пр.

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

Например, та же автоматизация регистрации юрлиц:

3. Кто. Пользователи, стейкхолдеры, команда и пр.

Этот вопрос/императив помогает понять — чьи мнения/боли/хотелки нам надо учитывать при работе. И как именно.

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

99% ценности от любого фреймворка — это внедрение. Твоя способность дожать до принятия командой, успешного применения и получения ценности. Поэтому очень важно не просто понимать «кто», но и «какие они». Чтобы адптировать подачу.

Кому-то отлично зайдет твое «щас мы пойдем через JTBD» (потому что «ну наконец все будет по науке, а не на коленках»). А у кого-то вызовет скрежет зубов «ну вот опять вместо дела будем умничать». В одном проекте у меня даже дейлики внедрить заняло полторы недели переговоров.

Для системной работы над «кто есть кто внутри нашей команды» имеется отличный инструмент — карта стейкхолдеров. Она показывает, на какие четыре группы стоих разделить всех игроков в проекте, и как с ними работать. Соответственно — лепим карточки с ФИО+должностью, либо сегментом. И действуем соответственно :)

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

1. Кто заказчики/бизнес/стейкхолдеры?
2. Кто предметные эксперты?
3. Кто «соседи»?
4. Кто будет внедрять у себя результаты нашей работы?
5. Кто что хочет и кому что нужно?
6. У кого можно получить какую инфу?
7. Кто какими ресурсами располагает и какие решения принимает?

Это уже не влезет в карту стейкхолдеров и такое удобней просто в майндмепе.

А про пользователей можно рисовать Empathy map, мандмепы с джобами и прочие штуки.

4. Как/когда. Процессы, подходы, ритуалы, церемонии

Мы ведь в статье говорим про расплывчатые и сложные задачи? Они часто не решаются в лоб. И появляется вопрос/императив про то:

• Как ты выполняешь задачу
• Как собираешь требования по задаче
• Как создаешь для команды прозрачность о том, что у тебя происходит
• Какие этапы выделяешь в работе над задачей
• И все остальные «как»

Вот например, Scrum и Agile — это очень сильно про «Как». Дейлики, спринты, канбаны-родмапы, шаблоны продуктового описания задач и пр.

Хорошо проработанное «Как» помогает бежать быстрее, снижает неразбириху и очень сильно высвобождает мозг.

Но есть нюансы:

1. Впрыскивать пошагово. «Как» — про системность, про «бюрократию в хорошем смысле». И команда, и бизнес часто ей сопротивляется. Поэтому внедрять надо маленькими, но ежедневными/еженедельными шажочками. На текущем месте я сначала внедрил дейлики (их не было), потом у нас появились релизы, потом начали появляться спринты и пр.
2. Учитывай особенности команды/ситуацию. Для каких-то изменений и практик ситуация может быть просто не назрела. К примеру, сейчас седьмой месяц моей работы над текущим продуктом. И только сейчас все дозрело, чтобы мы начали внедрять метрики. Раньше и пользователей в нужном объеме не было, и проблемы надо было решать — другие.
3. Продавай через решение конкретных проблем. Частая болезнь «сферического правильного продуктового дизайнера в вакууме» — продавать подходы и методы под соусом «ну так же правильно». Очень часто это не работает. А вот если начать с проблемы, которая болит и у команды и у бизнеса, и сначала договориться, что ты поищешь решение этой проблемы... То потом придти и рассказать про какой-нибудь Double Diamond — сработает гораздо лучше.
4. Lege, Meditare, Disputi (повторяй, проверяй, спорь). Это старая греко-римская поговорка про освоение философии, или какого-нибудь ремесла. Подходит и для фреймворков :)
• В ней предлагается сначала «взять как есть» и затестить максимально близко к описанному.
• И посмотреть как работает, получить первый опыт не в воображении, а в реальности.
• Желательно — в тепличных условиях, без дедлайнов и жестких требований к результату (иначе трудно учиться, самонаблюдать и делать выводы).
• Потом — честное практическое применение так, чтобы максимально освоить и научиться применять в разных условиях, со стабильным хорошим результатом.
• Потом — видоизменять, переделывать под себя, опровергать, декомпозировать и скрещивать с другими подходами. В общем — отталкиваться от и творить новое :)

Ок, и как сюда приложить фреймворки?

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

С этим я вернусь позже. Итак которую неделю посвящаю завтраки этой статье, пора выпускаться :)

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