🔧 Project manager и баги: кто виноват и что делать? В продолжение предыдущего поста**…

Расскажу пару реальных кейсов, когда баг прилетал не тому — и как я это решал 👇

🧨 Случай 1: “Неправильная логика” ⚰️ Что случилось: После релиза заказчик выявил "неправильную логику" работы функциональности и пошёл искать виновника по цепочке — разработчик, потом тестировщик, потом... к соседу. Все в панике, не знают, все ищут виновников и отвлекаются.

🕵️ Что выяснилось: Жалоба касалась логики, которая вообще не была предусмотрена в ТЗ. То есть баг — это «хотелка», которой просто не было в проекте.

🧯 Что сделал я: Зашёл в бюрократическое хранилище, достал подписанные требования, спокойно объяснил всё заказчику и... 💡 договорились, что доработаем это в следующем релизе. Всё: минус паника, плюс доверие и спокойствие команд.

🧨 Случай 2: “Специально ухудшили качество?” ⚰️ Что случилось: Релиз вышел с парой шероховатостей. Заказчик напрягся, начал спрашивать, почему не всё реализовано.

🧠 А на деле: Мы заранее осознанно пожертвовали частью качества, согласовав это с заказчиком, чтобы не тормозить более приоритетные задачи. Но спустя пол года все договоренности забываются, особенно ответственное лицо от заказчика меняется.

🧯 Что сделал я: Подтвердил договорённости, напомнил про сроки и ограничения. Заказчик понял: это не “халтура”, это управление приоритетами.

🎯 Вывод: ❗ Команда не всегда в курсе всех договорённостей и бизнес-решений — и не обязана. 🛡 PM — это тот, кто: — держит фокус на ожиданиях — несёт ответственность за приоритеты — и не позволяет багам превращаться в охоту на ведьм

😑 Мини-басня "по простому" Баг, который упал в прод — это не всегда ошибка. Иногда это компромисс, подписанный кровью и дедлайном. И вот тут важно: ты как PM — не ищешь виноватых, а защищаешь команду.

💬 Интересно ваше мнение по кейсам, буду рад обратной связи и ваши примеры!)

@project_manager_education

В этом посте были ссылки, но мы их удалили по правилам Сетки