Павел Шерер

Выступал вчера на форуме «Цифровые решения» от Национального Центра «Россия». Говорили о том, как создавать продукты, которыми пользуются. Давно не участвовал в таких сессиях, приятно было вспомнить. И да, под софитами жарко пиздец

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

(Pain ÷ Difficulty) × Probability × Reversibility

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но не о всяких 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. Но это всё нюансы, которые легко решаются подгонкой подхода под ваши реалии.

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

Грядёт время нового стрима:

14.10 (вторник) в 20:00 МСК

На этот раз хочу предложить вам парочку старых и несколько новых тем на выбор:

1. Вредный MVP. Типичные ошибки, урезанный опыт, влезание в долги, гипотезы и самообман, прототипы, месть рынка.

2. Фейковые инновации. Псевдо-ценности и псевдо-ИИ, новые обёртки старого, плагиат, разрушение культуры.

3. Роадмап и деньги. Метрики вместо чекбоксов, outcome вместо feature, бюджет вместо инженерии, польза вместо дат.

4. Пожаротушение. Огонь как часть системы, буфер хаоса, отличие пожаров от хотелок, роль документации и коммуникации, контролируемое горение и пост-мортем.

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

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