Многие конфликты запрограммированы устройством компании.
Представим обычную ситуацию. Крупный клиент готов подписать договор, если компания добавит новую функциональность к определённой дате. Продажи говорят: сделку нельзя упустить. Руководитель проекта предупреждает: при текущих ресурсах срок нереалистичен. Технический контур видит риск: быстро сделать можно только ценой качества и технического долга. Менеджер продукта понимает, что новая функция не входит в roadmap и может разрушить экономику продукта. Кто должен принять решение? Часто в этот момент собирают совещание, где каждый отстаивает свою позицию. Формально решение принимается «коллегиально». Фактически — либо побеждает самый настойчивый, либо вопрос уходит наверх. Но операционная модель должна работать иначе. Решение готовят несколько ролей, но у него должен быть один владелец. Продажи показывают ценность сделки: выручку, вероятность закрытия, стратегическую значимость клиента и возможные коммерческие компромиссы. Руководитель проекта оценивает последствия для сроков, бюджета, обязательств и ресурсов. CTO и техническая команда определяют реализуемые варианты, риски и цену технического долга. А Product Manager принимает решение по продуктовому приоритету — в пределах P&L своего продукта. Он может: — включить функцию в roadmap; — сократить scope; — перенести срок; — выделить дополнительный ресурс; — принять допустимое снижение маржи; — предложить отдельную кастомизацию; — отказаться от обязательства. То есть Product Manager не просто «выслушивает мнения». Он выбирает один из вариантов с учётом коммерческих, проектных и технических последствий — потому что отвечает за экономику продукта, его развитие, поставку результата и загрузку команды. Но его полномочия не безграничны. Если решение затрагивает несколько продуктов, требует перераспределить ресурсы между командами или выходит за пределы P&L одного продукта, оно эскалируется CPO. Если вопрос влияет на общий P&L, стратегию или ресурсы всего бизнес-юнита — руководителю БЮ. Получается простая логика: — один продукт — решает Product Manager; — несколько продуктов — CPO; — весь бизнес-юнит — руководитель БЮ. Хорошая операционная модель не устраняет конфликт интересов. Она не заставляет продажи перестать думать о выручке, проект — о сроках, а CTO — о качестве. Она делает другое: заранее определяет, кто готовит решение, кто его принимает и где заканчиваются его полномочия. И тогда системный конфликт не превращается в личный. #ОперационнаяМодель #ProductManagement #Управление #БизнесЮнит #ОрганизационныйДизайн
· 23.08
В поддержке пользователей у этого стола (конфликта) есть ещё один участник, которого не зовут на совещание, - пользователь. Он не спорит о приоритетах и не знает про P&L, но именно он (и его вертикаль) оплачивает отсутствие владельца временем своей остановившейся работы. И тогда фраза про то, что системный конфликт не превращается в личный, звучит совсем буквально: без владельца он становится личным - для пользователя.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён