Давайте поговорим о приоритизации.

Но не о всяких MoSCoW, USM, RICE/ICE и подобных. И даже не о сэйфовском WSJF. Давайте поговорим о подходе, который учитывает вероятности и риски. И который можно с лёгкостью адаптировать под конкретно ваши проектные и продуктовые реалии.

Речь о PoD x Probability x Reversibility, где:

PoD (Pain over Difficulty) — боль на единицу усилий. Чем больнее пользователю или бизнесу и проще исправить — тем выше приоритет. Это фильтр во имя здравого смысла: если у тебя в продукте очевидная дыра, которую можно закрыть за день, тупо ждать квартального планирования.

Probability — вероятность эффекта. Насколько мы уверены, что это вообще сработает. Уверенность эта берётся не из домыслов и фантазий, а из данных, интервью, экспериментов. Иногда «большая идея» с нулевой валидацией выглядит мощно, но шанс попасть в цель у неё меньше, чем у простого фикса, снимающего боль прямо здесь и сейчас.

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

Возьмём какой-нибудь простейший до карикатурности пример. Новый онбординг. Дизайнеры считают, что он снизит порог входа и повысит конверсию. Считаем:

Pain — низкий (никто не страдал от старого онбординга).

Difficulty — высокий (много времени на отрисовку и разработку).

Probability — низкая (никаких данных, только гипотеза).

Reversibility — нулевая (онбординг встроен глубоко в код).

Какой, в итоге, приоритет был бы у фичи? Самый низкий, полагаю. А значит, можно эти же ресурсы потратить на что-то более весомое.

В общем-то, всё (ну почти).

В чём же главный плюс подхода, помимо учёта обратимости? Да в том, что его можно миксовать с чем угодно. Не хватает одного только PoD? Добавьте количество затрагиваемых пользователей и уверенность в оценке из RICE. Нужно как-то визуализировать результат таких упражнений? Кидайте его в MoSCoW. Адаптируйте.

Да, метод, как и все остальные, далёк от идеала. Подвержен субъективным оценкам (если лень искать данные). Фокус на обратимости может «сбивать прицел» в крупных проектах с низкой долей неопределённости и высокой инертностью. Подход отчасти перекликается с аджайловским Value/Effort. Но это всё нюансы, которые легко решаются подгонкой подхода под ваши реалии.

ПС: Вот ссылка на цикл об этом

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

Немного о моём опыте:

Я начинал в нулевых как разработчик, потом ушёл в дизайн и аналитику, теперь менеджерю и продюсирую всякое. Семь лет управлял и помогал управлять стартапами, потом покорял корпоративные эдельвейсы (VISA, Альфа, Сбер, Лукойл, ВК, Атом etc). С 2017 года активно преподаю в ВУЗах, веду корпоративное обучение. Подробнее о моих умениях в закрепе канала.

Что я могу дать в рамках менторства:

1. Всё, что связано с управлением. Продуктом, проектом, командой, метриками, финансами, рисками, ожиданиями и всем, что ведёт к успешному запуску.

2. Харды: продуктовый дизайн, аналитика, разработка, архитектура. Помогу подтянуть неподтянутое или усилить сильное.

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

4. Подтягивание софтов в их классическом понимании. Коммуникации, ответственность, ведение дискуссий, работа с манипуляциями и всё такое.

5. Настройка процессов. От внедрения методологий до перевода бухгалтерии на ЭДО. Разработка, адаптация, борьба с саботажами и прочие прелести.

6. Вообще всё, что на стыке дизайна, технологий, бизнеса и аналитики.

И да, это менторство за деньги. О том, почему я перестал менторить бесплатно, можете почитать в прикреплённом к этому посту сообщении.

Пишите мне или @mashavanassi, созвонимся, обсудим детали.

И у нас победитель. С небольшим отрывом вперёд вышел «Вредный MVP», за ним следом «Стейкхолдеры и двойные сигналы». Это будут темы следующих 2х стримов.

Остальные темы пойдут либо в посты здесь, в канале, либо в статьи на сайте.

Не переключайтесь.

Проблемы белых. Зовут выступать на конференцию, в анкете нужно указать компанию, в которой работаю. А я не работаю ни в какой компании. С двумя сотрудничаю, но не настолько плотно, чтобы писать их названия на бейдже. Что делать?

Спойлер следующего стрима.

Уже скоро: во вторник (14.10) в 20:00 МСК.

Лет 10 назад один из моих клиентов спросил, почему нельзя писать код сразу без багов. Я тогда выдал ему очень красочную аналогию, и она сработала. Впоследствии я ещё не раз к ней прибегал и, чаще всего, успешно.

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

Уже много лет я не работаю на фрилансе, но до этого долго и успешно практиковал удалённую разработку и проектирование. И иногда клиенты задавали презабавный в своей наивности вопрос: «А сразу без багов писать нельзя?» или «А нельзя сразу сделать так, чтобы юзеры не отваливались?».

