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

Специально для таких «экспертов» даю десятисекундный мастер-класс. Зажимаете ALT и набираете на цифровой клавиатуре (там, где numpad):

- 0151 — получаете «тире»
- 0171 — получаете левую «ёлочку»
- 0187 — получаете правую «ёлочку»

Со смартфона ещё проще, там просто нужно на секунду зажать нужную кнопку, и вылезут варианты.

У меня это уже настолько на автомате, что я даже об этом не думаю. Приучить себя можно за пару недель максимум.

Пишите, блять, правильно! Даже если вас посчитают за ИИ.

А у меня на подходе статья про дизайн-систему как тюрьму вашего продукта, не переключайтесь

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

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

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

Шарьте

Как внедрять новые методологии без саботажа?

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

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

1. Малые шаги: не революция, а постепенное внедрение

Не нужно в понедельник приходить и заявлять, что с завтрашнего дня у нас Scrum по учебнику. Это и есть прямое приглашение к бунту. Лучше начать с одного элемента — например, ретроспективы. Потом добавить планирование. Постепенно команда втянется, а не взбесится.

2. Союзники: ищите евангелистов внутри команды

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

3. Ясная цель: зачем и для кого

Люди не любят перемен ради перемен. Если вы внедряете новую методологию, объясните, какой конкретный бардак она убирает. «Чтобы не тратить часы на бессмысленные совещания» звучит убедительнее, чем «оптимизация рабочего времени».

4. Гибкость: адаптируйте методологию под контекст

Кто со мной знаком, в курсе, что я яростный противник шаблонов. Универсальных практик не существует. Kanban в продуктовой разработке и Kanban в техподдержке — два разных канбана. Не нужно копировать чужой опыт дословно, важно адаптировать его под реалии команды, проекта и продукта.

5. Видимый результат: быстрые маленькие победы важны

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

6. Роль руководителя

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

7. Анти-паттерны: как делать нельзя

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

8. Метрики успеха

Чтобы показать результат, нужны цифры и наблюдаемые изменения. Самые простые и честные индикаторы: меньше времени уходит на релиз, снижается количество багов в продакшене, исчезают «пустые» совещания, на ретроспективах начинают говорить больше людей. Можно добавить и косвенные признаки: сотрудники начинают предлагать улучшения сами, снижается текучка, менеджеры тратят меньше времени на ручное администрирование. А ещё — растёт доверие: если команда соглашается пробовать новые практики без скептического «опять нас заставляют», значит, методология работает.

Методология — не цель, а инструмент. Настоящий результат внедрения — не только новые правила работы, но и культура команды, которая перестаёт бояться перемен.

Как распознать саботаж на ранних стадиях внедрения новой методологии?

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

Давайте разбираться.

1. Тихое согласие

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

2. Перевод стрелок

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

3. Пассивная агрессия

Фразы вроде «ну давайте попробуем, всё равно не взлетит» или «опять менеджерам нечем заняться». Сарказм и подколы становятся инструментом давления. Формально люди не отказываются, но эмоционально обесценивают процесс.

4. Затягивание сроков

Задачи по внедрению новых практик «случайно» выпадают из приоритетов, всегда находятся дела поважнее. Если команда постоянно переносит элементы внедрения на потом — это очень тревожный сигнал.

5. Минимальное участие

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

6. Формализация до абсурда

Команда начинает педантично выполнять все новые правила, но так, чтобы они выглядели бессмысленно. Мы сделали, как сказали, а что стало хуже — сами виноваты. В дискуссиях есть очень некрасивая манипуляция: гиперболизация, доведение доводов оппонента до абсурда путём многократного усиления смысла. Это про это.

7. Рост «кухонных разговоров»

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

Как действовать при первых признаках?

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

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

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

К чему это я?

А к тому, что я полностью освободился от обязательств и готов к новым свершениям. В закрепе написано, кто я и чем могу помочь. У кого-то из вас наверняка есть интересные проекты, давайте работать. А если нет, то 100% есть у кто-то из знакомых.

Пишите мне или @mashavanassi

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

