Все статьи
От ясности к неопределенности: тернистый переход к роли менеджера по продукту
Дата: 31.07.2024
Продукт можно запустить и в проектном, и в продуктовом подходе. Получается, если сотрудник участвовал в запуске проектов, он может легко освоить и продуктовый подход. Тогда почему так много разочарований при переводе проектных команд на продуктовые рельсы? В этой статье поговорим о том, может ли проектный менеджер перейти в новую роль и быть успешным, в чем основная разница между ролями продакта и проджекта и можно ли из проектников собрать продуктовую команду.
Появление концепции Agile принесло с собой новые роли, одна из них – product manager. Позиция продуктового лидера стала настолько популярной, что на нее засматриваются и проектные менеджеры, размещая свои резюме на продуктовые позиции, вакансия product owner воспринимается ими как модификация привычной им роли проектного лидера.
Примерно такой же подход можно наблюдать и при создании продуктовых подразделений в рамках Agile трансформации или реорганизации продуктовой службы: берем проектного менеджера, отправляем его пройти базовый курс, ставим новоиспеченного «продакта» на позицию и через полгода начинаем жаловаться в стиле «не так уж и хорош ваш продуктовый подход».
Предлагаю сегодня поразмышлять о том, в чем разница между проектным и продуктовым менеджером, почему так сложен бывает переход между этими ролями и возможно ли сделать продуктовую карьеру сильному специалисту из проектного офиса.
При внешней однозначности продакт как роль – одна из самых сложных, противоречивых и непонятных. Причин здесь несколько:
- Это молодая роль, а следовательно – мало накоплено опыта, совсем немного литературы, пока не сложилось системы массовых образовательных программ, нет стандартизации. В результате под этой ролью понимают все, чем может быть наполнен стереотип продуктового лидера или изобретателя.
- Роль работает в разных фреймворках и в зависимости от подхода наполняется по-разному. В результате появляется путаница с терминологией и требованиями к квалификации. Роль product owner очень разная в Scrum и SAFe (в первом случае – это стереотипный “мини CEO”, во втором – операционный сотрудник ближе к бизнес-аналитику).
- Путаница на уровне привычных моделей мышления: многие компании до сих пор так и не увидели разницы между спецификой ролей проектного и продуктового менеджеров, названия остались синонимами постановщика задач в команды (забавно, но у них даже сокращение одинаковое – PM). Поэтому зачастую при переходе на гибкие методологии проджекты – основные кандидаты на роль владельца продукта команды. В результате – вакансия заполнена, а продуктовой работы по факту нет.
- Продуктовый подход требует переформатировать привычные подходы к оценке бизнеса и тактике ведения разработки: прослушать курс product owner – полдела, важнее организовать практику после обучения, обеспечить качественный менторинг на первом этапе (чего чаще всего не делают).
Моя позиция в этом вопросе заключается в том, что качественное различие между ролями проектного и продуктового подходов проходит на всех уровнях функционирования бизнеса:
- Бизнес-контекст.
- Система.
- Бизнес-процесс.
- Организационная роль.
- Характеристики личности.
Давайте по порядку…
БИЗНЕС-КОНТЕКСТ
Основной концепт гибкой организации строится вокруг отказа от детерменизма: мир становится настолько сложным и непредсказуемым, что привычка нашего мозга везде строить причинно-следственные связи приводит к серьезным ошибкам и искажениям.
Современная гибкая организация базируется на сложности и нелинейности, отсюда и продуктовый подход, и организация коротких циклов управления. В современном Agile чаще всего прибегают к объяснению через модель Стейси и Кеневин матрицу. Мне больше нравится вторая.
Еще в 1999 г. директор Института управления знаниями на базе IBM Дейв Сноуден предложил инструмент помощи менеджерам для принятия качественных управленческих решений: «Разные проблемные ситуации требуют разных подходов к поиску правильного решения» – в статье «A Leader’s Framework for Decision Making».
Разработка кода и создание нового продукта – работа в сложных системах. И здесь для нас важны 2 домена: сложный и комплексный. На уровне сложного домена у нас больше определенности. Самая главная – мы знаем, куда мы хотим прийти. Значит, у нас есть образ нужного результата. Здесь хорошо помогает опыт и профессионализм. Ключевая задача – провести команду наиболее коротким путем к достижению цели. Именно в этом домение лежит область применения проектного подхода. То есть задача: «что сделать?» – уже прояснена, и мы фокусируемся на вопросе: «как делать?».
Комплексный домен – сложнее и запутаннее, находясь в нем, мы не понимаем, какой точно результат можно считать хорошим и что точно надо сделать, чтобы его создать. Поэтому мы двигаемся короткими HADI циклами, постоянно выдвигая и отсеивая гипотезы. Комплексный домен – зона действия продуктового подхода.
СИСТЕМА
Для того чтобы начать сравнение, предлагаю посмотреть на модель поставки продукта на рынок.
Если мы посмотрим критически на задачу создания продукта, то при недолгом размышлении придем к тому, что разработка продукта может быть реализована и по проектному, и по продуктовому подходу. Вместо HADI циклов мы можем разместить небольшие проекты и двигаться итеративно в направлении реализации. Так часто и происходит в компаниях с ранней гибкой культурой, когда общую форму продуктового процесса команда принимает, но содержание наполняет привычными моделями поведения. Получается продуктовый бэклог на год, согласованный и утвержденный руководством.
Истинный продуктовый подход – другой, мы не планируем долгосрочные результаты, пока в ходе водоворотов циклов проверки гипотез не подойдем к пониманию, что нужно клиенту. В продуктовом подходе основная цель – сделать продукт с максимальной клиентской ценностью.
БИЗНЕС-ПРОЦЕССЫ
Бизнес-процесс в проектном подходе разворачивается линейно и последовательно. Ключевая задача проектного менеджера – сдать проект в рамках 3 координат: скоуп задач, дата передачи заказчику, бюджет. Проект конечен и каждый раз собирается заново по индивидуальному подходу. Ошибка в проектном подходе – сродни преступлению, ведь она приводит к увеличению бюджета или срока.
Продуктовый подход построен на процессе непрерывной поставки. При оценке процессов в продуктовой разработке интересует: скорость поставки от идеи до выпуска (time to market), PMF (соответствие продукта потребности клиента), пропускная способность потока. Процесс создания продукта – динамичная история, продакт знает, что ничего не знает, поэтому должен быть готов быстро откидывать плохие идеи. Ошибка в продуктовом подходе – норма, приветствуется сокращать стоимость ошибок.
ОРГАНИЗАЦИОННАЯ РОЛЬ
Основная задача проектного менеджера в ИТ – организовать процесс взаимодействия людей так, чтобы они сделали работу в срок с заданным качеством. Проджект делает из хаоса структуру: общается с бизнес-заказчиком, определяет артефакт на выходе, его метрики, определяет необходимые затраты, составляет план и контролирует выполнение вплоть до сдачи проекта заказчику. В рамках структуры процесса разработки, проджект фокусируется на Delivery этапе.
Ключевые навыки проджекта в ИТ: планирование, декомпозиция задач, методы приоритезации, постановка задач, управление потоком поставки, фасилитация встреч, медиация, ведение переговоров, презентация.
Основная задача продакт менеджера – создание продукта, который будет востребован на рынке. Для этого необходимо обеспечить сбор информации и обратной связи, генерацию идей с максимально быстрой валидацией, разработку стратегии вывода продукта на рынок, создание доходной бизнес-модели. На основании этого владелец продукта отбирает задачи для беклога и передает их в команду. В этой части задачи обеих ролей совпадают с той разницей, что продакт не контролирует команду, он занимается приемкой и постановкой, остальные функции передаются самой команде и частично скрам-мастеру.
Фокус работы на Discovery процесс в продуктовом подходе требует других навыков: разработка видения и стратегии, формирование бизнес кейса, генерация и валидация гипотез, проведение исследований, управление метриками, постановка и декомпозиция задач, приоритезация, методы решения проблем, дизайн-мышление. На продвинутых уровнях еще добавляются навыки управления коммуникациями и продажами.
ЛИЧНЫЕ ХАРАКТЕРИСТИКИ
Проджект менеджер – это дирижер технологического оркестра разработки. Без сомнения, это лидерская позиция с большим количеством задач на мониторинг и постоянным контролем за результативностью, много приходится проводить переговоров, решать конфликтов.
Ключевые характеристики личности кандидата на позицию проджекта: целеустремленность, конкретность, логика, критическое мышление, дисциплина, требовательность, лидерство, сильные переговорные навыки.
Продакт – создатель нового, работает в условиях сильной неопределенности. На этой позиции хорошо проявляют себя творческие люди, у которых бесконечная неопределенность не рождает повышенной тревоги.
«Мягкие» навыки – креативность, творчество, умение выходить за пределы системы, умение отказаться от старых идей, любопытство, визионерство и стратегичность мышления, умение находиться в неопределенности.
ЗАКЛЮЧЕНИЕ
Проектный и продуктовый подход решают задачи разного класса, соответственно, ключевые роли (product manager и project manager) этих процессов тоже разные.
Проджект делает «делает вещи правильно», поэтому хороший проектник – четкий и структурный сотрудник. Его задача избавить бизнес-заказчика от неопределенности, предложив и реализовав конкретный во времени и в ресурсах способ получения результата.
Владелец продукта «делает правильные вещи» (ну или мечтает об этом), поэтому на этих позициях хорошо себя проявляют люди с хорошей фантазией, эмпатией, любопытством. Отсутствие образа продукта не повергает их в ужас, они терпеливо идут проверять самые невероятные гипотезы, постоянно расставаясь со старыми убеждениями. Перфекционизм – крайне вредная привычка в продуктовой разработке, она останавливает всякое движение мысли до «дня, когда мы сделаем на 100% (то есть никогда)».
Для принятия решения, подходит ли вам продуктовый стиль управления, нужно обратить внимание, что в agile среде (именно здесь развивается product management) сейчас сформировался другой подход к лидерству. Владелец продукта – не командир команды разработки, а скорее – идейный вдохновитель. Поэтому людям с авторитарным стилем управления точно не сюда.
По моим наблюдениям, «начальникам», «самым умным ребятам в команде», «контролерам всего и вся» и перфекционистам всех рангов продуктовый подход дается крайне тяжело, прежде всего, потому что здесь все совершают ошибки на каждом шагу, и ошибаться в продуктовом подходе – не стыдно.
Может ли менеджер проекта стать хорошим владельцем продукта. Вполне, особенно если:
- Проджект переходит на позицию продакта во внутренние продукты, где подходы проектного и продуктового офисов достаточно близки.
- Менеджер проекта идет на продукт в фазе зрелого продукта, когда задачи поддержки заданного качества и оптимизации затрат на разработку важнее прорывных идей.
- Переход из проекта в продукт происходит в технологичных продуктах в В2В (на рынках с умеренной конкуренцией).
В этих случаях потребуется базовое, а далее и точечное обучение технологиям, желательно подобрать ментора и настроиться на несколько лет практики, прежде чем вы сможете назвать себя product manager.
Есть много других случаев, где переход из проектного офиса в продуктовый благоприятен, главное, пробовать себя в разных ролях, помня о концептуальной разнице подходов и методов принятия решения. Для этого нужно переучиваться, и это займет время.
Познакомиться с основами продуктового подхода и пройти самодиагностику можно на моем бесплатном вебинаре «Введение в продуктовый подход».
Освоить базовые продуктовые инструменты можно на практическом курсе «Владелец продукта».
Автор статьи: Марина Иванченко — agile-коуч, партнер компании «Лидеры изменений», эксперт по внедрению продуктового подхода. Опыт работы топ-менеджером в крупных российских телеком-проектах более 15 лет. Степень MBA по направлению «стратегическое управление», магистр психологии в области психоанализа и бизнес-психологии.
