Познакомьтесь с руководством AI Product Operations от PAF
Настроить Cookies
Настроики Cookies
Файлы cookie, необходимые для корректной работы сайта, всегда включены. Другие файлы cookie можно настроить.
Руководство
Product Architecture Framework
AI Product Operations
Определение
Product Architecture Framework (сокращенно PAF) - методология проектирования системы управления продуктами в эпоху ИИ, которая помогает отдельным командам и большим корпорациям выстроить масштабируемые и прозрачные процессы и организационную структуру для повышения скорости и качества роста монетизируемой ценности за счет создания стратегического фундамента и адаптации к текущим изменениям рынка.
PAF решает две ключевых задачи современного управления продуктами: правильное мышление и искусственный интеллект.
Во-первых, это ответ на возникающий c-level вопрос о том, почему продуктовый подход НЕ даёт бизнес-результата. PAF отвечает на этот вопрос за счёт определения объектов мышления, которые рассматривают процесс управления продуктами НЕ как процесс продуктовой разработки. Как правило, проблема низких бизнес-результатов связана с тем, что компаниям "продали" методологии продуктовой разработки (например, scrum и производные) как панацею для решения их бизнес-проблем. Это очень хорошие методологии, которые действительно работают и помогают оптимизировать процессы разработки. Однако, процесс разработки - это не процесс развития продукта. Как наследник тойотовской системы управления, scrum или kanban оптимизируют потери процесса производства и для этого были созданы концепции беклога, спринтов, приоритизации и синронизирующих ритуалов. Процесс развития продукта отвечает на другой вопрос: не как что-то делать быстрее, а как создать продукт таким, чтобы был выше возврат монетизируемой ценности на инвестиции (ключевой параметр - NPV). Для этого необходимы другие объекты мышления и другие процессы.
Во-вторых, это ответ на вопрос, каким должно быть управление продуктами в эпоху искуственного интеллекта, когда оказалось, что практически все задачи менеджеров могут быть ИИзированы. ИИ оказался той disruptive технологией, которая возникает раз в сто лет, потому что кардинальным образом меняет то, как человечество выполняет свои задачи. Я не буду дублировать здесь аспекты этого влияния - они собраны в отдельной статье. Вопрос возникает в связи с тем, что одни задачи (например, discovery) теперь могут быть решены фактически мгновенно и достаточно качественно, больше даже не нужно планировать работу над ними, а другие задачи могут быть полностью делегированы ИИ. Мы сталкиваемся с кризисом роли менеджера продукта, когда необходимо понять, какова же тогда остаётся его функция, как меняется сама команда и процессы работы с учётом фактора ИИ. PAF отвечает на этот вопрос, включив в себя новые объекты мышления (например, такие как Нексус или Кортекс) и переосмысляя предыдущие (например, понятие беклога).
PAF решает две ключевых задачи современного управления продуктами: правильное мышление и искусственный интеллект.
Во-первых, это ответ на возникающий c-level вопрос о том, почему продуктовый подход НЕ даёт бизнес-результата. PAF отвечает на этот вопрос за счёт определения объектов мышления, которые рассматривают процесс управления продуктами НЕ как процесс продуктовой разработки. Как правило, проблема низких бизнес-результатов связана с тем, что компаниям "продали" методологии продуктовой разработки (например, scrum и производные) как панацею для решения их бизнес-проблем. Это очень хорошие методологии, которые действительно работают и помогают оптимизировать процессы разработки. Однако, процесс разработки - это не процесс развития продукта. Как наследник тойотовской системы управления, scrum или kanban оптимизируют потери процесса производства и для этого были созданы концепции беклога, спринтов, приоритизации и синронизирующих ритуалов. Процесс развития продукта отвечает на другой вопрос: не как что-то делать быстрее, а как создать продукт таким, чтобы был выше возврат монетизируемой ценности на инвестиции (ключевой параметр - NPV). Для этого необходимы другие объекты мышления и другие процессы.
Во-вторых, это ответ на вопрос, каким должно быть управление продуктами в эпоху искуственного интеллекта, когда оказалось, что практически все задачи менеджеров могут быть ИИзированы. ИИ оказался той disruptive технологией, которая возникает раз в сто лет, потому что кардинальным образом меняет то, как человечество выполняет свои задачи. Я не буду дублировать здесь аспекты этого влияния - они собраны в отдельной статье. Вопрос возникает в связи с тем, что одни задачи (например, discovery) теперь могут быть решены фактически мгновенно и достаточно качественно, больше даже не нужно планировать работу над ними, а другие задачи могут быть полностью делегированы ИИ. Мы сталкиваемся с кризисом роли менеджера продукта, когда необходимо понять, какова же тогда остаётся его функция, как меняется сама команда и процессы работы с учётом фактора ИИ. PAF отвечает на этот вопрос, включив в себя новые объекты мышления (например, такие как Нексус или Кортекс) и переосмысляя предыдущие (например, понятие беклога).
Общий каркас
PAF определяет условия среды, в которой продуктовые команды осознанно и целенаправленно способны достигать бизнес-целей компании за счет развития продуктов. Элементы этой среды включают:
Общая концепция управления PAF выглядит так:
Product Architecture Framework является насколько это возможно непротиворечивым и полностью описывающим управление продуктом и его связку с бизнесом. Это реализовано за счет теории объектов управления, которая определяет единую парадигму мышления для всех участников процессов: начиная с уровня команды и заканчивая стратегическим планированием. PAF основан на других методологиях: Customer Development, Scrum, концепция жизненных циклов (рынка, продукта, организации, команды), stage-gate процессах и т.д. PAF не противопоставляется методологиям продуктовой разработки, будь то Scrum, Kanban, SAFe, LeSS и процессно сочетается с ними.
Ключевой миссией PAF является создать язык для проектирования системы управления продуктами, найти лакуны в текущих методологиях и свести к общим понятиям сущности, которые в разных методологиях назывались по-разному, но представляли собой одни и те же объекты управления.
- Определение Портфеля Бизнес-Юнитов (англ. Business Unit Portfolio). Каждый бизнес-юнит является связкой конкретного рынка, продукта и бизнес-модели. Бизнес-юнит - это минимальная стратегическая единица бизнеса, которая генерируют прибыль через монетизацию ценности продуктом. Далее вместо бизнес-юнита для упрощения будет использоваться слово "продукт".
- Формирование Нексусов (англ. Nexus) - информационных моделей продукта, бизнеса и рынка, которые включают необходимый и достаточный контекст для принятия решений.
- Выстраивание Кортекса (англ. Cortex) - операционной системы управления Нексусами с помощью ИИ.
- Роль Инженера Продукта (сокр. продакт) (англ. Product Engineer), заменяющего менеджера продукта (англ. Product Manager), который управляет развитием продукта через Кортекс посредством контекста, собранном в Нексусе.
- Роль Менеджера Продуктовых Процессов (сокр. пропс) (англ. Product Ops), который помогает инженерам продуктов построить структуру Нексусов и настроить процессы Кортекса.
Общая концепция управления PAF выглядит так:
- Инженеры продуктов формируют Образ Продукта, или Видение (англ. Vision), который необходим рынку и компании. Образ продукта состоит из Свойств Продукта, или Фич (англ. Feature). Разрыв между текущим продуктом и Видением, называется Разрывом, или Гэпом (англ. gap).
- Функцией инженера продукта является сократить Гэп, определив какие Фичи нужно добавить, изменить или убрать из продукта, чтобы достичь целей бизнеса. Такой набор фич называется Банчем (англ. Feature Bunch) и определяется только текущим состоянием продукта, определенным Нексусом. Поэтому в PAF нет Беклога продукта (англ. Product Backlog) как перечня задач для разработки разной степени давности и актуальности.
- Банч состоит из идей, в которых Команда продукта (англ. Product Pod) уверена в разной степени, поэтому ключевой задачей Инженера продукта является повышение Оценки Уверенности команды (англ. Confidence Point) в фичах банча. Инженер продукта реализует это через увеличение контекста в Нексусах, фокусируясь не на самой идее фичи, а на общем знании.
- Команда продукта работает над добавлением Банча. PAF не является процессом разработки продукта (англ. Product Development) и не определяет его, поэтому на уровне команд для решения этой задачи может быть выбран любой: scrum, kanban, scrumban и т.д.
- Инженер продукта управляет не потоком задач в разработку, а Нексусами продукта, бизнеса и рынка, определяя как долгосрочные планы их развития, так и краткосрочные в виде Банча изменений. Для переключения между этими уровнями Инженер продукта использует Концепцию Трёх Линз (англ. Three Process Lenses, или сокращ. Концепция 3PL). Каждая линза определяет набор связанных процессов, которые помогают продуктовой команде достигать целей бизнеса.
- После релиза фичи на рынок, Инженер продукта с помощью Кортекса получает новую информацию и обновляет контекст Нексусов продукта, бизнеса и рынка. На основании новых знаний меняется Банч. Цикл повторяется.
Product Architecture Framework является насколько это возможно непротиворечивым и полностью описывающим управление продуктом и его связку с бизнесом. Это реализовано за счет теории объектов управления, которая определяет единую парадигму мышления для всех участников процессов: начиная с уровня команды и заканчивая стратегическим планированием. PAF основан на других методологиях: Customer Development, Scrum, концепция жизненных циклов (рынка, продукта, организации, команды), stage-gate процессах и т.д. PAF не противопоставляется методологиям продуктовой разработки, будь то Scrum, Kanban, SAFe, LeSS и процессно сочетается с ними.
Ключевой миссией PAF является создать язык для проектирования системы управления продуктами, найти лакуны в текущих методологиях и свести к общим понятиям сущности, которые в разных методологиях назывались по-разному, но представляли собой одни и те же объекты управления.
Принципы PAF
1. Прозрачность до очевидности
Менеджер — это функция, управляющая какими-то объектами. Единственный способ управления — это получение и передача информации. С этой точки зрения функция самого менеджера — это сокращение времени на обмен квантами информации. Соответственно, чтобы повышалось доверие к решениям менеджера необходимо повышать прозрачность информации в системе: полноту и непротиворечивость информации + доступ к этой информации от разных заинтересованных сторон. Фактически, уровень доверия влияет на качество менеджмента во всей компании (особенно, если вспомнить работы Янна Алгана и Пьера Каю про влияние уровня доверия на экономический рост).
Принцип прозрачности предполагает, что у всех заинтересованных сторон решений настолько хватает общего контекста информации, что принятие следующего решения становится очевидным. Этот принцип реализуется в PAF за счет формирования Нексусов и отсутствия Беклога продукта, идеи в котором непонятно откуда сформированы.
Принцип прозрачности предполагает, что у всех заинтересованных сторон решений настолько хватает общего контекста информации, что принятие следующего решения становится очевидным. Этот принцип реализуется в PAF за счет формирования Нексусов и отсутствия Беклога продукта, идеи в котором непонятно откуда сформированы.
2. Совместная унификация контекста
Формализация контекста важнее повторяющейся коммуникации, при которой этот контекст теряется. Если спросить десять разных человек внутри компании в чем заключается ценность продукта и каковы их сегменты потребителей, то можно услышать десять разных мнений. Потому что, во-первых, информация об этих и многих других вещах хранится только в голове каждого человека и больше нигде. А, во-вторых, само это представление отличается. Поэтому маркетологи не понимают менеджеров продуктов, а те не понимают команду разработки. Соответственно, решения которые они принимают, тоже будут отличаться, хотя в реальности все они оперируют с одним и тем же продуктом и одними и теми же потребителями.
Принцип совместной унификации предполагает, что все заинтересованные лица постепенно создают единое хранилище знаний об объекте управления - Нексус, в котором собрано представление компании об продукте, рынке или бизнесе. Они работают с уницированным Нексусом, а не набором разрозненных документов, созданных в разное время, которые читают в лучшем случае один раз и потом забывают.
PAF определяет, что именно контекст является новым способом конкуренции между компаниями. Выиграет тот, у кого лучше контекст и кто сможет им более эффективно управлять.
Принцип совместной унификации предполагает, что все заинтересованные лица постепенно создают единое хранилище знаний об объекте управления - Нексус, в котором собрано представление компании об продукте, рынке или бизнесе. Они работают с уницированным Нексусом, а не набором разрозненных документов, созданных в разное время, которые читают в лучшем случае один раз и потом забывают.
PAF определяет, что именно контекст является новым способом конкуренции между компаниями. Выиграет тот, у кого лучше контекст и кто сможет им более эффективно управлять.
3. Гибкая стабильность
Принцип реализует управленческую концепцию Stagility (от stability + agility), которая сочетает стабильность долгосрочного цели, но возможность гибкого изменения пути её достижения в зависимости от условий текущей рыночной среды. Это позволяет организации быстро адаптироваться к изменениям, не теряя управляемости и устойчивости.
Принцип гибкой стабильности реализуется в PAF за счет формирования долгосрочной стратегии, которая определяет будущее состояние бизнес-юнита, но не способ достижения этого состояния, который может меняться. Управление гэпом между долгосрочным и краткосрочным осуществляется за счет управления рисками.
Принцип гибкой стабильности реализуется в PAF за счет формирования долгосрочной стратегии, которая определяет будущее состояние бизнес-юнита, но не способ достижения этого состояния, который может меняться. Управление гэпом между долгосрочным и краткосрочным осуществляется за счет управления рисками.
4. Управление рисками равно управление знаниями
Все гибкие методологии разработки стремятся оптимизировать потери, которые возникают на разных этапах производственной цепочки продукта. Согласно PAF, управление продуктом - это НЕ производство, это скорее взращивание или возделывание. Нет какой-либо одного пути или процесса роста, успешно вырасти может одна или другая ветка продукта. Это определяется внешней средой, а не внутренними процессами. Поэтому вместо потерь используется оптимизация рисков (уровня неопределенности или информационной энтропии по Шеннону). Потери - это прошлое, а риски - это потенциальное будущее.
Ключевой задачей инженера продукта является сокращение рисков за счет насыщения нексусов необходимой информацией. PAF реализует этот принцип за счёт изменения оценки уверенности (confidence point), что приводит к изменению фич банча.
Ключевой задачей инженера продукта является сокращение рисков за счет насыщения нексусов необходимой информацией. PAF реализует этот принцип за счёт изменения оценки уверенности (confidence point), что приводит к изменению фич банча.
5. Скаутинг вместо приоритизации
Процессы разработки продукта крутятся вокруг концепции списка задач, которые по некоторому алгоритму выбираются и передаются в разработку. Сам процесс формирования этого списка не определен - вместо него есть концепция заинтересованных лиц, которые его определяют. В итоге ключевой задачей менеджера является таким образом приоритизировать этот список хотелок, чтобы удовлетворить потребности всех заинтересованных сторон (клиентов в том числе).
В PAF используется другая концепция мышления. Нет больше списка задач, как набора разных идей разных сторон, поэтому нет задачи выбора элемента из этого списка. Есть карта целей, которые задаёт стратегическое направление. Исходя из целей и знаний из Нексуса формируется банч фич, которые с наименьшими рисками способны достичь этих целей. Ключевой задачей инженера продукта является не генерация как можно большего списка лучших идей и их приоритизация, а скаутинг (поиск, анализ и исследования) возможностей и угроз, чтобы повысить качество контекста Нексуса до того момента, покуда не останется идея с самым высоким уровнем уверенности (confidence point).
В PAF используется другая концепция мышления. Нет больше списка задач, как набора разных идей разных сторон, поэтому нет задачи выбора элемента из этого списка. Есть карта целей, которые задаёт стратегическое направление. Исходя из целей и знаний из Нексуса формируется банч фич, которые с наименьшими рисками способны достичь этих целей. Ключевой задачей инженера продукта является не генерация как можно большего списка лучших идей и их приоритизация, а скаутинг (поиск, анализ и исследования) возможностей и угроз, чтобы повысить качество контекста Нексуса до того момента, покуда не останется идея с самым высоким уровнем уверенности (confidence point).
6. Прибыль через ценность
Прибыль компании является результатом монетизации ценности, предоставляемой рынку. В первую очередь команда решает задачу создания востребованного продукта и подтверждает наличие product / market fit. Только потом она развивает способы монетизации созданной ценности, создавая масштабируемую бизнес-модель.
PAF реализует этот принцип за счет метрики mNSM (метрика монетизируемой ценности), которую максимизирует продуктовая команда для каждой фичи после её запуска.
PAF реализует этот принцип за счет метрики mNSM (метрика монетизируемой ценности), которую максимизирует продуктовая команда для каждой фичи после её запуска.
Команды бизнес-юнита и продукта
Business Pod & Product Pod
PAF определяет два типа основных управляющих единиц: Команда Бизнес-Юнита (англ. Business Pod) и более классическая Команда Продукта (англ. Product Pod). Они отличаются объектами управления: первая отвечает за весь один или несколько бизнес-юнитов, а вторая за часть одного бизнес-юнита, к которым можно отнести:
Разделение ответственности и синхронизация действий между разными командами происходит с помощью Карты Целей (англ. Goal Map) без прямого вмешательства. Руководителем продуктовой команды является Инженер Продукта (англ. Product Engineer). Руководителем команды бизнес-юнита является Инженер по Развитию Бизнеса (англ. Business Development Engineer). Один и тот же человек может играть обе роли, если обладает необходимыми компетенциями или управляет бизнес-юнитом небольшого размера. Инженер продукта может управлять сразу несколькими продуктами или бизнес-юнитами, становясь Менеджером портфеля (англ. Portfolio Manager).
- рынок как сегмент потребителей;
- продукт;
- фича или группа комплементарных фич продукта;
- часть пути потребителя внутри продукта;
- платформа, на базе которой реализован продукт, или её отдельная часть;
- тачпоинт продукта, или его отдельные части.
Разделение ответственности и синхронизация действий между разными командами происходит с помощью Карты Целей (англ. Goal Map) без прямого вмешательства. Руководителем продуктовой команды является Инженер Продукта (англ. Product Engineer). Руководителем команды бизнес-юнита является Инженер по Развитию Бизнеса (англ. Business Development Engineer). Один и тот же человек может играть обе роли, если обладает необходимыми компетенциями или управляет бизнес-юнитом небольшого размера. Инженер продукта может управлять сразу несколькими продуктами или бизнес-юнитами, становясь Менеджером портфеля (англ. Portfolio Manager).
Потенциальные объекты управления продуктовой команды
Размер продуктовой команды меньше, чем scrum команды, за счет преимуществ Кортекса, как "операционной системы" на базе ИИ. Благодаря ему специалисты в команде обладают comb-shaped компетенциями, а потому их количество и набор компетенций может варьироваться в зависимости от объекта управления и имеющихся ресурсов. PAF определяет только одну необходимую роль в команде - это инженер продукта. Фактически, команда может состоять даже из одного единственного человека, который отвечает за весь цикл исследования, проектирования, производства, запуска и дальнейшего развития продукта. Ключевое правило - это способность команды реализовать самостоятельно жизненный цикл своего объекта управления.
Модель управления
ИИ как технология доказала свою применимость в задачах управления продуктами. Более подробные доказательства этому приведены в отдельной статье. Этот аспект в совокупности с фактором скорости решения задач приводит к тому, что именно модель управления становится новым способом конкуренции компаний. Соответственно, отличием хорошего менеджера от плохого заключается не в том, насколько он успешен сам по себе, а в том, насколько он способен создать масштабируемую систему управления, в которой успешны будут все остальные.
PAF определяет такую систему управления как две взаимосвязанные части:
PAF определяет такую систему управления как две взаимосвязанные части:
- Нексус, который хранит контекст. Вместо разрозненного набора разных документов, продуктовые команды работают только с Нексусом, постоянно расширяя и сохраняя актуальность его контекста.
- Кортекс, который определяет правила работы с этим контекстом. Вместо работы вручную с отдельными артефактами, продуктовые команды управляют продуктом с помощью Кортекса.
Нексус
Nexus
Ключевой задачей инженера продукта является определение таких свойств продукта, или фич (англ. Feature), чтобы приносить ценность потребителям, эффективно конкурировать и монетизировать эту ценность для компании. Для этого он формирует "живую" модель продукта, или Нексус (англ. Nexus), которая является актуальным контекстом продукта, значительно расширяющим способности команды к принятию решений. Нексус формируется с момента создания продукта, постоянно обновляется по мере развития и отображает его текущее качественное и количественное состояние. Это динамический PRD (Product Requirements Document) в эпоху ИИ, который существует не только для синхронизации всех заинтересованных сторон перед запуском продукта, а в течение всего его жизненного цикла. Фактически, нексус - это цифровой двойник продукта.
PAF определяет несколько типов нексусов: рынка, продукта, системы роста, операционной модели и компании (его можно обозначить как нексус портфеля бизнес-юнитов). Каждый нескус состоит из самостоятельных кусочков контекста, которые называются Узлы (англ. Node). Одни узлы могут быть достаточно полными и актуальными, а другие нет. В том случае, если у компания работает с несколькими одинаковыми объектами управления, то нексус создается под каждый из них.
PAF определяет несколько типов нексусов: рынка, продукта, системы роста, операционной модели и компании (его можно обозначить как нексус портфеля бизнес-юнитов). Каждый нескус состоит из самостоятельных кусочков контекста, которые называются Узлы (англ. Node). Одни узлы могут быть достаточно полными и актуальными, а другие нет. В том случае, если у компания работает с несколькими одинаковыми объектами управления, то нексус создается под каждый из них.
Структура нексуса рынка
Объект управления: рынок.
Цель контекста: поиск возможностей и угроз для сокращения рисков достижения миссии компании.
Цель контекста: поиск возможностей и угроз для сокращения рисков достижения миссии компании.
Структура нексуса продукта
Объект управления: продукт.
Цель контекста: максимизация монетизируемой ценности и и сокращение time-to-market.
Цель контекста: максимизация монетизируемой ценности и и сокращение time-to-market.
Структура нексуса роста
Объект управления: система роста.
Цель контекста: максимизация чистой прибыли от новых и текущих клиентов и сокращение time-to-profit.
Цель контекста: максимизация чистой прибыли от новых и текущих клиентов и сокращение time-to-profit.
Структура нексуса компании
Объект управления: портфель бизнес-юнитов.
Цель контекста: максимизация инкремента миссии за минимальное количество ресурсов с учетом заданного риска.
Цель контекста: максимизация инкремента миссии за минимальное количество ресурсов с учетом заданного риска.
Спелость контекста
Метрикой качества контекста, хранимого в нексусе, является "Спелость" Контекста (англ. Context Ripeness), которую инженер продукта обязан повышать. Это комбинированная метрика, которая одновременно отображает две характеристики нексуса: его полноту и актуальность. Полнота определяется набором информации, которая заполнена относительно заданной структуры нексуса. Актуальность - как давно эта информация актуализировалась. Метрика отображает два этапа жизни нексуса:
- этап "созревания", когда в некусе увеличивается объем информации в узлах;
- этап "увядания", когда информация в узлах теряет актуальность со временем.
Кортекс
Cortex
Для любого взаимодействия с нексусом инженер продукта использует Кортекс (англ. Cortex), который представляет собой "операционную систему" управления продуктом. Это стандартизированная и масштабируемая система автоматизации всех процессов управления на базе технологий ИИ (агентов / RAG / интеграций / простых промптов). Качество этой системы определяется уровнем доступных для компании технологий и имеющимися ресурсами. Кортекс разделяется на отдельные контекстные области, предоставляя каждой роли достаточную информацию для принятия решений. Например, контекстной областью для продуктового инженера является нексус продукта. Контекстной областью для продуктового маркетолога является часть нексуса продукта, нексус рынка и нексус роста.
PAF не трактует КАК именно будет реализован Кортекс внутри компании, т.е. с помощью каких именно технологий. Это сделано намеренно, т.к. уровень зрелости ИИзации разных компаний совершенно разный. Ниже приведен черновик модели зрелости ИИзации процессов управления продуктами, где вы можете определить тот уровень, на котором вы сейчас находитесь. Он включает три фазы в зависимости от объекта ИИзации: отдельные задачи, процессы работы команд, процессы работы всей компании (или большей её части). Для каждой из фаз определены три уровня процессов: стратегический, операционный и уровень отдельной команды.
PAF не трактует КАК именно будет реализован Кортекс внутри компании, т.е. с помощью каких именно технологий. Это сделано намеренно, т.к. уровень зрелости ИИзации разных компаний совершенно разный. Ниже приведен черновик модели зрелости ИИзации процессов управления продуктами, где вы можете определить тот уровень, на котором вы сейчас находитесь. Он включает три фазы в зависимости от объекта ИИзации: отдельные задачи, процессы работы команд, процессы работы всей компании (или большей её части). Для каждой из фаз определены три уровня процессов: стратегический, операционный и уровень отдельной команды.
Модель зрелост AI Product Operations
Ключевая концепция Кортекса - что инженер продукта работает с проудктом не "вручную", а только через проводника, которым и является Кортекс. Инженер продукта ставит задачу Кортексу, а тот в свою очередь её выполняет, проводя определенные манипуляции с Нексусами и другими документами. Каким образом это реализуется, за счет просто промптов к ИИ платформам или с помощью агентов, определено компетенциями инженера продукта и политикой ИИзации компании. На прикладном уровне можно выделить несколько этапов реализации Кортекса (см. схему ниже). Причём находится на одном уровне Кортекса и на другом Нексуса.
Вне зависимости от технологической реализации Кортекса, он имеет чёткую архитектуру, определенную набором задач инженера продукта по управлению конкретными Нексусами. Ниже приведён пример такой архитектуры для части Кортекса, которая отвечет за работу с Нексусом Рынка.
Свойства продукта и сокращение гэпа
Feature Bunch & Gap
Инженеры продуктов формируют Образ Продукта, или Видение (англ. Vision). Образ продукта состоит из свойств продукта, или фич. Фича, или свойство продукта - это минимальный законченный "кирпичик" продуктовой ценности, состоящий:
- ценностных предложений, которые определяют добавочную ценность этой фичи при удовлетворении потребностей потребителя;
- набора интерфейсов, через которые потребитель получает это ценностное предложение;
- и технологической реализацией.
Из-за эффекта асинхронности процесса discovery, банч должен быть ограничен по размеру, т.е. обладать заданным Размером Банча (англ. Bunch Size). Размер выбирается методом договоренности внутри компании и как правило связан только со скоростью восприятия изменений рынком. Это значит, что даже если скорость разработки огромна, то наш поток новой ценности всё равно ограничен степенью восприятия изменений потребителями. Необходимо искать баланс между нашей скоростью выращивания и скоростью "потребления" рынком, чтобы избежать эффекта перепроизводства.
Инженер продукта формирует такой банч, который обладает максимальным показателем NPV за определенный период. Такой период называется Окном Банча (англ. Bunсh Window) и определяет период, через который мы хотим увидим бизнес-результат от фичи. Этот результат может быть выражен в деньгах от новых клиентов, в допродажа текущим клиентам, в увеличении используемости продукта при рекламной модели и т.д.
Формировать правильный банч, инженеру продукта помогают три критерия. Во-первых, содержмое банча должно быть таким, чтобы максимизировать монетизируемую ценность - за это отвечает показатель mNSM. Во-вторых, банч должен обладать минимальными рисками - за это отвечает показатель Confidence Point. В-третьих, эффект от банча должен быть виден в окне банча. Всё это и складывается в комплексный показатель NPV (или его аналогию), который отражает, как много заработает компания за определенный период времени от продуктовой деятельности с учётом заложенных рисков.
Инженер продукта управляет фичами продукта, максимизируя их метрику монетизируемой ценности (англ. monetizable North Star Metric, или mNSM). Она отображает конвертируемость ценности в прибыль для каждой отдельной фичи и продукта в целом. Сама ценность определяется через NSM по принципу чёрного ящика и существует и как метрика эффективности, и как метрика результативности.
Инженер продукта формирует такой банч, который обладает максимальным показателем NPV за определенный период. Такой период называется Окном Банча (англ. Bunсh Window) и определяет период, через который мы хотим увидим бизнес-результат от фичи. Этот результат может быть выражен в деньгах от новых клиентов, в допродажа текущим клиентам, в увеличении используемости продукта при рекламной модели и т.д.
Формировать правильный банч, инженеру продукта помогают три критерия. Во-первых, содержмое банча должно быть таким, чтобы максимизировать монетизируемую ценность - за это отвечает показатель mNSM. Во-вторых, банч должен обладать минимальными рисками - за это отвечает показатель Confidence Point. В-третьих, эффект от банча должен быть виден в окне банча. Всё это и складывается в комплексный показатель NPV (или его аналогию), который отражает, как много заработает компания за определенный период времени от продуктовой деятельности с учётом заложенных рисков.
Инженер продукта управляет фичами продукта, максимизируя их метрику монетизируемой ценности (англ. monetizable North Star Metric, или mNSM). Она отображает конвертируемость ценности в прибыль для каждой отдельной фичи и продукта в целом. Сама ценность определяется через NSM по принципу чёрного ящика и существует и как метрика эффективности, и как метрика результативности.
Оценка уверенности фичи
Во всех гибких методологиях разработки, как потомков производственной системы Toyota, оптимизируются потери и большая часть процессов сфокусированы на том, что их снизить. PAF оперирует другой сущностью вместо потерь - рисками. Задача продуктового инженера – оптимизация рисков недостижения целей, которую он осуществляет за счет повышения Оценки уверенности фич (англ. Confidence Point). Команда продукта обновляет оценку уверенности во время события "Питчинг Доверия".
Фактически эта оценка является определением уровня контекста и разницы между текущими знаниями и теми, что нам нужно получить.
Логику роста доверия к фиче хорошо отображает концепция колеса от Итамара Гилада, которую он предложил, чтобы сделать показатель Confidence Level объективным в схемах приоритизации ICE или RICE.
Фактически эта оценка является определением уровня контекста и разницы между текущими знаниями и теми, что нам нужно получить.
- Оценка повышается по мере прохождения по stage-gate процессам и является критерием для прохождения на следующую стадию.
- Оценка повышается, когда появляется новая значимая информация по инициативе, которая снижает неопределенность в принятии решений.
- Оценка снижается Кортексом или продуктовым инженером, если срабатывают риски (например, фича не принесла ценности) или происходят отклонения (например, фича долго раскатывается).
- Оценка предназначена для фокусировки продуктового инженера на его ключевой задаче – сокращения рисков продуктовых инициатив.
- Оценка включает оценку стоимости риска. Необходимо для ответа на вопрос: “Сколько мы потратим ещё ресурсов команды и получим негативного эффекта на клиентскую базу, если запустим фичу при таком уровне рисков?”.
Логику роста доверия к фиче хорошо отображает концепция колеса от Итамара Гилада, которую он предложил, чтобы сделать показатель Confidence Level объективным в схемах приоритизации ICE или RICE.
Ролевая модель
Team Roles
-
Business Development EngineerИнженер по развитию бизнеса
Отвечает за бизнес-юнит. Ключевая функция - максимизация NPV. Работает в связке с менеджером роста и управляет инженерами продукта. В небольших компаниях объединяет роли и инженера продукта, и инженера роста. - Portfolio ManagerМенеджер портфеля бизнес-юнитов
Ключевая функция - максимизация NPV для всего портфеля или экосистемы продуктов. Его задача - управление балансом маржинальности бизнес-юнитов в портфеле. Распределяет ресурсы между командами. Решает конфликты каннибализации продуктов. Равен роли CPO. - Growth EngineerИнженер роста
Является частью команды бизнес-юнита и отвечает за модель роста. Ключевая функция - максимизация mNSM за счет привлечения новых клиентов и увеличения LTV для текущих. - Product OpsМенеджер продуктовых процессов
Отвечает за настройку и эффективность работы нексусов и кортекса. Измеряет и повышает качество процессов управления продуктами. Подчиняется Portfolio Manager.
Процессы
Processes
Концепция Трёх Линз
Three Process Lenses
Концепция трёх линз предполагает, что команды рассматривают процесс работы сразу на нескольких уровнях. Смена "оптики" позволяет командам понимать, каким образом они влияют на бизнес-модель и стратегию компании в целом. PAF выделяет три линзы: стратегии, бизнеса и продукта.
Линза продукта позволяет команде сфокусироваться на их операционных процессах работы с продуктами. Объектом управления для этой линзы является продукт. С помощью нексуса продукта команды определяют текущее состояние продукта и формируют банч фич, с которым дальше работают в продуктовых спринтах (англ. Product Sprint). Продуктовый спринт отличается от спринтов отдельных команд (например, спринтов разработки или дизайн-спринтов) и предназначен для работы с продуктым контекстом. Его размерность определена средним time-to-market, но имеет двойственную структуру времени. С одной стороны процесс работы с банчем является асинхронным в силу скорости работы инженера продукта через кортекс. С другой стороны по принципу бутылочных горлышек он всё равно упирается либо в другие команды, либо в другие процессы, с которыми приходится синхронизироваться по времени.
Линза бизнеса позволяет команде бизнес-юнита выстроить работу между отдельными своими частями, будь то команды или отдельные специалисты. Объектом управления для этой линзы является модель роста. Модель роста преставляет собой набор Рычагов (англ. Lever), при инвестировании в развитие которых бизнес-юнит увеличивает свой NPV. Рычаги - это измеримые свойства бизнес-модели или продукта. Для продукта частным случаем рычага является его фичи, поэтому развитие бизнес-юнита возможно за счет увеличения добавочной ценности продукта, добавляемому через банчи фич. Для бизнес-модели рычаги более разнообразны, так как определяют способы дистрибуции и монетизации ценности (см. модель роста ниже). Работа с этой линзой проходит в бизнес-спринтах (англ. Business Sprint) и необходима для распределения ресурсов бизнес-юнита на запуск новых кросс-функциональных проектов, которые являются конкретными реализациями рычагов. Бизнес-спринт состоит из нескольких продуктовых спринтов, но отличается от него, т.к. состояние продукта меняется быстрее, чем состояние бизнес-юнита в целом.
Линза бизнеса позволяет команде бизнес-юнита выстроить работу между отдельными своими частями, будь то команды или отдельные специалисты. Объектом управления для этой линзы является модель роста. Модель роста преставляет собой набор Рычагов (англ. Lever), при инвестировании в развитие которых бизнес-юнит увеличивает свой NPV. Рычаги - это измеримые свойства бизнес-модели или продукта. Для продукта частным случаем рычага является его фичи, поэтому развитие бизнес-юнита возможно за счет увеличения добавочной ценности продукта, добавляемому через банчи фич. Для бизнес-модели рычаги более разнообразны, так как определяют способы дистрибуции и монетизации ценности (см. модель роста ниже). Работа с этой линзой проходит в бизнес-спринтах (англ. Business Sprint) и необходима для распределения ресурсов бизнес-юнита на запуск новых кросс-функциональных проектов, которые являются конкретными реализациями рычагов. Бизнес-спринт состоит из нескольких продуктовых спринтов, но отличается от него, т.к. состояние продукта меняется быстрее, чем состояние бизнес-юнита в целом.
Модель роста
Линза стратегии позволяет команде посмотреть на её деятельность с точки зрения реализации стратегии. Объект управления на этом уровне - портфель бизнес-юнитов. Компания работает с ним по стратегическим спринтам (англ. Strategic Sprint), отправной точкой для которого являются долгосрочные цели и рыночные условия, консолидированные в нексусе рынка. Они определяют те стратегические сценарии, которые должна реализовать компания. Стратегический сценарий разбивается на набор Ставок (англ. Bets), которые с одной стороны могут быть связаны с запуском новых элементов портфеля, а с другой стороны с инвестированием ресурсов в рычаги роста текущих бизнес-юнитов. Именно в стратегических спринтах компания решает свои задачи по изменению своей организационной структуры, процессов управления или поиска новых ресурсов.
Эффект асинхронности
Одним из самых сложных для восприятия аспектов управления PAF является эффект асинхронности. Он связан с тем, что если у каждой локальной продуктовой команды скорость (как discovery, так и development, когда релиз может наступить в любой момент времени) растёт как угодно высоко, то компания в целом становится плохо синхронизированной, т.к. появляются простои. Это значит, что общие циклы синхронизации (например, то же PI-планирование) перестают работать. Нужен асинхронный подход, повязанный не на каденциях, а на событийной модели (event-based). Поэтому и с точки разработки лучше всего будет подходить Kanban и его производные, чем Scrum.
Stage-Gate процессы
Логика stage-gate представляет собой концепцию создания новых продуктов или фич, которая разбивает процесс на последовательные этапы (stage) с обязательными контрольными точками (gate) между ними. У каждой контрольной точки есть условия, при выполнении которых проект проходит на следующие этапы (например, смотрите процесс Product Discovery или жизненный цикл фичи). Это позволяет значительно сократить риски при неуспеха для инициатив. Выполнение условия гейтов является обязательным. Чем выше оценка доверия (confidence point), тем выше вероятность прохождения гейта или осознанного отказа в необходимости этой инициативы, поэтому повышение уровня контекста напрямую связано со скоростью процессов развития продуктов согласно PAF.
Спринт продукта
Product Sprint
Команда продукта работает по продуктовым спринтам. В отличие от scrum продуктовый спринт PAF представляет собой не единый направленный временной поток, а скорее "сезоны", где одна часть может проходить очень быстро в силу своей асинхронности, а другая - быть растянута во времени. В ходе продуктового спринта команда определяет текущие свойства продукта и меняет их для достижения поставленных целей, ища наиболее оптимальный банч фич. Важно, как было сказано ранее, PAF не противоречит методологиям разработки и определяет уровень "над" ним. Непосредственно для разработки команда разработки может работать по любой из методологий, однако, предпочтение отдаются асинхронным, таким как kanban и её производные, так как они ещё больше усиливают эффект от современных технологий искусственного интеллекта.
Пульс прогресса (англ. Progress Pulse) является событием, с которого стартует продуктовый спринт. Во время Пульса продуктовая команда определяет текущее состояние продукта. Это похоже на то, как пилоты смотрят на приборную панель самолёта. Инженер продукта определяет гэп между текущим состоянием и целевым, формируя Банч фич. Дальнейшей задачей инженера продукта является поиск аргументов, способных "насытить" контекстом банч (англ. Bunch Saturation). Смотрите описание логики этого процесса ниже.
Как только инженер продукта готов, наступает ритуал Питчинга Доверия (англ. Pitching of Trust), на котором инженер продукта питчит команде содержимое банча и аргументы по фичам. Задачей команды является "завалить" текущие аргументы, найти в них слабые места. В результате команда назначает Оценку Доверия (англ. Confidence Point) для фич из банча. Фичи с низкой оценкой выкидываются. Для фич с наибольшей оценкой формируются требования на разработку и передаются разработчикам по принятым в команде процессам. Для этого могут быть выделены привычные всем спринты разработки. В результате процесса разработки появляются инкремент продукта, для которого Инженер продукта формирует Change Log.
Данный инкремент передаётся в маркетинг для подготовки к запуску на рынок. Маркетинг формирует оффер для этого инкремента и упаковывает его в Тюк, или Бейл (англ. Bale). Бейл Фичи - это инкремент продукта с понятным оффером и планом дистрибуции до аудитории. Маркетинг формирует release notes и доставляет этот бейл до аудитории. Начинается "проращивание" (англ. Germination) донесенной ценности: аудитория онбордится в фичу, пытается определить для себя ценность, постепенно формирует привычку и т.д.
Упрощенно, бейл представляет собой гипотезу спроса, состояющую из нескольких компонентов. Задачей инженера роста является подбор таких компонентов, чтобы максимизировать используемость и скорость онбординга в эту фичу.
Как только инженер продукта готов, наступает ритуал Питчинга Доверия (англ. Pitching of Trust), на котором инженер продукта питчит команде содержимое банча и аргументы по фичам. Задачей команды является "завалить" текущие аргументы, найти в них слабые места. В результате команда назначает Оценку Доверия (англ. Confidence Point) для фич из банча. Фичи с низкой оценкой выкидываются. Для фич с наибольшей оценкой формируются требования на разработку и передаются разработчикам по принятым в команде процессам. Для этого могут быть выделены привычные всем спринты разработки. В результате процесса разработки появляются инкремент продукта, для которого Инженер продукта формирует Change Log.
Данный инкремент передаётся в маркетинг для подготовки к запуску на рынок. Маркетинг формирует оффер для этого инкремента и упаковывает его в Тюк, или Бейл (англ. Bale). Бейл Фичи - это инкремент продукта с понятным оффером и планом дистрибуции до аудитории. Маркетинг формирует release notes и доставляет этот бейл до аудитории. Начинается "проращивание" (англ. Germination) донесенной ценности: аудитория онбордится в фичу, пытается определить для себя ценность, постепенно формирует привычку и т.д.
Упрощенно, бейл представляет собой гипотезу спроса, состояющую из нескольких компонентов. Задачей инженера роста является подбор таких компонентов, чтобы максимизировать используемость и скорость онбординга в эту фичу.
В конце продуктового спринта команда проводит событие Сбора Урожая (англ. Harvesting), на котором команда подводит итог запуска фичи, насколько она произвела импакт в цели команды и фиксирует NPV. Все новые знания превращаются в инкремент контекста, который сохраняется в нексусах.
Насыщение банча фич
Bunch Saturation
Событие пульс прогресса, формирование банча и дальнейшее его насыщение базируется на концепции "Understand, Identify, Execute" (сокращенно Und-Id-Ex). Она представляет собой последовательность проработки идей продукта, которые напрямую влияют на достижение целей. Есть два принципа работы по этой методике:
- Принцип "null base", когда у продуктовой команды нет фундамента из данных и потому она вынуждена проводить product discovery с нуля, последовательно проверяя гипотезы потребностей, гипотезы ценностных предложений и гипотезы реализации. Как правило это бывает в случае работы с совершенно новым продуктом или новыми фичами, значимо отличающихся от текущих.
- Принцип "data base", когда у продуктовой команды уже есть какой-то продукт, из которого можно извлечь знания о поведении потребителей и которые дают понимание о бутылочных горлышках продукта.
- Определяется цель развития продукта.
- Этап Understand. На этом этапе инженер продукта анализирует нексус, пытаясь найти и разобраться, что именно сейчас влияет на выполнимость целей, т.е. какие нужно создать или изменить текущие свойства продукта. При необходимости, команда формулирует гипотезы и проводит исследования.
- Этап Identify. На этом этапе инженер продукта с помощью кортекса формирует идеи, как можно расшить найденные бутылочные горлышки и проводит тестирование гипотез. По мере получения информации меняется оценка уверенности для фичи, а нексус наполняется новой информацией.
- Этап Execute. На этом этапе команда продукта масштабирует на всю аудиторию продукта подтвержденные решения и проверяет достижимость цели.
- Цикл начинается заново.
Визуальное представление процесса насыщения банча фич
Заключение
Здесь представлен лишь общий каркас операционных процессов управления продуктами согласно Product Architecture Framework. Сам фреймворк поставляется бесплатно под лицензией CC BY-SA 4.0 License, что позволяет другим его распространять, перерабатывать, исправлять и развивать при условии обязательного указания авторства и распространять результаты на тех же условиях. В случае изменения элементов фреймворка, отличных от представленного здесь руководства или сайта https://productframework.ru/, результаты уже не будет признаны как PAF.