Так вот, хочу ответить всем своим будущим и бывшим клиентам и партнёрам: «Нет, нельзя. Меньше — можно, вообще без — нельзя.»

Запомните одну простую штуку. Создание серьёзного программного продукта — это не только производственный процесс. Это исследование. Вот вы знаете, как положить асфальт. И когда вам говорят, что нужно покрыть 5 квадратных кэмэ дороги, вы быстренько считаете расход, технику, амортизацию, логистику – и выдаете сроки и сумму. А теперь замените в предыдущем предложении слово «дороги» на «стены». Чуете? Никто, ни один дебил до вас, не клал асфальт на пять километров стены. По отдельности – все понятно. Вот асфальт, он простой. Вот каток, он тоже несложный. Вот сорок рабочих, они умеют укладывать простой асфальт несложным катком. А вот стена, и о ней вы тоже знаете практически всё. Но вместе — какая-то поебень получается.

И пусть мы представим, что асфальт на этой стене оправдан. Всё равно, эти сорок профи изведут вам гору асфальта, прежде чем поймут, как его класть. Вот переведённый асфальт — это и есть баги и минусы в воронке.

Допустим, теперь вы умный. Вы позовете мастера по нестандартным дорожным покрытиям. Он не умеет класть асфальт, как сорок трудяг, но он способен мыслить нестандартно и знает всё о силе трения. И даже он изведет вам некоторое количество асфальта в процессе поиска решения. Меньше, чем сорок строителей, но он и денег отдельных за свою работу возьмёт.

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

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

У меня всё. И да, все аналогии лживы.

Стрим ровно через сутки, 14.10 в 20:00 МСК. Поговорим про то, почему запуск MVP может навредить продукту/бизнесу и что делать, чтобы этого избежать.

Основные темы:

1. Термины, отличия от прототипа и типы потенциального вреда.
2. Типичные ошибки запуска.
3. Радикальный минимализм и чем он может обернуться.
4. Реакция рынка и последствия плохого MVP.
5. Продуктовый, технический и дизайн-долг.
6. Чем чреват запуск без продуманных гипотез.
7. Почему нужно ограничивать риск, а не продукт.
8. Метрики и практические советы.

Записи не будет (я писал уже, почему так). Презентации, скорее всего, тоже (расскажу на стриме о причине).

Шарьте, наверняка кому-то будет интересно.

Начало через 10 минут: https://telemost.yandex.ru/j/2742891779

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

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

Не переключайтесь.

Начал писать третью статью про сущности в информационной архитектуре — и, как обычно, немного увлёкся. Пришлось разбивать на две части: одна получилась больше про теорию, в другой будут практические материалы.

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

В общем, налетайте.

На неделе будут «сущности vol.2»

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

Это, видимо, никогда не закончится.

А у меня снова хорошие новости. На следующей неделе я заканчиваю работу с одним из клиентов. Бизнес упакован, процессы налажены, команда довольна. Осталась пара формальностей со структурой документации и её поддержкой, дело пяти дней.

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

Я умею в методологии и процессы, документацию, архитектуру, продуктовый дизайн с аналитикой, в обучение команды. Опыт в этой нашей айтишке 20+ лет, больше 10 из которых — в управлении и обучении. Подробнее о моих умениях в закрепе канала. О том, кто я такой и почему это всё себе позволяю — на сайте.

Если у вас есть интересные продукты/проекты и задачи, пишите @mashavanassi или мне @sherer_pro.

Готова вторая часть про информационные сущности (и она же четвёртая во всём цикле про информационную архитектуру).

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

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

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

Я обещал, что не буду задерживаться со следующей частью цикла? Ловите.

Третья статья про сущности в информационной архитектуре, теперь про их свойства и способы фиксации.

Пока с IA приторможу, накопилось много другого материала.

Вы не просили, а я всё равно сделал:

(Pain ÷ Difficulty) × Probability × Reversibility

Первая статья в цикле про PoDPR — метод приоритизации, который учитывает не только важность проблемы/задачи и сложность реализации, но и вероятность «попадания», риски и обратимость решения. Что это за подход, как он может улучшить существующие методологии и как сделать его расширяемым под конкретно ваши реалии.

В следующей статье будет про то, как считать PoDPR без манипуляций и вкусовщины.

Почему гипотеза без риска и измеримости — это не гипотеза, а херня. И не просто херня, а херня крайне вредная.

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

Вы молодцы? Конечно, нет. Это всё равно интуиция, просто замаскированная под решение. Нормальная формулировка всегда жёсткая и двусторонняя: «если сделать X, то Y изменится на Z по такой-то причине».

Она вынуждает объяснить механику эффекта. Почему это вообще должно сработать? Где в цепочке пользовательского поведения наступит перелом? Что именно поменяется в принятии решения?

Если сократить онбординг до трёх шагов, то конверсия в первый целевой шаг увеличится на 10–15%, потому что пользователи меньше устают и быстрее достигают момента ценности.

