Давайте поговорим о культе метрик и к чему он может привести.

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

За последние 10-20 лет в IT аналитика стала решающим фактором в принятии продуктовых решений. Дашборды, отчёты, графики и схемы — это то, на чём мы строим свои продукты. Это не плохо, данные для того и нужны, чтобы их анализировать.

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

Давайте я приведу несколько примеров:

В 2015-2017 Facebook убеждал медиа «переходить на видео», показывая им астрономические показатели Average Watch Time и Video Views. Позже в суде оказалось, что ребятишки малость погорячились (до 900% по данным иска) и Facebook знал об этом больше года. Издатели уволили сотни текстовых редакторов, вложились в видеопродакшн, но получили только просадку по баблу. В итоге Facebook выплатил $40 млн компенсации рекламодателям, а понятие «pivot to video» стало мемом.



В 2010 году соц-новостник Digg решил угодить издателям: в четвёртой версии приоритет отдали автопостам медиа, а не голосам пользователей. Через неделю комьюнити устроило «Quit Digg Day» и дружно съебало на Reddit. Трафик Digg рухнул на 25% за месяц, а к 2012-му — на 90%. Команду урезали, компанию продали за копейки. Метрика «объём партнёрского контента» стала главенствовать, и комьюнити просто вышло из чата. 



В 2018 Snapchat решил поднять Time in App, и расхерачил интерфейс, как ты свой палец с заусенцем: разделили чаты и сторис, усложнили навигацию. Пользователи взбунтовались, петицию против редизайна подписали 1.2 млн человек, сервис впервые потерял 3 млн DAU. Акции просели на 20%, и компания врубила заднюю. Я прям вижу, как топы спускают «надо поднять минуты в приложении», а дизайнеры «хуйня вопрос, усложним UX»

Да, там было не всё так просто, но это — большие, публичные компании. Сколько таких проёбов было у компаний помельче?

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

Что делать на практике?

1. Держите пул из 3–5 метрик: рост, удержание, качество, выручка, удовлетворённость и тп. Не выделяйте одну, стройте иерархию. Если нижняя метрика растёт, а верхние нет, то должны возникнуть вопросики.

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

3. Ставьте «гвардейцев» — вторые метрики, которые тормозят злоупотребления (например, NPS к Time in App). Это позволит вовремя очнуться, даже если «зависимые» метрики не ведут себя подозрительно.

4. Слушайте пользователей: юзтесты, саппорт, соцсети. Не только цифры в дашбордах, но и реальные отзывы.

Я для себя обычно разбиваю показатели на 3 слоя:

1. North Star (LTV/CAC, валовая маржа). Это то, к чему идёт продукт и компания. На короткой дистанции их толком не посчитаешь.

2. Здоровье продукта сегодня (конверсия оплаты, churn). А вот это как раз можно измерять если и не в моменте, то почти.

3. Пульс системы (5xx ошибки, latency, аптайм). Это чаще технические метрики, от которых зависит качество продукта.

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

А вот вам альтернативная точка зрения. IT-мир неоднороден, он развивается и иногда разницы трактовок вызывают недопонимания. Я противник любых культов. И не особо важно, методолические они, продуктовые или поклоняющиеся «успешным примерам индустрии». Проёбываются все одинаково

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

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

У Даши на канале крутой интерактив. Го качаться

ИИ рулит. И захватывает наш с вами родненький рынок.

Сейчас все специалисты делятся на 4 категории:

1. Активно юзают ИИ для повседневных и профессиональных задач. Научились в промптинг, задают иишкам правильно сформулированые вопросы, не чураются выдавать им роли. За этими ребятами будущее.

2. Только пробуют GPT. Осторожно, иногда даже скрывая это (потому что начальники из четвёртой категории могут дать пизды). Эти ребята или сдохнут, или перейдут в первую категорию.

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

4. Четвёртая — самая мерзкая категория. Луддиты, воюющие с прогрессом. Они не просто отрицают использование ИИ, они БОРЯТСЯ против него. Эти ребята особенно опасны, если они начальники. Но совершенно безвредны как линейные специалисты (они либо примкнут к первым категориям, либо в ближайший год-два будут вынуждены сменить профессию).

Времена, когда джун с подпиской ChatGPT мог сойти за мидла, проходят. Сейчас компании понимают, что мидл с тем же GPT — это, конечно, не сеньор, но по эффективности может в мясо разъебать трёх классических мидлов. А это значит, что в очень скором времени нашу отрасль ждёт кризис: нам будут нахуй не нужны разработчики-джуны. Ведь даже сейчас OpenAI Codex или GitHub Copilot эффективнее, надёжнее и дешевле любого джуна.

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

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

Так мы сотню не соберём. Едва за полтос перевалили. Поднажмите, что ли

Ну что, преза готова.

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

