Эпоха Agile-трансформаций: Мелисса Перри о мифах и реальности работы с продуктом 0:00
В индустрии разработки программного обеспечения роль «владельца продукта» (Product Owner) стала одной из самых быстрорастущих, однако зачастую она сильно оторвана от классического понимания управления продуктом. В своем глубоком анализе для Lenny's Podcast эксперт Мелисса Перри (Melissa Perri) и ведущий Ленни (Lenny) разбирают, почему внедрение жестких фреймворков вроде SAFe часто становится «заплаткой» на пути к реальным инновациям. В этом материале — разбор истории Agile, ловушек сертификаций и того, как компаниям на самом деле выстраивать стратегию создания ценных продуктов.
🧬 История возникновения ролей в Agile 11:05
По мнению Мелиссы Перри, корни недопонимания ролей кроются в самом происхождении Agile. Манифест Agile 2001 года был написан исключительно разработчиками программного обеспечения, а не менеджерами по продукту. В центре внимания было создание процесса, который поможет разработчикам быстрее доставлять ценность и избегать рисков «водопадной» модели.
- Scrum и Product Owner: Роль «владельца продукта» возникла в Scrum как способ приоритизации бэклога для разработчиков. В первых версиях руководства Scrum (Scrum Guide) допускалось, что PO может быть заказчиком из бизнес-подразделения.
- Искажение смыслов: Со временем акцент сместился с создания продукта на процесс управления бэклогом. Мелисса Перри отмечает, что современные курсы для PO обучают проведению стендапов и приоритизации, но игнорируют ключевые навыки менеджера: исследования рынка, эксперименты и работу с данными.
📉 Ловушка Scaled Agile Framework (SAFe) 26:33
SAFe стал популярен среди руководителей крупных корпораций, так как предложил готовый «чертеж» для масштабирования Scrum на тысячи сотрудников. Однако гостья считает, что этот подход часто превращает владельцев продукта в «собирателей требований».
- Почему это не работает: Вместо того чтобы заниматься стратегией и общением с клиентами, PO в структурах SAFe тратят всё время на написание пользовательских историй для обеспечения полной загрузки разработчиков.
- Критика «Agile-индустрии»: Мелисса Перри утверждает, что популярность SAFe поддерживается консультационными гигантами (например, McKinsey), которые продают сертификации. По словам эксперта, каждый человек, добившийся успеха после внедрения SAFe, в итоге «разорвал» этот фреймворк и превратил его во что-то другое.
🏗️ Как трансформировать организацию правильно 41:41
Для компаний, которые не являются «технологически нативными» (банки, страховые, телеком), путь к инновациям требует пересмотра операционной модели, а не просто копирования процессов Google или Amazon.
- Создание стратегии: Компании должны начинать с формирования стратегии продукта, а не с выбора методологии.
- Карьерные лестницы: Одной из главных ошибок Мелисса называет разделение карьерных путей PO и PM. Она рекомендует отказаться от этих разных ролей, переименовав всех в менеджеров по продукту, а тех, кому не хватает опыта в исследованиях, называть Associate Product Manager.
- Интерполяция опыта: Наиболее успешные трансформации происходят там, где руководство нанимает опытных директоров и менеджеров с рынка, которые уже видели, как работают сильные команды.
🚀 Советы для профессионалов: как не «застрять» 57:19
Для специалистов, работающих в крупных корпорациях с жесткими процессами, эксперт дает следующие рекомендации:
- Смена фокуса: В своем резюме и в работе смещайте акцент с «я приоритизировал бэклог» на «я решил бизнес-задачу, что сэкономило X долларов / увеличило Y метрику».
- Проактивность: Если вы PO, начните задавать лидерам вопросы: «Какую цель мы преследуем этим релизом?», «Какие метрики мы ожидаем изменить?».
- Критическое отношение к сертификатам: Мелисса подчеркивает, что сертификация (CSPO и др.) — это часто результат двухдневного курса, который не делает человека готовым менеджером. Опыт важнее бумаг.
По мнению Мелиссы Перри, ключ к успеху лежит в принципе inspect and adapt (исследуй и адаптируй): если процесс не служит интересам бизнеса и не помогает делать клиентов счастливее, его необходимо менять, даже если кто-то называет его «неправильным» применением Agile.