Вроде, ок. Измеримо, чётко. Или нет? Нет. В любой гипотезе должен быть риск. Если риска нет, то что тут вообще проверять? Пилите, и всё.

Если сократить онбординг до трёх шагов, то конверсия в первый целевой шаг увеличится на 10–15%, потому что пользователи меньше устают и быстрее достигают момента ценности. Ключевой риск: упрощение может убрать важные уточнения, из-за чего качество первичной настройки упадёт.

Когда риск не зафиксироан, он всё равно существует, просто прячется. И потом вылезает в самый неожиданный (и дорогой для бизнеса) момент: на проде, в репутации, в откате решения. Риск — это часть гипотезы. Он показывает, на какой участок системы вы давите, где у вас наименьшая обратимость, где потенциально полетит метрика, которую никто даже не вспомнил включить в мониторинг.

Хорошая гипотеза не только говорит, что улучшится, но и честно показывает, что может сломаться. Именно поэтому гипотеза — это инструмент управления неопределённостью, а не просто формальность в документации, которую нужно заполнить, чтобы запустить А/В.

Если добавить персональные рекомендации на основе истории действий, то среднее время в продукте возрастёт на 8–12%, потому что контент станет релевантнее каждому пользователю. Ключевой риск: отсутствие достаточного количества данных на старте приведёт к низкому качеству рекомендаций и обратному эффекту.

Если добавить автодополнение и ранжирование результатов по популярности, то доля успешных поисковых сессий вырастет на 15–20%, потому что пользователи будут быстрее находить нужное. Ключевой риск: неверная логика ранжирования может скрыть важные результаты и ухудшить восприятие поиска.

Если на карточках продукта показать рейтинг и количество использований, то конверсия в просмотр деталей увеличится на 10–12%, потому что социальное доказательство снижает неопределённость. Ключевой риск: низкие рейтинги или небольшое количество оценок могут, наоборот, отпугнуть пользователей.

Если добавить бесплатный тестовый период на 7 дней, то конверсия из регистрации в оплату увеличится на 20–25%, потому что снижение первичного барьера повышает вероятность пробного использования. Ключевой риск: увеличение доли нецелевой аудитории, которая «поживёт» бесплатно и не перейдёт в оплату.

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

Отдельной темой может стать диапазон процентов в формулировке гипотез, потому что «как их тогда подтверждать или опровергать?»

Но это уже совсем другая история

Рынок найма мутировал.

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

Парадокс: на макроуровне кадровый голод, на микроуровне тьма специалистов, которые не могут найти нормальную по баблу и задачам позицию.

Но позиций, всё же, сильно меньше, чем соискателей. Вот вам немного фактов, можете не читать:

Если верить hh, то на одну вакансию CIO сейчас приходится 64.4 резюме. На арт-директора — 87.1 резюме. А вот менеджеры и консультанты по стратегии почти добрались до сотки, у них 94,7 резюме на вакансию.

По тем же данным, в сегменте «белых воротничков» в июне вакансий стало на 25% меньше, чем годом ранее. Число активных резюме при этом выросло на те же 25%, а новых резюме – на 36%, если сверять с прошлым годом.

В айтишечке с количеством резюме ещё веселее: оно выросло на 46%, а вакансий, наоборот, сократилось на 6%. При этом аж 42% соискателей — из Москвы и Московской

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

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

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

И поговорим мы об этом в ближайший четверг, 27.11, в 20:00. Ставьте в календари и шарьте знакомым. Не будет никаких презентаций и лекций, будет тёплое ламповое общение. Ниже несколько тем, которые интересны лично мне, но если вы подключитесь со своими, будет ещё круче.

С работодателями и руководителями:

- Почему нанимать «просто айтишников» теперь нет смысла и нужно искать людей с хорошими операторскими навыками.
- Как построить небольшую, но сильную команду с ИИ, не раздувая штат.
- Почему надо растить сеньоров из мидлов, а не ждать рок-звёзд.
- Почему и как надо честно переписать вакансии и процессы найма.
- Ну и главное: почему к ИИ нужно применять риск-менеджмент, а не рассматривать его просто как средство экономии.

С соискателями и специалистами:

- Зачем продавать себя как «уверенного пользователя ИИ» и как им стать (и я не про промпт-инжиниринг и фиксиков в IDE, которые пишут твой код за тебя).
- Как укреплять фундамент, который не сожрут бездушые нейросети (и что это вообще за фундамент такой).
- Почему иногда нужно трезво пересмотреть ожидания по удалёнке и ЗП.
- Почему важно брать на себя управление обучением, а не ждать «корпоративных курсов».

Маленький спойлер: очень скоро плоскость обязанностей переместится из количества закрытых задач и написанных строчек кода в принятие ответственности за эти самые задачи и строчки.

Решил немного дополнить первую статью про PoDPR, и в итоге она стала ещё большим лонгридом. Разбил на две: в первой — основы и усиление других подходов к приоритизации, во второй — варианты расширения метода.

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