Как обычно, никакой записи, только хардкор.

Шарьте

К слову об обучении и менторстве.

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

Сейчас у меня новый поток охуительных менти. Их шестеро, и все они вдохновляют меня похлеще Энтони Старка.

В своё время (две тысячи лет назад) Сенека в письмах Луцилию писал: «Если же мне предложат мудрость на условии, что я должен хранить её в тайне и не передавать другим, — я откажусь: никакое благо не радует, пока им не делишься с другом».

Я стараюсь делиться и считаю, что это то немногое, чем я делаю мир лучше.

Я преподаю в нескольких ВУЗах, пытаясь хоть немного разбавить системное и постоянно запаздывающее образование. Я менторю тех, кто хочет расти.

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

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

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

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

Если же ты ещё не менти или даже не планируешь им стать, но тебе очень-очень нужно в чатик, пиши в личку, обсудим и всё сделаем

Вот тут будет обсуждение: https://news.1rj.ru/str/shererpro/243

Наткнулся тут недавно на статью Андрея Шапиро про развитие USM. Прочитал, понравилось (ну почти). А потом мне ещё несколько человек её скинули: кто-то с просьбой прокомментировать, кто-то с предложением внедрять. Каждому отдельно отвечать влом, так что вот вам небольшой и исключительно субъективный разбор SIM/КРИ-подхода.

Пересказывать статью не стану, почитаете при желании. Если коротко, это визуальная «семиэтажная» карта, которая связывает бизнес-цель, контекст, предметные объекты и первый каркас интерфейса в одном столбце. Она помогает команде увидеть сквозную логику «зачем - как - на каких данных - через какой UI», лечит типичную XY-проблему и вытягивает доменную модель.

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

Итак, плюсы и сильные стороны метода:

1. Чётко лечит XY-проблему. Первый слой «Цель» заставляет сначала сформулировать зачем, а слой «Объекты» выводит доменные сущности «на поверхность», так что ни задача-X, ни данные не потеряются. Здесь, конечно, имеет смысл уточнить, что user story вообще не решает проблему потребности, только задачи. С потребностями лучше справляется job story.

2. Сквозная трассировка «цель - процесс - данные - UI». Семь вертикальных слоёв собирают всю логику реализации в одном столбце карты, поэтому дизайнер, аналитик и разработчик опираются на единый контекст. Вот это круто.

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

4. Самый сок: SIM/КРИ отлично мапятся с Domain Driven Development и Event Storming. Цветовое кодирование слоёв и фокус на домене позволяют встроить метод в воркшопы по моделированию процессов и предметной области. Ну во всякие PI-планирования SAFe.

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

Минусы и слабые стороны подхода:

1. Тема хорошо работает на уже сформированной бизнес-модели. Если вы — динамичный стартап и ваши метрики определяются в процессе анализа и проектирования, то «чистая» цель вам попросту недоступна. А если корректируются цели, метод по каскаду распадается и карта устаревает уже через спринт.

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

3. Каркас экранов создаётся слишком рано. Да, это не UI в финальном его виде, но все мы знаем, что дизайнеры мыслят картинками. После того, как конкретный лайаут зафиксировался в их нейронных цепочках, он останется там навеки. И никакие исследования потом этого риска не снимут.

4. При большом бэклоге доска становится нефункциональной. Нет прямой связи историй с KPI, нет явного инструмента синхронизаций (а синхронизация Holst/Miro с таск-трекерами — ебля ещё та, поверьте). Так что на реально большом проекте вы будете тратить целого проджекта или двух на синхронизацию доски и трекеров. Классический USM проще, поэтому и синковать его не так сложно.

5. Фасилитация, кривая обучения и избыточность на маленьких фичах. Объединил это в один пункт, потому что метод реально сложный. На мелкой хрени типа «добавить оплату через Х» он избыточен. Для полного его понимания и эффективного применения не достаточно просто скинуть статью. Ну и без грамотной фасилитации карта, как я уже сказал, устареет буквально через спринт.

Есть ещё недостатки, типа сложностей с инкрементальной поставкой и перебором upfront-аналитики, но и так получился лонгрид, телега мне тут пишет минусы в количестве символов

А хотите подробный и исчерпывающий пост (а может, даже статью) про заблуждения вокруг связки «UX-CX»?

Народ, Андрей Шапиро пришёл в комментарии к разбору подхода SIM/КРИ. И накидал несколько довольно интересных тезисов. Го читать. И подписываться на канал Андрея.

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

Между UX и CX в последнее время много споров. Кто-то считает, что первый включает в себя второй, кто-то наоборот. Я решил немного развернуть эту тему, чтобы вы могли просто кидать в оппонента ссылкой: https://sherer.pro/blog/ux-vs-cx-kto-kogo-vklyuchaet/