Павел Шерер

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

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

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

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

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

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

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

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

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

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

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

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. Используйте метрики для честной обратной связи, а не для красивых отчётов.

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

К чему это я?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шарьте

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

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

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

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

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

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

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

Риски невидимых зависимостей.

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

Я часто говорю о рисках интеграций, настало время привести несколько примеров.

Google Fonts в Китае, 2014–2015.

Когда в Китае начали активно блокировать Google CDN, сайты, построенные на красивых веб-шрифтах, превратились в визуальную катастрофу. Текст обрушивался в дефолтные fallback-шрифты, где ломалась иерархия, исчезали акценты, рушился tone of voice бренда. Продукт формально работал, но доверие и «фейс» компании сыпались прямо на глазах.

Падение Stripe, сентябрь 2022.

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

GitHub Actions, ноябрь 2020.

Инфраструктура автоматизации упала почти на сутки. Команды, полностью завязанные на CI/CD через GitHub, встали: код не собирался, тесты не прогонялись, релизы зависали. Многие команды в спешке начали подключать Jenkins или GitLab CI, теряя дни и недели на переключение. Кто-то сорвал контракты, потому что «не смог выкатиться в срок».

Amazon S3 outage, февраль 2017.

Один из крупнейших кейсов в истории облаков. Из-за ошибки при отладке команда AWS положила S3 в регионе US-East-1. На несколько часов часть интернета превратилась в неоткрываемое говно: Slack, Quora, Trello, Guardian, Imgur и сотни других сервисов. Самое смешное, что даже статус-дашборд AWS перестал работать, потому что его изображения хранились в том же S3.

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

Что делать, чтобы этого не допустить?
1. Фиксируйте карту зависимостей. Это должен быть прям отдельный сквозной артефакт.
2. Имейте альтернативы. Если один смс-шлюз сдох, вы должны мгновенно перейти на другой.
3. Проверяйте продукт на «обрыв проводов». В E2E-тестировании проходитесь не только по базовым сценариям.
4. Планируйте так, будто чужой сервис точно однажды упадёт.

Потому что упадёт.

Погнали, готовность 5 минут: https://telemost.yandex.ru/j/6187704687

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

Закреп с тем, кто я такой и что умею.

Кто я такой

Продуктовый методолог и IT-продюсер. В IT больше двадцати лет. Начинал как разработчик, потом ушёл в дизайн и аналитику. Из-за этого говорю абсолютно со всей проектной командой на одном языке. Мой сайт https://sherer.pro, там можно почитать мои статьи и немного больше узнать о моём опыте.

Что я умею

1. Формировать проект и проектную команду с нуля и до релиза. От этапа зарождения идеи до выхода на рынок, настройки поддержки и механик дальнейшего развития. Этот пункт включает в себя все следующие.

2. Формировать представление о новом продукте. Определю пользовательские, технические, функциональные и бизнес-границы продукта, помогу посчитать экономику, выявлю риски и ограничения. Упакую бизнес в продукт.

3. Помогать бизнесу выстроить правильные процессы. Могу условную бухгалтерию перевести на условный ЭДО, могу безжалостным аудитом найти и уничтожить узкие места проекта, могу ускорить медленное и автоматизировать ручное.

4. Проектировать и управлять проектированием. Проработаю проектную методологию с учётом специфики бизнеса и проекта/продукта, выстрою правильную документацию и научу сотрудников всему этому следовать.

5. Обучать. Управлению цифровыми продуктами, всевозможным методологиям продуктового дизайна, коммуникациям внутри проектных команд, функциональной, информационной архитектурам и ещё массе всякого. Преподаю (в том числе в ВУЗах, типа ИТМО и РАНХиГС) уже 8 лет

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

Пробежимся по словарю (roadmap vs релиз‑план vs бэклог, 5C, горизонтам и прочему). Обсудим 12 антикейсов с признаками и контрмерами. Сформируем чеклист таких признаков. Отдельно будет про реалии 2025 и ритуал похорон лишних дат.

Зайдет продактам и проджектам, аналитикам, дизайнерам, тимлидам и владельцам бизнеса.

Собираемся 21.08 в четверг, в 20:00 МСК. Скорее всего, в Телемосте, но чёрт знает. Туда поближе решу.

Шарьте, наверняка кому-то из ваших знакомых это будет интересно

Я ничего не хочу сказать, но встреча двух президентов в Анкоридже — это слишком сильные ассоциации, чтобы я ими с вами не поделился

Есть у меня небольшие подозрения, что стрим в телеге больше какое-то время не будет работать. У нас по плану поговорить про роадмап. Где будем встречаться, есть идеи?

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

Есть у меня один питомец, wlist.fun. Это такой малютка, который позволяет тебе создать вишлист, отправить его друзьям и те (без регистрации и смс) забукают подарки. Так ты не получишь на свой ДР несколько книг Талеба, а ребята не будут париться, что же тебе такого подарить.

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

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

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

- Фильтрацию и сортировку по цене (если владелец вишлиста её указал). А то он, конечно, молодец, накидал в самое начало дайсонов за 50к, а у тебя весь бюджет на подарок как две шаурмы.

- Опция автоматического сокрытия отмеченных подарков. Чтобы их видел только владелец и тот, кто, собственно, их отметил. Снял отметку — снова всем доступно.

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

- AI-ассистент для подбора подарков. Часто ты вообще нихрена не знаешь, что тебе хочется. Тогда просто пишешь ассистенту в свободной форме, типа "играю в преферанс по субботам, на выходных чилю в собственном поместье, есть английский сеттер и сорок голов крепостных" — и он подбирает тебе подарки в тему.

Если есть ещё идеи — обязательно кидайте в комменты, моя фантазия иссякла

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