Цифры любят все: инвесторы, топ-менеджеры, команды. Но иногда именно метрики становятся оружием массового самообмана (а порой и краха всего бизнеса).

Vanity metrics

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

В 2017 руководство Medium уволило 50 сотрудников (треть штата), отказавшись от ad-driven модели на основе просмотров и кликов, потому что она вредила качеству контента. Они закрыли офисы в NY и DC, перейдя к подписной модели.

Локальная оптимизация

Команда выжимает CTR кнопки на лендинге, но при этом стоимость привлечения клиента растёт. Продукт псевдооптимизируется кусками, а бизнес в целом — деградирует. Тактическая победа вместо стратегического роста.

В 2010x YouTube отказался от ранжирования по просмотрам/CTR и перешёл к watch time, потому что оптимизация под клики порождала кликбейт и плохой долгосрочный опыт. Отказ от старого ранжирования привёл к постоянному улучшению retention в течение следующих лет.

Игнорирование лагов

Есть метрики, которые показывают результат с задержкой. Например, churn по-настоящему проявляется лишь через месяцы. Если реагировать только на «живые» цифры — можно проспать момент, когда продукт уже пошёл ко дну.

Microsoft/Bing описывает парадоксальные результаты в онлайн‑экспериментах: изменения, дающие краткосрочный прирост запросов/дохода, ухудшали долгосрочную ценность. Вывод — нужен OEC и длинные эксперименты.

Слепота к качеству

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

В 2017 Star Wars Battlefront II (EA): монетизационные метрики «сходились», но токсичный опыт вызвал грандиозный публичный скандал. Electronic Arts в спешке отключила микротранзакции в игре.

Культ одной метрики

Повторюсь, но любой, кто верит в «сакральную метрику» (будь то DAU, NPS или LTV), подписывает себе приговор. Продукт живёт системой показателей, а не одной цифрой. Ваша драгоценная NSM без сторожевых подружек — просто карго-культ.

MoviePass гнался за числом подписчиков и «ростом», игнорируя юнит‑экономику. Итог — кассовый разрыв, обвалы, массовый отток (с 3 млн до ~225 тыс).

Средняя температура по больнице

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

Blue Apron: в публичных отчётах были приличные средние показатели и выручка на пользователя, но они не спасли от болезненного IPO и провала — высокий churn съедал экономику.

Оптимизация ради отчёта

Когда команда работает не на продукт, а на красивую презентацию. Сократили cost per lead? Красавцы. И плевать, что лиды оказались дохлыми. Метрика должна быть инструментом обратной связи, а не фейерверком в презентации. Она обязана показывать реальность, даже если реальность неприятна.

Wells Fargo гналась за KPI по числу открытых счетов: миллионы фейковых аккаунтов, рекордные штрафы и многолетние регуляторные санкции — отличный пример токсичной метрики.

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

1. Создайте сбалансированную систему метрик (DAU, LTV, churn) для полной картины бизнеса.

2. Регулярно проверяйте качественные сигналы и интегрируйте их в дашборды.

3. Проводите длинные эксперименты с OEC, чтобы уловить отложенные эффекты.

4. Используйте метрики для честной обратной связи, а не для красивых отчётов.

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

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

Наблюдал тут пару недель назад итересную картину (публикую с разрешения владельца компании).

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

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

Оказалось, что «проблема» лишь в том, что все пользуются разными инструментами: дизайнеры фигмой, аналитики конфлюенсом, разработчики гитлабом. Когда команда была небольшой, это не создавало трудностей: всё решалось на дейликлах. Дизайнеры без проблем ориентировались в небольшом тогда конфлюенсе, аналитики легко шастали по макетам.

Но с увеличением команды это стало неудобно: тьма изменений, которые стало сложно отслеживать даже с трекером. Классика.

Можно было бы начать перестраивать процессы, если бы планировалось продолжать найм. Но команду не собирались больше расширять, и мы нашли более простое и дешёвое решение.

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

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

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

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

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

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

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

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

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

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

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

Но не о всяких 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

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

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

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