Настроить Cookies
Настроики Cookies
Файлы cookie, необходимые для корректной работы сайта, всегда включены. Другие файлы cookie можно настроить.
Руководство
Product Architecture Framework
AI Product Operations
Определение
Product Architecture Framework (сокращенно PAF) - методология проектирования системы управления продуктами в эпоху ИИ, которая помогает отдельным командам и большим корпорациям выстроить масштабируемые и прозрачные процессы и организационную структуру для повышения скорости и качества роста монетизируемой ценности за счет создания стратегического фундамента и адаптации к текущим изменениям рынка.
PAF определяет условия среды, в которой продуктовые команды осознанно и целенаправленно способны достигать бизнес-целей компании за счет развития продуктов. Элементы этой среды включают:
Общая концепция управления PAF выглядит так:
Product Architecture Framework является насколько это возможно непротиворечивым и полностью описывающим управление продуктом и его связку с бизнесом. Это реализовано за счет теории объектов управления, которая определяет единую парадигму мышления для всех участников процессов: начиная с уровня команды и заканчивая стратегическим планированием. PAF основан на других методологиях: Customer Development, Scrum, концепция жизненных циклов (рынка, продукта, организации, команды), stage-gate процессах и т.д. Ключевой миссией PAF было создать язык для проектирования системы управления продуктами, найти лакуны в текущих методологиях и свести к общим понятиям сущности, которые в разных методологиях назывались по-разному, но представляли собой одни и те же объекты управления.
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 было создать язык для проектирования системы управления продуктами, найти лакуны в текущих методологиях и свести к общим понятиям сущности, которые в разных методологиях назывались по-разному, но представляли собой одни и те же объекты управления.
Принципы 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). Они отличаются объектами управления: первая отвечает за весь один или несколько бизнес-юнитов, а вторая за часть одного бизнес-юнита. К ним можно отнести:
- рынок как сегмент потребителей;
- продукт;
- фича или группа комплементарных фич продукта;
- часть пути потребителя внутри продукта;
- платформа, на базе которой реализован продукт, или её отдельная часть;
- тачпоинт продукта, или его отдельные части.
Потенциальные объекты управления продуктовой команды
Размер продуктовой команды меньше, чем scrum команды, за счет преимуществ Кортекса, как "операционной системы" на базе ИИ. Благодаря ему специалисты в команде обладают comb-shaped компетенциями, а потому их количество и набор компетенций может варьироваться в зависимости от объекта управления и имеющихся ресурсов. PAF определяет только одну необходимую роль в команде - это инженер продукта. Фактически, команда может состоять даже из одного единственного человека, который отвечает за весь цикл исследования, проектирования, производства, запуска и дальнейшего развития продукта. Ключевое правило - это способность команды реализовать самостоятельно жизненный цикл своего объекта управления.
Нексус
Nexus
Ключевой задачей инженера продукта является определение таких свойств продукта, или фич (англ. Feature), чтобы приносить ценность потребителям, эффективно конкурировать и монетизировать эту ценность для компании. Для этого он формирует "живую" модель продукта, или Нексус (англ. Nexus), которая является актуальным контекстом продукта, значительно расширяющим способности команды к принятию решений. Нексус формируется с момента создания продукта, постоянно обновляется по мере развития и отображает его текущее качественное и количественное состояние. Это динамический PRD (Product Requirements Document) в эпоху ИИ, который существует не только для синхронизации всех заинтересованных сторон перед запуском продукта, а в течение всего его жизненного цикла. Фактически, нексус - это цифровой двойник продукта.
PAF определяет несколько типов нексусов: рынка, продукта, системы роста, операционной модели и компании (его можно обозначить как нексус портфеля бизнес-юнитов). В том случае, если у компания работает с несколькими одинаковыми объектами управления, то нексус создается под каждый из них.
PAF определяет несколько типов нексусов: рынка, продукта, системы роста, операционной модели и компании (его можно обозначить как нексус портфеля бизнес-юнитов). В том случае, если у компания работает с несколькими одинаковыми объектами управления, то нексус создается под каждый из них.
Структура нексуса рынка
Объект управления: рынок.
Цель контекста: поиск возможностей и угроз для сокращения рисков достижения миссии компании.
Цель контекста: поиск возможностей и угроз для сокращения рисков достижения миссии компании.
Структура нексуса продукта
Объект управления: продукт.
Цель контекста: максимизация монетизируемой ценности и и сокращение time-to-market.
Цель контекста: максимизация монетизируемой ценности и и сокращение time-to-market.
Структура нексуса роста
Объект управления: система роста.
Цель контекста: максимизация чистой прибыли от новых и текущих клиентов и сокращение time-to-profit.
Цель контекста: максимизация чистой прибыли от новых и текущих клиентов и сокращение time-to-profit.
Структура нексуса компании
Объект управления: портфель бизнес-юнитов.
Цель контекста: максимизация инкремента миссии за минимальное количество ресурсов с учетом заданного риска.
Цель контекста: максимизация инкремента миссии за минимальное количество ресурсов с учетом заданного риска.
Метрикой качества контекста, хранимого в нексусе, является "Спелость" Контекста (англ. Context Ripeness), которую инженер продукта обязан повышать. Это комбинированная метрика, которая одновременно отображает две характеристики нексуса: его полноту и актуальность. Полнота определяется набором информации, которая заполнена относительно заданной структуры нексуса. Актуальность - как давно эта информация актуализировалась. Метрика отображает два этапа жизни нексуса:
- этап "созревания", когда в некусе увеличивается объем информации;
- этап "увядания", когда информация теряет актуальность со временем.
Кортекс
Cortex
Для любого взаимодействия с нексусом инженер продукта использует Кортекс (англ. Cortex), которая представляет собой "операционную систему" управления продуктом. Это стандартизированная и масштабируемая система автоматизации всех процессов управления на базе технологий ИИ (агентов / RAG / интеграций / простых промпотов). Качество этой системы определяется уровнем доступных для компании технологий и имеющимися ресурсами. Кортекс разделяется на отдельные контекстные области, предоставляя каждой роли достаточную информацию для принятия решений. Например, контекстной областью для продуктового инженера является нексус продукта. Контекстной областью для продуктового маркетолога является часть нексуса продукта, нексус рынка и нексус роста.
PAF не трактует КАК именно будет реализован Кортекс внутри компании, т.е. с помощью каких именно технологий. Это сделано намеренно, т.к. уровень зрелости ИИзации разных компаний совершенно разный. Ниже приведен черновик модели зрелости ИИзации процессов управления продуктами, где вы можете определить тот уровень, на котором вы сейчас находитесь. Он включает три фазы в зависимости от объекта ИИзации: отдельные задачи, процессы работы команд, процессы работы всей компании (или большей её части). Для каждой из фаз определены три уровня процессов: стратегический, операционный и уровень отдельной команды.
PAF не трактует КАК именно будет реализован Кортекс внутри компании, т.е. с помощью каких именно технологий. Это сделано намеренно, т.к. уровень зрелости ИИзации разных компаний совершенно разный. Ниже приведен черновик модели зрелости ИИзации процессов управления продуктами, где вы можете определить тот уровень, на котором вы сейчас находитесь. Он включает три фазы в зависимости от объекта ИИзации: отдельные задачи, процессы работы команд, процессы работы всей компании (или большей её части). Для каждой из фаз определены три уровня процессов: стратегический, операционный и уровень отдельной команды.
Модель зрелост AI Product Operations
Ключевая концепция Кортекса - что инженер продукта работает с проудктом не "вручную", а только через проводник, которым и является Кортекс. Инженер продукта ставит задачу Кортексу, а тот в свою очередь её выполняет, проводя определенные манипуляции с Нексусами и другими документами. Каким образом это реализуется, за счет просто промптов к ИИ платформам или с помощью агентов, определено компетенциями инженера продукта и политикой ИИзации компании. На прикладном уровне можно выделить несколько этапов реализации Кортекса (см. схему ниже). Причём находится на одном уровне Кортекса и на другом Нексуса.
Свойства продукта
Feature
Фича, или свойство продукта - это минимальный законченный "кирпичик" продуктовой ценности, состоящий:
Инженер продукта управляет фичами продукта, максимизируя их метрику монетизируемой ценности (англ. monetizable North Star Metric, или mNSM). Она отображает конвертируемость ценности в прибыль для каждой отдельной фичи и продукта в целом. Сама ценность определяется через NSM по принципу чёрного ящика и существует и как метрика эффективности, и как метрика результативности.
- ценностных предложений, которые определяют добавочную ценность этой фичи при удовлетворении потребностей потребителя;
- набора интерфейсов, через которые потребитель получает это ценностное предложение;
- и технологической реализацией.
Инженер продукта управляет фичами продукта, максимизируя их метрику монетизируемой ценности (англ. monetizable North Star Metric, или mNSM). Она отображает конвертируемость ценности в прибыль для каждой отдельной фичи и продукта в целом. Сама ценность определяется через NSM по принципу чёрного ящика и существует и как метрика эффективности, и как метрика результативности.