Продуктовый или проектный подход – как правильно?

Мне очень нравится фраза одного статистика: «В сущности, все модели неправильны, но некоторые полезны»

Примерно лет 10-15 тому назад многие жали за процессное управление – разобрались, что не везде работает; переключились на проектное, сейчас разбираемся, что и оно не везде работает.

Любой подход имеет ограничения определённое контекстом применения. Стрёмно видеть, когда доказательства применимости подхода ссылается на сам подход, а не на контекст его применения — доказательство догмата через догмат – религиозный фанатизм.

Приходится часто сталкиваться с подобным догматизмом от проектного управления.

Метрики, используемые в проектном управлении, направлены на контроль достижения цели в определённых проектных ограничениях, а не на контроль соответствия поставляемого продукта решению задач, под который он создаётся. Интересным образом эта проблема была сформулирована в «Чёрном законе метрик».

Метрики в продуктовом менеджменте направлены на проверку того, что действительно ли, создаваемый продукт соответствует решению проблемы потребителя. Эта проверка между проблемой и решением иногда называют «соответствием продукта рынку» (product market fit). Об одном из подходов к продуктовому управлению, где используется product market fit писал тут.

Странно выглядела бы идея строить многоэтажный дом, сдавая каждый этаж отдельно, регулярно внося конструктивные изменения на основании обратной связи от будущих жильцов. И также странно выглядит идея запустить продукт, ориентированный на открытый рынок, стремясь соблюсти проектный подход.

Дальше по мотивом статьи

Представите, глобальную страховую компанию, которая хочет разработать новый продукт для страхования домашних животных.

Руководитель продукта пытается продемонстрировать совету директоров цифровые инновации, ожидая, что проект будет укомплектован человеческими ресурсами с самого начала, а разработчики, технические специалисты, которые в настоящее время работают над различными другими проектами, также будут задействованы в этом проекте.

Следуя традиционному принципу проектного управления, техническое руководство составляет его план и заранее определяет бюджет и необходимые человеческие ресурсы. Ежемесячно контролирует, идёт ли работа по плану и в рамках бюджета.

Затем, после запуска год спустя, приложение явно не привлекает значительного числа новых клиентов – и по факту хуже аналогичного решения, выпущенного маленьким стартапом в области страховых технологий шестью месяцами ранее.

Что пошло не так?

Традиционные принципы управления ИТ-проектами долгое время обеспечивали успех в бизнесе и помогали предприятиям реализовывать крупнейшие и наиболее важные инициативы на протяжении многих лет. Управление проектами даёт руководителям возможность собрать необходимые ресурсы и бюджеты, составить подробный план, зафиксировать выполненные задачи, похвалить себя и свою команду, когда проект завершается вовремя и в рамках бюджета. В таком случае это не удивительно, что компании составляли масштабные планы проектов по управлению и трансформации своих процессов. На мой взгляд, здесь происходит глубокая проблема на уровни психологи управления – «Куда смотрим, туда и приедем», менеджер проекта концентрируется исключительно на метриках, описывающих ограничения, и не обращает внимания на момент ценности эксплуатации продукта проекта.

И поэтому традиционные подходы в управлении проектами обычно недостаточно для обеспечения сегодняшних потребностей в поставке программных продуктов, к примеру. Неподходящая управленческая модель и метод измерения могут пустить под откос даже стратегические проекты, которые отлично обеспечены ресурсами – Отслеживание действий и бюджетов даёт ощущение безопасности, которое может проявиться только тогда, когда программный продукт выйдет на рынок. Хуже того, предварительно принятые риски и расходы могут задержать команду в получении обратной связи по мере реализации проекта.

Мишель Шаттлворт управляющий директор в Deloitte Consulting LLP’s Delivery Innovation group – «Многие команды встроили в свою ДНК определённые способы работы, часто измеряя действия: проведение встреч, выполнение задач, создание поставок. Вместо того чтобы уделять должное внимание результатам. Управление продуктам меняет окно, через которое команда смотрит на свою работу. Пришло время изменить образ мышления и принять модели поведения и показатели, определяющие успех на основе результатов, которые часто определяют конечные пользователи продукта».

Многие организации осознают преимущества перехода к методологии управления продуктами для изменения стратегии разработки программного обеспечения. Управление продуктами побуждает организации измерять успех на основании ценности, которую их продукт приносит потребителям, а не на основе этапов, достигнутых в процессе создания реализации проекта. Подходы, которые включают в себя зонтик Agile, реагируют на обратную связь пользователей, на изменения рыночных условий. Поддерживают гибкость и промежуточные корректировки, вместо жёсткой привязки бюджетного и ресурсного плана к базовому плану проекта.

