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

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

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

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

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

Со своей стороны обещаю фундаментальный подход к документации и процессам, со стороны остальной команды обещаю непрерывное включение в продукты и их механики.

Ниже — цитата от одного из ключевых участников:

Так-то мы ищем много специалистов в разных областях и готовы адекватно платить за экспертизу.

Предстоит работать в экспериментальном проекте для разработчиков и девопсов. В дерзкой компании, создающей облако, готовой к жесткой конкуренции с Yandex Cloud, VK Cloud и прочими, намеренной полностью перепродумать UX для облачных решений в России и мире. От Хабра получили приз как самый рейтинговый блог новой компании. Из-за нас крупные компании собирают встречи, чтобы выяснить кто мы и почему такие дерзкие.

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

Белая зарплата, ДМС, пройдены все согласования для работы в России, гибкое начало дня. Стабильность нормальной компании, дух стартапа и открытые пути для роста и ценный востребованный опыт.

Шарьте, позиция реально крутая. Пишите в личку мне или @mashavanassi

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

Я не пропал, просто малость подзаебался (очень интересный и сложный проект, даже два+).

На днях ждите новую статью, и вот вам спойлер:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто я такой

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

Что я умею

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

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

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

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

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

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

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

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

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

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

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. Планируйте так, будто чужой сервис точно однажды упадёт.

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

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

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

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

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

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

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

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

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

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

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

Шарьте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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