AI-ТРАНСФОРМАЦИЯ ⚡¶
Свод ключевых принципов построения AI-Native продуктовой команды по методологии Product Architecture Framework (PAF). Автор фреймворка: Тихомиров Сергей («Борода продакта»). Лицензия CC BY-SA 4.0. Документ систематизирован по SA-Helper: каждое утверждение маркируется источником [S1]–[S7]; недоступные источники пересказу по содержимому не подлежат (раздел «Пробелы»).
📚 Карта источников (ground truth)¶
| Код | Источник | Тема | Статус |
|---|---|---|---|
| [S1] | productframework.ru/ops/main | Каркас PAF, AI Product Operations | ✅ полный |
| [S2] | productframework.ru/ai_product_roles | Трансформация роли PM в эпоху ИИ | ✅ полный |
| [S3] | productframework.ru/skill_map | Карта навыков менеджера продукта | ✅ полный |
| [S4] | Профстандарт 06.012 | Гос. стандарт «Менеджер продуктов ИТ» | ✅ полный |
| [S5] | Medium / Typical Company (В. Розова) | Навыки PM | ⚠️ частично (paywall) — разбор |
| [S6] | Google Sheet Product Mindset v1.2 | Табличная карта навыков | ⚠️ только заголовок |
| [S7] | Miro board | Визуальная карта | ❌ закрытая доска |
🎯 Зачем нужен этот документ¶
PAF отвечает на два c-level вопроса [S1]:
- Почему продуктовый подход НЕ даёт бизнес-результата? — потому что компаниям «продали» методологии разработки (Scrum, Kanban) как панацею от бизнес-проблем. Процесс разработки ≠ процесс развития продукта. Scrum (наследник тойотовской системы производства) оптимизирует потери производства, а развитие продукта отвечает на другой вопрос: как создать продукт с максимальным возвратом монетизируемой ценности на инвестиции (ключевой параметр — NPV) [S1].
- Каким должно быть управление продуктами в эпоху ИИ? — когда практически все задачи менеджера могут быть ИИзированы [S1, S2]. ИИ = disruptive-технология раз в сто лет. Discovery решается почти мгновенно, часть задач полностью делегируется [S1, S2].
Главный тезис автора [S2]: в эпоху ИИ конкуренция смещается с продуктов на контекст и модель управления им. «У кого лучше собран контекст продукта и реализована ИИзация работы с ним — тот и будет лидером на рынке» [S2].
ЧАСТЬ I. ОБЩИЙ КАРКАС PAF [S1]¶
PAF определяет среду, в которой продуктовые команды осознанно достигают бизнес-целей за счёт развития продуктов [S1]:
| Элемент | Суть | Источник |
|---|---|---|
| Портфель Бизнес-Юнитов | Бизнес-юнит = связка «рынок × продукт × бизнес-модель». Минимальная стратегическая единица прибыли. | [S1] |
| Нексус (Nexus) | Информационная модель продукта/бизнеса/рынка — достаточный контекст для решений. | [S1] |
| Кортекс (Cortex) | Операционная система управления Нексусами с помощью ИИ. | [S1] |
| Инженер Продукта (Product Engineer) | Заменяет PM. Управляет развитием через Кортекс посредством контекста Нексуса. | [S1, S2] |
| Менеджер Продуктовых Процессов (Product Ops / «пропс») | Помогает построить Нексусы и настроить процессы Кортекса. | [S1, S2] |
Базовая логика управления [S1]: 1. Инженер формирует Видение (Vision) = образ продукта из фич (Features). Разрыв между текущим и Видением = Гэп (gap). 2. Функция инженера — сократить Гэп. Набор фич = Банч (Feature Bunch), определяется только текущим состоянием (Нексусом). В PAF нет Беклога. 3. PAF — уровень над методологиями разработки; внутри команды — scrum/kanban/scrumban. 4. Инженер управляет Нексусами, переключаясь между горизонтами через Концепцию Трёх Линз (3PL). 5. После релиза Кортекс обновляет Нексус → меняется Банч → цикл повторяется.
ЧАСТЬ II. ШЕСТЬ ПРИНЦИПОВ PAF [S1]¶
Принцип 1. Прозрачность до очевидности¶
Менеджер = функция управления объектами через обмен квантами информации; его функция = сокращение времени на обмен информацией. Рост доверия к решениям требует роста прозрачности (полнота + непротиворечивость + доступ стейкхолдеров). Реализация: Нексусы + отсутствие Беклога [S1].
Принцип 2. Совместная унификация контекста¶
Формализация контекста важнее повторяющейся коммуникации. Все стейкхолдеры создают единое хранилище — Нексус — и работают с ним, а не с разрозненными документами.
🏆 «Именно контекст является новым способом конкуренции между компаниями. Выиграет тот, у кого лучше контекст и кто сможет им эффективнее управлять» [S1].
Принцип 3. Гибкая стабильность (Stagility = stability + agility)¶
Стабильность долгосрочной цели + гибкость пути. Стратегия задаёт будущее состояние, но не способ его достижения. Управление гэпом долгосрочное/краткосрочное — через риски [S1].
Принцип 4. Управление рисками = управление знаниями¶
Управление продуктом — НЕ производство, а возделывание. Вместо потерь — оптимизация рисков (энтропии по Шеннону). Потери — прошлое, риски — будущее. Задача инженера — сокращение рисков через насыщение Нексуса информацией. Реализация: изменение Confidence Point [S1].
Принцип 5. Скаутинг вместо приоритизации¶
Нет списка задач → нет выбора элемента. Есть карта целей. Задача инженера — скаутинг (поиск, анализ, исследования) возможностей и угроз, чтобы поднять контекст Нексуса до идеи с максимальным confidence point [S1].
Принцип 6. Прибыль через ценность¶
Прибыль = результат монетизации ценности. Сначала — востребованный продукт и PMF, затем — масштабируемая бизнес-модель. Реализация: метрика mNSM [S1].
ЧАСТЬ III. AI-NATIVE КОМАНДА [S1] + [S2]¶
III.1. Два полюса операционной модели¶
🔹 Нексус — где хранится контекст [S1]¶
«Живая» модель продукта = актуальный контекст = динамический PRD эпохи ИИ = цифровой двойник. Существует весь жизненный цикл. Типы: рынка, продукта, системы роста, операционной модели, компании. Состоит из Узлов (Nodes). - Метрика качества — «Спелость контекста» (Context Ripeness) = полнота × актуальность. Два этапа: «созревание» (рост инфо) и «увядание» (потеря актуальности). Инженер обязан её повышать.
🔹 Кортекс — операционная система на базе ИИ [S1]¶
Стандартизированная система автоматизации всех процессов (агенты / RAG / интеграции / промпты). Разделяется на контекстные области под каждую роль. PAF не фиксирует технологию реализации (зрелость компаний разная). - Ключевая концепция: инженер работает только через проводника — Кортекс, не вручную. Ставит задачу → Кортекс манипулирует Нексусами.
III.2. Команды: Business Pod и Product Pod [S1]¶
| Команда | Объект управления | Руководитель |
|---|---|---|
| Business Pod | весь бизнес-юнит (несколько) | Инженер по Развитию Бизнеса |
| Product Pod | часть юнита: сегмент / продукт / фича / часть пути / платформа / тачпоинт | Инженер Продукта |
Требования [S1]: - Команда обладает всеми ресурсами для создания, дистрибуции и монетизации ценности (полный ЖЦ объекта). - Синхронизация между командами — через Карту Целей (Goal Map) без прямого вмешательства. - Размер команды меньше scrum-команды: специалисты comb-shaped, количество/набор варьируются. Единственная обязательная роль — инженер продукта. Под может быть из одного человека (весь цикл: исследование → проектирование → производство → запуск → развитие).
III.3. Ролевая модель каркаса PAF [S1]¶
| Роль | Ключевая функция |
|---|---|
| Инженер по развитию бизнеса | Отвечает за бизнес-юнит. Максимизация NPV. В малых компаниях объединяет роли. |
| Менеджер портфеля (Portfolio Manager) | Максимизация NPV всего портфеля. Баланс маржинальности, конфликты каннибализации. ≈ CPO. |
| Инженер роста (Growth Engineer) | Максимизация mNSM: новые клиенты + рост LTV. |
| Product Ops | Настройка/эффективность Нексусов и Кортекса. Подчиняется Portfolio Manager. |
III.4. Трансформация роли (3 оптимизации) [S2]¶
- Автоматизация — сокращение срока задач.
- Аугментация — рост качества: альтернативная точка зрения, челендж идей/рисков, экспертиза, обучение как наставник.
- Агентизация — полное/частичное делегирование ИИ.
⚠️ Критический фильтр [S2]: рост качества — только при достаточных метапознании и компетенциях для валидации. Junior без метапознания + ИИ = нулевой прирост. Компетентный, но забивший на верификацию = «убедительные, но неверные» результаты (фронт ИИ, Harvard × BCG).
Паттерны работы с ИИ [S2]: Кентавры (делят/делегируют часть ИИ) и Киборги (интегрируют поток задач с ИИ).
Вне контура ИИзации (зона человека) [S2]: 1. Стратегическое планирование (распределение ресурсов; агенты — инструменты, не акторы; ответственность не передать). 2. Синхронизация взаимодействия сотрудников (кросс-проекты, корпоративные интриги; ИИ не преодолеет, но сделает прозрачным).
III.5. Сдвиги системной динамики → структура команды [S2]¶
| Закон | Следствие для команды |
|---|---|
| Голдратт (Theory of Constraints) | ИИ снял bottleneck с discovery/разработки → сместился на дистрибуцию (последняя миля). |
| Product Life Cycle + консолидация рынков | Фаза запуска прошла → фокус на масштабировании. |
| Парадокс Джевонса | Удешевление когнитивного труда через ИИ увеличивает его потребление → больше сложных продуктов/экспериментов, а не сокращение штата. |
| Value Chain | Рост спроса в звене тянет инвестиции в предыдущее. |
| Курцвейл (ускоряющаяся отдача) | Прогресс экспоненциален (галлюцинации ИИ встречаются реже). |
| Иерархия потребностей | Операционка закрыта → фокус на стратегии/развитии/инновациях. |
Прямая проекция на команду [S2]: 1. Один менеджер → портфель (объект управления смещается с продукта на экосистему, инвестиционная логика). 2. Сдвиг с операционки на стратегию и целеполагание. 3. Малые автономные поды (pods): Марти Каган — компании 15–20 команд сократятся до 3–5 с тем же результатом (comb-shaped + ИИ замещает недостающее). 4. Документация исчезает → цифровой профиль продукта (количественные метрики + качественные артефакты, единая точка инфо, аналог claude.md, но для продукта/процессов). Взаимодействие — через агентов.
III.6. Новые роли AI-Native команды [S2]¶
| Роль | Объект управления | Функция |
|---|---|---|
| Product Engineer | продукт | Максимизация монетизируемой ценности через свойства продукта. НЕ вайбкодер. Две компоненты: ① проектирование «цифрового профиля» (инженерия контекста, по Тоби Лютке); ② определение AI workflow (что делегировать агентам, что себе). |
| Product Portfolio Manager / Bizdev Architect | портфель | Максимизация NPV портфеля, баланс маржинальности/каннибализации. Инвестиционная логика. Формирует «цифровой профиль бизнес-модели». |
| Technical / AI Product Manager | продукт с ИИ | Максимизация ценности через ИИ-свойства. Понимает LLM, сшивает агентов, оценивает качество моделей. KPI: точность, прецизионность, полнота, производительность. |
| Growth Product Manager | модель роста | Минимизация time-to-activation, максимизация LTV, ROI токенизируемых функций. Ключевые метрики — adoption/usage. Контрольная точка COGS (помимо CAC/LTV). |
| Discovery / Launcher PM | запуск продукта | Минимизация time-to-market и time-to-PMF. Человек-команда: продуктовые компетенции + вайбкодинг. Full Stack Product Manager. |
| AI UX Designer | UX & UI | Управление метафорами взаимодействия с ИИ, tone-of-voice. ИИ в продукт ≠ чат-бот без изменений UX. |
| Product Ops / Product Architect | product operations | Повышение качества процессов. Помогает строить каркас «цифрового профиля»/«цифрового каркаса бизнес-модели». Миссия — рост ИИ-зрелости компании. Аналог scrum master AI-эпохи. |
III.7. Тёмные стороны (учитывать при построении команды) [S2]¶
- Workslop («рабочий мусор») — генерация материалов, перекладывающих когнитивную нагрузку на потребителя (~15,4%). Снижает, а не повышает эффективность (MIT: 95% не получают отдачи от инвестиций в ИИ).
- Дофаминовая петля ИИ — с ИИ приятнее взаимодействовать, чем с людьми; рост когнитивной нагрузки, а не снижение (Berkeley 2025: рост интенсивности, мультизадачность, размытие работа/не-работа).
- Креативность ≠ автоусилитель — ИИ усиливает креативность только у людей с сильным метапознанием (полевой эксперимент, 250 чел.).
III.8. Новые метафоры ИИ-продукта и потребителя [S2]¶
| Уровень | Классическое ПО | AI-продукт | Изменение дизайна |
|---|---|---|---|
| Ментальная модель | Команда → Результат | Намерение → Черновик → Уточнение | Дизайн для итераций |
| Метафора | Инструмент | Партнёр / соавтор | Интерфейс поддерживает диалог |
| Ошибка | Системное сообщение | Альтернатива / уточнение | Ошибка = новый промпт |
| Ввод | Формы, валидация | Естественный язык, референсы | Валидация: синтаксис → семантика |
| Время | Мгновенно / прогресс-бар | Streaming + «мысли вслух» | Ожидание заполнено мышлением |
Новая 4-я роль потребителя — «секретарь/адъютант» (агент с поведением и потребностями) + сущность «поручение» (правила делегирования) [S2].
ЧАСТЬ IV. НАВЫКИ МЕНЕДЖЕРА ПРОДУКТА (Skill Map) [S3]¶
Развёртка PAF Skills Map — карты навыков менеджера продукта с точки зрения PAF. Фокус — только hard skills (управление командой и soft skills исключены: важны, но не целевы для фреймворка) [S3].
IV.1. Менеджер продукта как целевая функция [S3]¶
Любая роль в компании — целевая функция «механизма» бизнеса, решающая задачу оптимизации: - Системный аналитик → минимизация разницы между желанием заказчика и результатом. - Менеджер продаж → максимизация прибыли от клиентов за период. - Продуктовый маркетолог → максимизация ROI для привлечённых когорт.
Целевая функция менеджера продукта [S3]: максимизация ценности, которую продукт приносит потребителям, с минимизацией time-to-market.
Что НЕ является целью PM (причина vs следствие) [S3]¶
- НЕ прибыль — но, увеличивая ценность (в измеримых показателях), он расширяет возможности монетизации.
- НЕ исследования — но, организуя их, снижает риски «никому не нужных» решений → снижает time-to-market.
- НЕ рост метрик — метрики = показатель результата изменения объёма ценности, а не сама ценность.
Вывод [S3]: PM — тот, кто определяет условия внешней и внутренней среды и свойства продукта, при которых продукт достигает целей бизнеса.
IV.2. Шесть секторов карты навыков [S3]¶
| № | Сектор | Что покрывает |
|---|---|---|
| 1 | Discovery & Researches | Качественные и количественные исследования, контекст потребителя/пользователя. |
| 2 | Value & Solution Design | Формирование ценностных предложений и конечных решений на базе исследований. |
| 3 | Development & Delivery | Управление разработкой спроектированных решений и поставка пользователям. |
| 4 | Growth & Experiments | Развитие существующих проектов, достижение целей продуктовой компании. |
| 5 | Product Marketing | Привлечение и удержание потребителей, донесение ценностных предложений. |
| 6 | Sales & Economics | Монетизация ценности продукта и финансовое планирование. |
IV.3. Три уровня владения каждым сектором [S3]¶
| Круг | Неопределённость | Уровень | Фокус управления |
|---|---|---|---|
| Внутренний | низкая — атомарная задача, идея/гипотеза без валидации | junior | одиночная задача / фича / метрика отдельной фичи |
| Средний | средняя — анализ, агрегация, обоснованные выводы, сложное проектирование | middle / senior | проект / вертикаль / продукт / комплексная метрика продукта |
| Внешний | высокая — целеполагание, процессы, стратегические инициативы | senior / head of / CPO | продукт / портфель / бизнес-юнит / North Star / метрики бизнеса |
IV.4. Последовательность и конфигурации навыков [S3]¶
- Навыки связаны лучами: развитие одного требует предварительного другого. Пример: нет смысла развивать «Приоритезацию беклога» без навыка «Формирование беклога» [S3].
- Конфигурации — наборы навыков под конкретную роль/контекст компании (ЖЦ продукта, оргструктура, зрелость культуры, отрасль, ресурсы, риски). Используются для тестовых заданий, программ ассесмента и развития.
IV.5. Почему PAF Skills Map (а не другие) [S3]¶
Существуют альтернативные карты навыков: Product Star (Миша Карпов), Typical (Валерия Розова) [S5], Product Mindset (Юра Агеев) [S6]. Самым системным автор PAF считает профстандарт 06.012 (см. Часть V) [S3, S4]. Причины для PAF Skills Map [S3]: 1. Показать связь между активностями этапов ЖЦ продукта и навыками PM. 2. Дать полный спектр задач PM (где-то упор на экономику забывает проектирование, где-то скуден маркетинг). 3. Преодолеть проблему линейных списков (трудно проследить приоритет навыков; группировка искусственна/противоречива). 4. Показать адаптацию карт под разные профили менеджеров (связи навыков). 5. Единый уровень абстракции навыков (вместо смешения).
ЧАСТЬ V. ПРОФСТАНДАРТ 06.012 «МЕНЕДЖЕР ПРОДУКТОВ В ОБЛАСТИ ИТ» [S4]¶
Профессиональный стандарт, утверждённый приказом Минтруда РФ № 636н от 16.09.2021, регистрационный номер 147. Самый системный, по оценке автора PAF, взгляд на функции менеджера продукта [S3]. 4 обобщённые трудовые функции, уровни квалификации 4–7.
📝 О редакции: статья [S3] (сентябрь 2021) ссылается на первоначальную редакцию стандарта от 2014 г. Ниже приведены актуальные данные из [S4] — живого реестра Минтруда (приказ 636н от 16.09.2021, действующая редакция). Расхождение со [S3] не вводится — используется более свежий источник.
| Код | Обобщённая функция | Уровень | Трудовые функции (выборка) | Маппинг к PAF |
|---|---|---|---|---|
| A | Сопровождение развития существующего ИТ-продукта | 4 | A/01.4 орг.сопровождение исследований · A/02.4 требования · A/03.4 дизайн/разработка/выпуск обновлений · A/04.4 планы развития и продвижения · A/05.4 поддержка продаж | ассистент / junior PM |
| B | Управление ИТ-продуктом | 5 | B/01.5 продуктовые исследования · B/02.5 определение продукта/дизайн/требования · B/03.5 план развития · B/04.5 заказ разработки/контроль/приёмка · B/05.5 координация подразделений · B/06.5 вывод на рынок · B/07.5 экспертное сопровождение продаж · B/08.5 показатели успешности · B/09.5 вывод с рынка | Product Engineer |
| C | Управление серией ИТ-продуктов и группой менеджеров | 6 | C/01.6 технологические исследования · C/02.6 бизнес-планы/цены/стратегия серии · C/03.6 партнёрства · C/04.6 бюджет серии · C/05.6 команды и персонал · C/06.6 продвижение · C/07.6 программа проектов · C/08.6 патенты · C/09.6 M&A интеллектуальных активов | Portfolio Manager |
| D | Управление портфелем ИТ-продуктов и подразделением | 7 | D/01.7 исследования новых рынков · D/02.7 управление портфелем · D/03.7 процессы и практики управления продуктами · D/04.7 командообразование/персонал · D/05.7 эффективность менеджеров · D/06.7 покупка/продажа активов | CPO / Head of Product |
Классификация [S4]: ОКЗ 1221 (руководители служб сбыта и маркетинга), 2431 (специалисты по рекламе и маркетингу), 3322 (агенты по коммерческим продажам). ОКВЭД 62.02, 70.22, 73.20.1.
⚠️ Связка стандарт ↔ PAF — ИНТЕРПРЕТАТИВНАЯ (авторская реконструкция на основе [S3]+[S4], не прямое утверждение стандарта): уровни A→D профстандарта примерно соответствуют вертикальному росту в PAF — A≈ассистент PM, B≈Product Engineer, C≈Portfolio Manager, D≈CPO/Head of Product. Краевые соответствия (A→«ассистент», D→«директор по продуктам») прямо указаны в [S3]; маппинг средних уровней (B/C) — интерпретация, помеченная как таковая. При этом PAF переопределяет способ работы на каждом уровне — через Нексус и Кортекс, а не вручную [S1].
ЧАСТЬ VI. ПРОЦЕССЫ AI-NATIVE КОМАНДЫ [S1]¶
VI.1. Концепция Трёх Линз (3PL)¶
| Линза | Объект управления | Спринт |
|---|---|---|
| Продукта | продукт | Product Sprint (Нексус продукта → состояние → Банч; размер = time-to-market) |
| Бизнеса | модель роста | Business Sprint (Рычаги/Lever → NPV; состоит из нескольких Product Sprint) |
| Стратегии | портфель бизнес-юнитов | Strategic Sprint (долгосрочные цели + Нексус рынка → Ставки/Bets) |
VI.2. Эффект асинхронности (критично) [S1]¶
При росте локальных скоростей компания в целом рассинхронизируется — каденции (PI-планирование) ломаются. Вывод: нужен асинхронный event-based подход, с точки разработки — Kanban и его производные, не Scrum.
VI.3. Stage-Gate процессы [S1]¶
Этапы с обязательными гейтами. Чем выше Confidence Point, тем выше шанс прохождения гейта или осознанного отказа. Рост контекста = рост скорости процессов.
VI.4. Цикл Product Sprint [S1]¶
PAF-спринт — не единый поток, а «сезоны» (асинхронно). События: 1. Пульс прогресса (Progress Pulse) — старт; фиксация состояния (как пилоты у приборной панели); гэп → Банч. 2. Насыщение банча (Bunch Saturation) — методика Und-Id-Ex (Understand → Identify → Execute). 3. Питчинг доверия (Pitching of Trust) — защита банча; команда «заваливает» аргументы → Confidence Point. Слабые фичи выкидываются, сильные → в разработку. 4. Разработка → инкремент → Change Log. 5. Бейл (Bale) — маркетинг: инкремент + оффер + план дистрибуции → release notes. 6. Проращивание (Germination) — онбординг аудитории, формирование привычки. 7. Сбор урожая (Harvesting) — импакт, фиксация NPV, инкремент контекста в Нексус. Цикл заново.
VI.5. Методика Und-Id-Ex [S1]¶
- Null base — нет данных → discovery с нуля (гипотезы потребностей → ЦП → реализации). Для нового продукта.
- Data base — есть продукт → извлекаем знания о поведении, находим бутылочные горлышки.
- Этапы: ① цель развития → ② Understand (анализ Нексуса) → ③ Identify (Кортекс генерит идеи, тест гипотез, рост CP) → ④ Execute (масштабирование) → цикл.
VI.6. Банч vs Беклог [S1]¶
| Беклог | Банч | |
|---|---|---|
| Цель | С чем работать в первую очередь | Как выиграть конкуренцию |
| Объекты мышления | Ресурсы + идеи + метрики | Свойства продукта + конкуренция + гэп |
| Срок жизни | Накопленный | Только в моменте |
| Источник | Стейкхолдеры + старые штурмы | Только анализ текущего состояния |
| Миссия | Утилизировать разработку | Макс. финансовая и продуктовая ценность быстро |
Лимиты Банча [S1]: Размер (Bunch Size) — ограничен скоростью восприятия рынка (баланс выращивания/потребления, без перепроизводства). Окно (Bunch Window) — период ожидания бизнес-результата. Три критерия: ① макс. mNSM; ② мин. рисков (Confidence Point); ③ эффект в окне → комплексный NPV.
VI.7. Confidence Point — ядро управления рисками [S1]¶
Уровень контекста и разница между текущими и нужными знаниями. - Растёт по stage-gate (критерий перехода) и при появлении информации, снижающей неопределённость. - Падает (Кортекс/инженер) при срабатывании рисков/отклонениях. - Включает оценку стоимости риска: «Сколько ещё потратим ресурсов и негативного эффекта на клиентскую базу при таком уровне рисков?». - Логика роста доверия — колесо Итамара Гилада (объективизация Confidence Level в ICE/RICE).
ЧАСТЬ VII. МОДЕЛЬ ЗРЕЛОСТИ AI PRODUCT OPERATIONS [S1]¶
Кортекс реализуется поэтапно. Три фазы по объекту ИИзации:
| Фаза | Объект ИИзации |
|---|---|
| 1 | Отдельные задачи |
| 2 | Процессы работы команд |
| 3 | Процессы работы всей компании |
Три уровня процессов в каждой фазе: стратегический, операционный, уровень отдельной команды.
Миссия Product Ops [S2] — двигать команду по этой модели. Можно быть на одном уровне Кортекса и другом — Нексуса.
ЧАСТЬ VIII. СВОДНАЯ ТАБЛИЦА: КЛАССИЧЕСКАЯ VS AI-NATIVE КОМАНДА¶
| Параметр | Классическая (Scrum-эпоха) | AI-Native (PAF) | Источник |
|---|---|---|---|
| Базовый артефакт | Беклог | Банч (в моменте) | [S1] |
| Объект управления PM | Поток задач в разработку | Нексусы | [S1] |
| Ключевая метрика процесса | Скорость/потери | Confidence Point (риски) | [S1] |
| Бизнес-метрика | velocity, story points | NPV, mNSM | [S1] |
| Документация | Разрозненные документы | Цифровой профиль (Нексус) | [S1, S2] |
| Работа с продуктом | Вручную | Через Кортекс | [S1] |
| Мышление | Приоритизация списка | Скаутинг | [S1] |
| Роль | Product Manager | Product Engineer | [S1, S2] |
| Профиль компетенций | T-shaped | Comb-shaped | [S2] |
| Размер команды | Scrum-team (7±2) | Pod (может быть 1) | [S1, S2] |
| Ритм | Каденции | Event-based / Kanban | [S1] |
| Конкуренция | Продуктами | Контекстом и моделью управления | [S2] |
| Bottleneck | Discovery / разработка | Дистрибуция (последняя миля) | [S2] |
| Карта навыков | Линейный список | 6 секторов × 3 уровня + конфигурации | [S3] |
| Гос. соответствие | — | Профстандарт 06.012 (A/B/C/D) | [S4] |
ЧАСТЬ IX. ПРАКТИЧЕСКИЕ СЛЕДСТВИЯ ДЛЯ AI-KORTEX¶
- Сначала Нексус, потом Кортекс. Без спелого контекста Кортекс усиливает мусор. Спелость = полнота × актуальность — как метрика [S1].
- Убрать Беклог. Перейти к Банчу из текущего состояния Нексуса под карту целей [S1].
- Растить метапознание. Главный фильтр прироста качества от ИИ [S2].
- Проектировать AI workflow явно. Стратегия + синхронизация людей — всегда за человеком [S2].
- Асинхронный Kanban/event-based вместо каденций — убирает простои, усиливает ИИ [S1].
- Готовиться к bottleneck на дистрибуции. Рост adoption/usage, контроль COGS токенов [S2].
- Product Ops — роль-двигатель модели зрелости AI Product Operations [S1, S2].
- Карта навыков как конфигурация. Собирать роли из 6 секторов × 3 уровня под контекст компании; сверять с профстандартом 06.012 [S3, S4].
⚠️ Раздел «Пробелы» (zero hallucination)¶
Документ построен на полных источниках [S1]–[S4]. Источник [S5] получен частично (paywall), [S6]–[S7] недоступны автоматическому разбору. Пересказу скрытого/недоступного содержимого по принципу zero hallucination не подлежат:
- [S5] Medium / Typical Company — «Какие навыки нужны менеджеру продукта» (Валерия Розова). Получен через Playwright (real Chromium + Google referer, HTTP 200): заголовок, автор, публикация, вводные абзацы, дисклеймер автора. Полный список навыков скрыт metered/member paywall Medium и НЕ реконструируется. Детали:
sources/S5_medium.md. Известно: авторский hard&soft-skills чек-лист, регулярно обновляется (совпадает с упоминанием «Typical/Розова» в [S3]). - [S6] Google Sheet «[Product Mindset] Навыки менеджера продуктов v1.2» — получен только заголовок (JS-рендер, ячейки не извлекаются). Табличная карта навыков (Product Mindset / Юра Агеев). Содержимое не цитируется.
- [S7] Miro board uXjVOs817Gs — закрытая интерактивная доска (canvas требует рендер/доступ). Указана как визуальный артефакт без пересказа.
Закрытие пробелов: для полного покрытия [S5] (нужен логин Medium через Playwright + cookies пользователя), [S6] (Google OAuth + расшаренная таблица), [S7] (доступ к доске Miro) — предоставить доступ/креденшалы или прислать содержимое вручную.
📚 Источники¶
| Код | Полная ссылка | Автор / дата |
|---|---|---|
| [S1] | https://productframework.ru/ops/main | Тихомиров С. (PAF, CC BY-SA 4.0) |
| [S2] | https://productframework.ru/ai_product_roles | Тихомиров С., апрель 2026 |
| [S3] | https://productframework.ru/skill_map | Тихомиров С., сентябрь 2021 |
| [S4] | Профстандарт 06.012, приказ Минтруда № 636н от 16.09.2021, рег. № 147 | Минтруд РФ, 2021 |
| [S5] | Medium / Typical Company (В. Розова) | ⚠️ частично (paywall) |
| [S6] | Google Sheet [Product Mindset] v1.2 | ⚠️ только заголовок |
| [S7] | Miro board uXjVOs817Gs | ❌ закрытая доска |
🔗 Связанные артефакты¶
- Провенанс источников:
sources/S5_medium.md(разбор paywall-источника S5),sa_documentation/naming_conventions.md(глоссарий PAF). - Существующие ноты: 1.0 Базовые концепции · 1.1 Нексус Рынка · 1.2 Нексус Продукта · 1.3 Нексус Роста · 2.1 Linza Strategy · 2.2 Linza Business · 2.3 Linza Product · 3.2 Confidence Points · 3.3 AI Bunch Formation · 6.1 Pitching of Trust