В приведённым выше примере страховой стартап, использующий продуктовый подход, вероятно, начал не с создания монолитного плана проекта, а с определения желаемых бизнес-результатов, таких как: увеличение числа пользователей приложения, определение целевых конверсий в платящего клиента. Руководители собрали кросс-функциональную команду разработчиков программного обеспечения, полностью посвятившую себя разработке продукта, запланировали более частые проверки прогресса, а также корректировали курс по ходу работы – и всё это за меньшую часть затрат чем у крупной организации.

Согласно Керстену, основные различия между ИТ-проектами и управлением продуктами заключается в следующем:

Управление проектам обычно распределяет финансирование в соответствии с этапами, зафиксированными во время определения объёма проекта (где-то в процессах: Планирование управление стоимостью, Оценка стоимости, Определение бюджета), а новый бюджет требует фактически создание нового плана проекта.

Управление продуктом основывается на бизнес-результатах с выделением новых денег по мере необходимости и на достижение дополнительных результатов.

Проекты обычно измеряются способностью выпустить поставку в срок и в рамках проектных ограничений, поэтому бизнес-заказчики вводят заранее свои требования, что обычно приводит к укрупнению проекта и увеличение его бюджета.

Продуктовый подход ориентирован на способность команды создать дополнительную ценность и достигнуть бизнес-целей, таких как создание программного продукта, приносящего ожидаемую прибыль.

В проектном подходе риск поставки продукта плохо соответствующему рынку наиболее вероятен, потому что спецификация продукта и стратегические решения формируются на старте (фиксируется базовым планом, а дальше отслеживаются метрики, как правила отклонения от базового плана. см "чёрный закон метрик").

В продуктовом подходе риск распределяется на более длительный период и на несколько итераций, создавая возможность внести изменения в спецификацию продукта, если первоначальные предположения (о свойствах продукта) окажутся неверными или возникнут стратегические возможности.

Проектный подход распределяет ресурсы на раннем этапе, и люди часто работают над несколькими проектами одновременно с частым оттоком и переназначениями.

Продуктовый подход предполагает назначение кросс-функциональной команды на один продукт, это позволяет достичь большей стабильности и даёт возможность постепенно корректировать штатное расписание.

Проектный подход ориентирован на поставку по заранее согласованным требованиям (реализация плана).

Продуктовый подход основывается на дорожной карте, проверки гипотез с упором на функциональность ценность для бизнеса (реализация ценности).

Офис управления проектами навсегда может точно определить сложность решения с точки зрения бизнеса (нехватка бизнес-компетенций). В этом случае прогресс проекта становится чёрным ящиком уже для бизнеса (нехватка компетенций в ИТ).

Продуктовый подход помогает руководителям сопоставить выполненную работу с бизнес-результатом, что обеспечивает большую прозрачность (за счёт быстрых поставок работающих модулей и получения обратной связи от бизнеса).График

В проектном подходе есть зафиксированная дата окончания проекта. Уделяется мало внимания работоспособности продукта после завершения проекта.

Продуктовый подход делает упор на многолетний жизненный цикл продукта, включая текущее обслуживание и работу по улучшению. Т.е. эксплуатацию продукта, что полностью исключено в проектном подходе.

В сущности, все модели неправильны, но некоторые полезны. Выбирая подход, нужно учитывать контекст применения. Если контекст таков, что нужно отдать итог работы в строгом соответствии с документацией – проектный подход. Если итог работы ориентирован на открытый рынок – продуктовый подход. Выбор подхода, который позволяет вам приобрести больше, чем потерять, – есть вектор антихрупкости :)

Отслеживание действий, бюджетов, сроков даёт ощущение безопасности. Реагирование на обратную связь пользователей и на изменения в рыночных условиях даёт управляемость.

Керстен рекомендует предприятиям использовать более быстрые циклы обратной связи и структурировать свои подразделения в потоки создания ценности продуктов. «Поток создания ценности — это непрерывный поток информации, необходимый для предоставления ценности клиенту, и чем больше ценности передаётся клиенту, тем успешнее организация», — Керстен отмечая это, рекомендует направлять сотрудников только к одному потоку создания ценности зараз.

Организации могут измерить элементы потока на уровне бизнеса и соответствующим образом оптимизировать», — говорит Керстен. «Используя этот подход, команды могут перейти от мира, в котором в предварительном плане проекта всё указано, к бюджету разработки продукта, который позволяет перераспределять между потоками создания ценности и адаптироваться к тому, где лидеры видят бизнес-результаты».

Закончить хочу словами соотечественника. Андрей Губанов, «Спасибо от Сбербанка», Начальник отдела целевого маркетинга — «Мы не делаем готовый продукт, мы делаем управляемый продукт»