Когда продакт-менеджер несет ответственность за баги в разработке

Когда продакт может быть виноват в том, что много багов в разработке? Когда в продукте становится слишком много багов, виноват далеко не всегда Engineering Manager. Иногда проблема начинается гораздо раньше – с работы самого продакта. Новые инициативы от автора канала тут https://t.me/FreshProductGo/1792, а расширить насмотренность, включая запуски на новых рынках можно в Разборы кейсов, 76 разборов пришли, всего свыше 190 тестовых и реальных задач продактов. Плейлист доступен по ссылке, сайт разборов тут. Самая распространенная ошибка – считать, что задача продакта заканчивается после написания требований. На практике качество продукта формируется задолго до того, как разработчик открывает IDE. 1. Продакт приносит в разработку не решение, а идею. В задаче написано «добавить кэшбэк», но нет ответов на десятки вопросов: что происходит при возврате товара, как работает начисление при частичной оплате, что делать при отмене операции, как меняются лимиты, что видит пользователь при ошибке. Разработка начинает самостоятельно принимать продуктовые решения. Чем больше таких решений принимается «по ходу», тем выше вероятность дефектов. 2. Продакт меняет требования после начала разработки. Иногда это происходит незаметно: «давайте еще вот это добавим», «а здесь сделаем немного иначе», «клиент попросил еще один сценарий». Каждое подобное изменение увеличивает сложность реализации и резко повышает риск регрессии. Хороший продакт понимает, что изменение требований во время спринта — это не бесплатное улучшение продукта, а дополнительный риск для качества. 3. Слишком большие задачи. Если в одном релизе одновременно меняется онбординг, профиль, бонусная программа и система уведомлений, вероятность того, что все пройдет идеально, минимальна. Зрелый продакт умеет декомпозировать инициативы так, чтобы каждая поставка решала одну конкретную проблему и могла быть независимо протестирована и быстро откатана. 4. Игнорирование сложных сценариев. Многие требования описывают только "happy path" – что происходит, когда все идет идеально. Но большинство критичных багов рождается совсем в других местах: медленный интернет, повторная отправка запроса, два устройства одновременно, отмена операции посередине процесса, устаревшая версия приложения, отсутствие данных, интеграция, которая не ответила. Если продакт не думает об этих сценариях на этапе проектирования, потом команда будет искать их уже в продакшене. 5. Приоритизация только новых функций. Если каждый квартал roadmap состоит исключительно из новых возможностей, а время на рефакторинг, стабилизацию и улучшение архитектуры постоянно переносится, через несколько месяцев команда начинает тратить все больше времени на исправление последствий собственных релизов. Технический долг редко появляется сам по себе. Чаще всего это сознательное продуктовое решение: еще раз выбрать новую функцию вместо качества системы. 6. Продакт может перегрузить команду когнитивной сложностью. Иногда каждая новая функция сама по себе небольшая, но вместе они создают десятки пересекающихся бизнес-правил. Например: разные тарифы, исключения для сегментов, специальные условия для партнеров, акции, промокоды, бонусы, ограничения по регионам. Каждое новое правило кажется логичным, но их комбинации начинают расти быстрее, чем команда успевает их тестировать. В какой-то момент продукт становится настолько сложным, что баги становятся неизбежными. Также обратите внимание на предложения от редакции тут https://t.me/FreshProductGo/1792