74 lines
5.6 KiB
Markdown
74 lines
5.6 KiB
Markdown
---
|
||
title: "Phase 6 Playbook — Operate & Evolve"
|
||
type: source
|
||
tags: []
|
||
date: 2026-04-29
|
||
---
|
||
|
||
## Source File
|
||
- [[Agent/agency-agents/strategy/playbooks/phase-6-operate]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：产品上线后的持续运营与演进框架，定义多频次运营节拍、持续改进闭环、应急响应协议和战略进化流程。
|
||
- 问题域：产品已上线（Phase 5 结束），如何维持高质量运营并实现持续增长与优化。
|
||
- 方法/机制：通过分层运营节拍（Continuous / Daily / Weekly / Bi-Weekly / Monthly / Quarterly）分配 Agent 职责；建立 Measure → Analyze → Plan → Build → Validate → Deploy 六步持续改进闭环；P0–P3 四级应急响应机制；季度战略评审驱动产品演进。
|
||
- 结论/价值：Phase 6 无结束日期，只要产品在市场一天就持续运行；新功能通过压缩的 NEXUS 循环（7步）快速迭代。
|
||
|
||
## Key Claims（用中文描述）
|
||
- Studio Producer 作为治理核心，通过分层节拍协调 12+ Agent 的持续运营活动。
|
||
- 持续改进闭环（Measure → Deploy）每季度推动流程效率提升 20%。
|
||
- P0 事故需即时响应（MTTR < 30 分钟），P3 纳入下个 Sprint 处理。
|
||
- 月度增长评审整合渠道表现、实验结果、留存分析和增长路线图更新。
|
||
- 季度战略评审从市场定位、产品策略、增长策略和组织健康四个维度评估产品方向。
|
||
|
||
## Key Quotes
|
||
> "Phase 6 has no end date. It runs as long as the product is in market, with continuous improvement cycles driving the product forward." — Phase 6 运营哲学
|
||
|
||
> "Preparation beats heroics." — 应急响应核心原则（与 Incident Response Commander Agent 共享理念）
|
||
|
||
## Key Concepts
|
||
- [[Continuous Improvement Loop]]：Measure → Analyze → Plan → Build → Validate → Deploy 的六步持续改进闭环，每季度推动流程效率提升 20%。
|
||
- [[Operational Cadence]]：分层运营节拍——Continuous（常驻）、Daily、Weekly、Bi-Weekly、Monthly、Quarterly，将 Agent 职责与活动频率对齐。
|
||
- [[Incident Response Protocol]]：P0–P3 四级事故分级与对应响应团队、响应时间和决策权限的结构化应急体系。
|
||
- [[NEXUS Sprint]]：Phase 6 中新功能开发的压缩生命周期——从 Backlog 选择到用户反馈收集的 7 步快速迭代循环。
|
||
- [[Growth Operations]]：以 Growth Hacker 为核心，整合渠道分析、实验追踪、留存分析和增长路线图的月度增长评审。
|
||
- [[Financial Operations]]：以 Finance Tracker 为核心，覆盖收入分析、成本分析、单位经济指标和预测的月度财务评审。
|
||
- [[Compliance Operations]]：以 Legal Compliance Checker 为核心，覆盖监管跟踪、隐私合规、安全合规和审计准备的月度合规评审。
|
||
- [[Quarterly Strategic Review]]：以 Studio Producer 为核心，从市场定位、产品策略、增长策略和组织健康四个维度进行季度战略评审。
|
||
|
||
## Key Entities
|
||
- [[Studio Producer]]：Phase 6 治理核心，协调所有运营节拍，主持季度战略评审，P0 事故最终决策者。
|
||
- [[Infrastructure Maintainer]]：负责系统正常运行时间（99.9%）和性能安全，SLA 要求 MTTR < 30 分钟。
|
||
- [[Support Responder]]：负责客户支持与问题解决，首次响应 SLA < 4 小时。
|
||
- [[DevOps Automator]]：负责部署流水线和热修复，支持每日多次部署能力。
|
||
- [[Analytics Reporter]]：负责 KPI 仪表板更新，每日快照和每周性能分析。
|
||
- [[Feedback Synthesizer]]：负责用户反馈综合，周会和双周深度分析。
|
||
- [[Sprint Prioritizer]]：负责待办列表梳理和 Sprint 规划。
|
||
- [[Growth Hacker]]：负责增长渠道优化，主持月度增长评审。
|
||
- [[Project Shepherd]]：跨团队协调，P1 事故决策权限。
|
||
- [[Experiment Tracker]]：负责 A/B 测试分析与实验结果总结。
|
||
- [[Content Creator]]：负责内容日历执行和发布内容报告。
|
||
- [[Executive Summary Generator]]：负责 C-suite 月度报告。
|
||
- [[Finance Tracker]]：负责月度财务报告和单位经济分析。
|
||
- [[Legal Compliance Checker]]：负责月度监管合规检查。
|
||
- [[Trend Researcher]]：负责月度市场情报更新。
|
||
- [[Brand Guardian]]：负责月度品牌一致性审计。
|
||
- [[Workflow Optimizer]]：负责流程效率审计和优化报告。
|
||
- [[Performance Benchmarker]]：负责性能回归测试和季度性能报告。
|
||
- [[Tool Evaluator]]：负责技术栈评估和 Tech Debt 评估。
|
||
- [[Agents Orchestrator]]：P2 事故决策权限，分类并分配响应团队。
|
||
|
||
## Connections
|
||
- [[phase-5-hardening]] ← extends ← [[phase-6-operate]]（Phase 6 以 Phase 5 的质量门槛为前提）
|
||
- [[phase-3-build]] ← implements ← [[NEXUS Sprint]]（NEXUS Sprint 是 Phase 3 Dev↔QA 循环在 Phase 6 的复用）
|
||
- [[project-management-studio-producer]] ← governs ← [[phase-6-operate]]（Studio Producer Agent 是 Phase 6 的核心治理角色）
|
||
- [[handoff-templates]] ← receives_from ← [[phase-5-hardening]]（Phase 5 Handoff Package 是 Phase 6 的输入）
|
||
- [[scenario-incident-response]] ← implements ← [[Incident Response Protocol]]（场景手册是应急协议的具体执行指南）
|
||
|
||
## Contradictions
|
||
- 与 [[scenario-incident-response]] 存在细节差异：
|
||
- 冲突点：事故分级体系名称和粒度不同。
|
||
- 当前观点：Phase 6 使用 P0–P3 四级，定义明确响应时间和决策权限。
|
||
- 对方观点：Incident Response Runbook 可能使用 SEV1–SEV4 分级体系。
|
||
- 建议：以 Phase 6 文档的 P0–P3 为准，Incident Response Runbook 应与 Phase 6 对齐或明确说明两套体系如何共存。
|