«Успеть до понедельника»

Мы собираем практику и смыслы продакт-менеджмента: от CustDev и JTBD до бэклога, онбординга и роста метрик. Даем простые чек-листы, рабочие примеры и разборы, чтобы вы быстрее принимали продуктовые решения. Без воды и хайпа — только то, что помогает делать продукт и карьеру сегодня.

Открыть в Telegram Другие публикации

Автор:Немного продакт

•21 марта 2026 г.

релизархитектурапродакт-менеджмент

Предлагаю сюжет для корпоративного триллера.

В главных ролях:

👩‍🦰 Катя — продакт. Идет запуск стратегического модуля, куплена реклама, следующий карьерный шаг уже маячит на горизонте. Она умеет дожимать проекты и в жёстких сроках чувствует себя как рыба в воде.
👨‍💻 Игорь — техлид. Из тех, кто знает легаси так, как знают только люди, которые сами его и писали. Без лишнего шума, но крепкий инженер.

История реальная — кейс рассказан мне на интервью в рамках исследования лидерского опыта в ИТ.

За неделю до релиза, во время груминга.

Игорь говорит:

Под нагрузкой система может начать деградировать. Я серьёзно: нужно пересмотреть архитектуру, иначе после релиза будет плохо.

Катя слышит не риск, а угрозу срокам.

- Игорь, акционеры сказали: «к понедельнику». Значит, к понедельнику. Рассказывать мне сейчас, почему это невозможно — бессмысленно.

Техлид пробует объяснить, но Катя перебивает:

- Речь сейчас не про качество, а про скорость. Если не можешь уложиться — скажи честно. Может, это просто не твой уровень задач?

Команда замолчала. Кто-то уткнулся в ноутбук. Кто-то стал старательно что-то записывать.

Дальше, конечно, были тикеты и эскалация, но точка невозврата была пройдена именно здесь. Решение принято: «костылим, идём в релиз».

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

А Игорь принял оффер другой компании — выбрал место поспокойнее.

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

Финал простой: релиз состоялся, и галочка, конечно, стоит. Только цена этой галочки оказалась уж больно высокой.

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

📝 А вас хочу спросить вот о чем: если бы вы были Катей — дедлайн горит, бизнес давит, техлид говорит о рисках — как бы вы принимали решение? Как разговаривали бы с командой? И был ли шанс у Кати, сорвавшись, откатить ситуацию?

Автор: Елена Логачева 🫎Эмоции успеха

#EQ #эмоциональныйинтеллект #конфликт

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

Дискуссия

Слезы продакта

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

08:34

❤1💯1

AnDy

Ну и манипуляции «не твой уровень задач» это огромный ред флаг и прямой путь потерять доверие команды 💯

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

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

Если рассказывать продукту "бессмысленно", то чем и на основании чего происходит управление "Катей"? Зачем это нужно вообще, если она никого не хочет слышать и все опускают глаза? Или же она уже не продакт в исходном смысле этой должности? Все мы в этот момент понимаем, что цена рисков в этот момент выросла на несколько порядков? Так и на этих основаниях может игнорироваться любой этап жизненного цикла производства ПО: зачем писать и согласовывать БТ, если это качество? Зачем делать валидацию, если это качество? Зачем обеспечивать безопасность, если это качество? Зачем тестировать что-то кроме позитивного сценария, если это качество? Зачем передавать в поддержку, включая обучение 1-3 линий, если это качество? Зачем контролировать влияние от НСИ и ФЗ, на/от соседних продуктов, на/от инфрасервисов и тд и тп, тк все это процессы производства ПО, обеспечивающие качество? Может вообще не нужен результат такого Г продукта, если его качество сведено к 0?

Релиз прошёл вовремя и Катя получила хвалебное письмо от руководства.

А вот это болезнь уже в компании, ачивка получена до окончания rollout'а и передачи в поддержку после периода эксплуатации под продуктивной нагрузкой и поддержкой 3 линии. Жизненный цикл ПО основан не только и не столько на релизах в рамках V(W) модели, а ещё и на эксплуатации, вплоть до вывода из эксплуатации. В какой момент ответственность "технического владельца" продукта = продакта, который отвечает за создание и предоставление сервиса/услуги/фичи с оговоренными SLA/OLA(в отличии от "бизнес владельца", который отвечает за внедрение в бизнес и конверсию) была ограничена только "фичапушингом"? Да, их можно объединить, но кто-то должен определить критерии баланса для разрешения явного конфликта интересов.

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

Это ещё не выяснилось, тк экономия на качестве, как видно из цитаты, влияла ещё и на документирование изменений. А , скорей всего, и на другие аспекты работы команды тоже... Вместе с потерей ключевого специалиста, это с 90% вероятностью, полный рефакторинг сервиса, что потребует времени на анализ, проектирование и разработку, потребует инвестиций и маратория на бизнес изменения (CR) на несколько месяцев, что приведет к потере темпа Бизнесом, росту связанного капитала в Capex, а, возможно, и к убыткам из-за оттока клиентов. Так что то, что "посчитал HR" - лишь малая часть от разрушения процессов производства и поддержки ПО силами "Екатерины Великой"

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

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

09:51

❤1👍1