@umacloud/knowledge 1.0.1

package/product/01-standards/product-management-complete.md

@@ -0,0 +1,285 @@
+---
+id: product-management-complete
+title: 产品管理完整指南
+domain: product
+category: 01-standards
+difficulty: intermediate
+tags: [complete, discovery, management, product, 产品发现, 概述, 用户故事, 用户画像]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 产品管理完整指南
+
+## 概述
+
+产品管理是连接业务目标、用户需求和技术实现的核心环节。本指南覆盖产品发现、需求分析、优先级管理、PRD 编写、数据驱动决策和产品指标体系。
+
+---
+
+## 产品发现 (Product Discovery)
+
+### 用户研究方法
+
+| 方法 | 适用场景 | 成本 | 产出 |
+|------|----------|------|------|
+| 用户访谈 | 深度理解需求 | 中 | 用户画像/痛点地图 |
+| 问卷调查 | 量化验证假设 | 低 | 统计数据 |
+| 可用性测试 | 验证原型 | 中 | 交互优化建议 |
+| A/B 测试 | 比较方案效果 | 中 | 数据驱动决策 |
+| 竞品分析 | 了解市场格局 | 低 | 差异化策略 |
+| 数据分析 | 发现行为模式 | 低 | 洞察报告 |
+
+### Jobs-to-be-Done 框架
+
+```
+当 [情境] 时，
+我想要 [动机/目标]，
+这样我可以 [期望结果]。
+
+示例:
+当我在通勤路上时，
+我想要快速浏览今日技术新闻，
+这样我可以在工作前了解行业动态。
+```
+
+---
+
+## 需求分析
+
+### 用户故事格式
+
+```markdown
+## 用户故事
+
+**作为** [角色]
+**我想要** [功能]
+**以便于** [价值]
+
+### 验收标准
+- Given [前置条件]
+- When [操作]
+- Then [预期结果]
+
+### 边界条件
+- 最大/最小输入值
+- 空状态处理
+- 错误场景
+- 并发场景
+
+### 非功能需求
+- 响应时间: < 200ms
+- 并发用户: 1000+
+- 数据量: 100万+ 记录
+```
+
+### MoSCoW 优先级
+
+```
+Must Have (必须有):   核心功能，没有就不能发布
+Should Have (应该有): 重要功能，但可以延迟
+Could Have (可以有):  锦上添花，有时间就做
+Won't Have (不会有):  明确排除，本期不做
+```
+
+### RICE 评分
+
+```python
+def rice_score(reach: int, impact: float, confidence: float, effort: int) -> float:
+    """
+    RICE 优先级评分
+    reach: 影响用户数 (每季度)
+    impact: 影响程度 (0.25=低, 0.5=中, 1=高, 2=很高, 3=极高)
+    confidence: 信心度 (0-100%)
+    effort: 人月工时
+    """
+    return (reach * impact * confidence) / effort
+
+# 示例
+features = [
+    {"name": "搜索优化", "rice": rice_score(5000, 2, 0.8, 3)},    # 2667
+    {"name": "暗色模式", "rice": rice_score(8000, 0.5, 0.9, 2)},   # 1800
+    {"name": "导出PDF",  "rice": rice_score(1000, 1, 0.7, 1)},     # 700
+]
+# 按 RICE 分数排序确定优先级
+```
+
+---
+
+## PRD 编写
+
+### PRD 模板
+
+```markdown
+# [功能名称] 产品需求文档
+
+## 1. 背景与目标
+- 为什么要做这个功能？
+- 解决什么问题？
+- 成功指标是什么？
+
+## 2. 用户画像
+- 目标用户是谁？
+- 用户的核心痛点？
+- 当前用户如何解决？
+
+## 3. 功能描述
+### 3.1 核心流程
+[流程图/状态图]
+
+### 3.2 详细需求
+#### 功能点 1: [名称]
+- 描述: ...
+- 输入: ...
+- 输出: ...
+- 验收标准: ...
+
+## 4. 数据需求
+- 需要哪些新数据？
+- 数据来源？
+- 数据量预估？
+
+## 5. 非功能需求
+- 性能要求
+- 安全要求
+- 兼容性要求
+
+## 6. 设计稿
+[Figma 链接]
+
+## 7. 技术方案
+[简要技术方案或链接]
+
+## 8. 发布计划
+- 灰度策略
+- 回滚方案
+- 监控指标
+
+## 9. 风险评估
+| 风险 | 影响 | 概率 | 缓解措施 |
+```
+
+---
+
+## 产品指标体系
+
+### 北极星指标 (North Star Metric)
+
+```
+SaaS 产品:  月活跃用户 (MAU) / 周活跃用户 (WAU)
+电商产品:   GMV (商品交易总额)
+内容产品:   日均阅读时长
+社交产品:   日均发送消息数
+工具产品:   任务完成数
+```
+
+### AARRR 海盗指标
+
+```
+Acquisition (获取):   新用户注册数、注册转化率
+Activation (激活):    首次完成核心动作的比例
+Retention (留存):     次日/7日/30日留存率
+Revenue (收入):       ARPU、LTV、付费转化���
+Referral (推荐):      NPS、邀请转化率
+```
+
+### 关键指标定义
+
+```python
+# DAU / MAU 比值 (用户黏性)
+stickiness = dau / mau  # > 0.2 为健康
+
+# 留存率
+retention_d1 = users_returned_day1 / users_registered_day0
+retention_d7 = users_returned_day7 / users_registered_day0
+retention_d30 = users_returned_day30 / users_registered_day0
+
+# LTV (用户生命周期价值)
+ltv = arpu * average_lifetime_months
+
+# CAC (客户获取成本)
+cac = total_marketing_spend / new_customers
+
+# LTV/CAC > 3 为健康
+```
+
+---
+
+## 数据驱动决策
+
+### A/B 测试框架
+
+```python
+# 样本量计算
+import math
+
+def required_sample_size(
+    baseline_rate: float,      # 基线转化率 (如 0.05)
+    minimum_effect: float,     # 最小检测效应 (如 0.01)
+    alpha: float = 0.05,       # 显著性水平
+    power: float = 0.8         # 统计功效
+) -> int:
+    """计算每组所需样本量"""
+    p1 = baseline_rate
+    p2 = baseline_rate + minimum_effect
+    p_avg = (p1 + p2) / 2
+
+    z_alpha = 1.96  # 95% 置信区间
+    z_beta = 0.84   # 80% power
+
+    n = ((z_alpha * math.sqrt(2 * p_avg * (1 - p_avg)) +
+          z_beta * math.sqrt(p1 * (1 - p1) + p2 * (1 - p2))) ** 2) / \
+         (p2 - p1) ** 2
+
+    return math.ceil(n)
+
+# 示例: 基线转化率 5%，检测 1% 提升
+n = required_sample_size(0.05, 0.01)
+print(f"每组需要 {n} 样本")  # 约 3,800
+```
+
+---
+
+## 常见反模式
+
+### 1. 功能堆砌 (Feature Factory)
+❌ 不断添加功能，不验证价值
+✅ 先验证假设，再投入开发
+
+### 2. HiPPO (最高薪资者的意见)
+❌ 老板说做就做
+✅ 用数据说话，A/B 测试验证
+
+### 3. 过度设计
+❌ 第一版就想做到完美
+✅ MVP 快速验证，迭代优化
+
+---
+
+## Agent Checklist
+
+Agent 在产品设计阶段必须检查:
+
+- [ ] 是否有明确的目标用户画像？
+- [ ] 是否定义了北极星指标？
+- [ ] 需求是否有清晰的验收标准？
+- [ ] 是否做了优先级排序（RICE/MoSCoW）？
+- [ ] PRD 是否包含非功能需求？
+- [ ] 是否有灰度发布和回滚方案��
+- [ ] 是否有监控指标和告警？
+- [ ] 是否考虑了边界条件和错误场景？
+- [ ] 设计是否有移动端适配？
+- [ ] 是否有数据埋点方案？
+
+---
+
+## 参考资料
+
+- [Marty Cagan - Inspired](https://www.svpg.com/inspired-how-to-create-tech-products-customers-love/)
+- [Google HEART Framework](https://research.google/pubs/measuring-the-user-experience-on-a-large-scale-a-user-centered-metrics-for-web-applications/)
+- [Intercom on Product Management](https://www.intercom.com/blog/product-management/)
+
+---
+
+**文档版本**: v1.0
+**最后更新**: 2026-03-28
+**质量评分**: 87/100

package/product/02-playbooks/feature-launch-playbook.md

@@ -0,0 +1,207 @@
+---
+id: feature-launch-playbook
+title: 功能上线 Playbook
+domain: product
+category: 02-playbooks
+difficulty: intermediate
+tags: [agent, checklist, feature, launch, playbook, product, 上线日期, 功能名称]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 功能上线 Playbook
+
+## 概述
+
+本 Playbook 定义功能从开发完成到全量上线的标准流程。适用于面向用户的产品功能发布，
+覆盖灰度策略、监控配置、数据验证、全量发布和上线复盘五个阶段。
+目标：确保每次功能上线可控、可观测、可回滚。
+
+---
+
+## 阶段一：上线准备（发布前 3-5 天）
+
+### 1.1 功能验收
+
+- [ ] 产品经理完成功能验收并签字确认
+- [ ] QA 完成全量测试用例执行，通过率 100%
+- [ ] 无 P0/P1 级别的已知 Bug
+- [ ] 性能测试通过（目标接口 P99 < 500ms，QPS 满足预估峰值 1.5x）
+- [ ] 安全审查通过（无 SQL 注入/XSS/越权等高危漏洞）
+
+### 1.2 发布计划
+
+- [ ] 发布日期和时间窗口确定（避开业务高峰期）
+- [ ] 灰度策略确定（用户比例/用户分组/地区）
+- [ ] 回滚方案文档化（触发条件 + 操作步骤 + 预期耗时）
+- [ ] 相关团队通知（客服/运营/市场）并同步 FAQ
+
+### 1.3 监控准备
+
+- [ ] 功能相关的业务指标埋点已上线并验证
+- [ ] 监控 Dashboard 已创建（核心指标：转化率/错误率/性能）
+- [ ] 告警规则已配置（阈值基于历史基线）
+- [ ] 日志关键字监控已配置（ERROR/WARN 相关的新增日志）
+
+### 1.4 Feature Flag 配置
+
+- [ ] Feature Flag 已创建并在 staging 环境验证
+- [ ] Flag 默认关闭，灰度规则已配置
+- [ ] 紧急关闭 Flag 的操作步骤已验证（< 1 分钟可完成）
+- [ ] Flag 清理计划已排期（全量后 2 周内清除）
+
+---
+
+## 阶段二：灰度发布（第 1-3 天）
+
+### 2.1 灰度策略推荐
+
+```
+阶段 1: 内部员工 / 种子用户（1-2%）  →  观察 24h
+阶段 2: 5% 用户                      →  观察 24-48h
+阶段 3: 20% 用户                     →  观察 24h
+阶段 4: 50% 用户                     →  观察 12-24h
+阶段 5: 100% 全量
+```
+
+### 2.2 灰度期间检查项
+
+每个灰度阶段推进前，需确认以下指标正常：
+
+| 检查项 | 达标标准 | 检查频率 |
+|--------|----------|----------|
+| 接口错误率 | 与基线持平（波动 < 0.5%） | 每小时 |
+| 接口 P99 延迟 | 与基线持平（波动 < 20%） | 每小时 |
+| 核心转化率 | 不低于基线 5% | 每 4 小时 |
+| 客诉量 | 无新增相关客诉 | 每 4 小时 |
+| 资源使用 | CPU/内存无异常飙升 | 每小时 |
+
+### 2.3 灰度期间沟通
+
+- 每日发布灰度状态报告到项目群
+- 报告包含：当前灰度比例、核心指标、异常情况、下一步计划
+- 异常情况 30 分钟内通知项目负责人
+
+---
+
+## 阶段三：数据验证（灰度期间持续进行）
+
+### 3.1 功能指标验证
+
+- [ ] 功能使用率是否达到预期（DAU 渗透率）
+- [ ] 关键路径转化漏斗是否符合预期
+- [ ] 新功能是否对现有功能产生负面影响（回归指标）
+- [ ] A/B 实验数据是否具有统计显著性（p < 0.05）
+
+### 3.2 技术指标验证
+
+- [ ] 新增接口性能是否达标
+- [ ] 数据库查询是否有慢查询（> 1s）
+- [ ] 缓存命中率是否正常
+- [ ] 异步任务（队列/定时任务）是否正常消费
+
+### 3.3 数据一致性
+
+- [ ] 新功能产生的数据格式和内容正确
+- [ ] 数据写入路径（DB/ES/缓存）一致性检查
+- [ ] 报表和统计数据是否准确反映新功能数据
+- [ ] 与上下游系统的数据同步是否正常
+
+---
+
+## 阶段四：全量发布
+
+### 4.1 全量发布决策
+
+**决策者**: 产品负责人 + 技术负责人 联合确认
+
+**必须满足的前提条件**:
+- [ ] 灰度期间所有检查项达标
+- [ ] 无未解决的 P0/P1 问题
+- [ ] 数据验证报告确认功能指标达预期
+- [ ] 客服团队已完成培训并准备好 FAQ
+
+### 4.2 全量操作
+
+- [ ] 确认发布时间窗口（建议工作日上午 10:00-11:00）
+- [ ] Feature Flag 切换到 100%
+- [ ] 全量后 2 小时内密切监控核心指标
+- [ ] 确认无异常后通知相关团队"全量发布完成"
+
+### 4.3 全量后观察（48 小时）
+
+- [ ] 持续监控核心业务指标（日报频率）
+- [ ] 关注客诉渠道是否有新增反馈
+- [ ] 观察系统资源使用趋势（是否有缓慢增长）
+- [ ] 确认数据报表和统计正确
+
+---
+
+## 阶段五：上线复盘（全量后 1 周内）
+
+### 5.1 复盘会议议程
+
+```
+1. 功能概述和目标回顾             (5 min)
+2. 上线过程回顾（时间线/灰度/问题）  (15 min)
+3. 数据结果 vs 预期目标             (10 min)
+4. 问题和经验总结                   (15 min)
+5. 后续优化计划                     (10 min)
+```
+
+### 5.2 复盘文档模板
+
+```markdown
+## 功能名称: ___
+## 上线日期: ___
+## 负责人: ___
+
+### 目标达成情况
+| 指标 | 目标值 | 实际值 | 达标 |
+|------|--------|--------|------|
+
+### 上线过程中的问题
+| 问题 | 影响 | 处理方式 | 改进建议 |
+|------|------|----------|----------|
+
+### 经验总结（做得好的 / 需要改进的）
+### 后续优化 Backlog
+```
+
+### 5.3 清理工作
+
+- [ ] Feature Flag 代码清理（全量稳定 2 周后）
+- [ ] 临时监控告警调整为长期告警
+- [ ] 文档更新（用户文档/API 文档/内部 Wiki）
+- [ ] 复盘文档归档
+
+---
+
+## 紧急回滚流程
+
+### 回滚触发条件（满足任一即触发）
+
+- 核心转化率下降 > 10%
+- 接口错误率上升 > 2%
+- P0 级 Bug 影响核心功能
+- 大量用户投诉（30 分钟内 > 10 条）
+
+### 回滚操作
+
+```
+1. Feature Flag 紧急关闭（< 1 分钟）
+2. 确认功能已下线（检查监控）
+3. 通知项目组 + 客服团队
+4. 排查根因并修复
+5. 修复后重新走灰度流程
+```
+
+## Agent Checklist
+
+- [ ] 发布前是否完成功能验收和安全审查
+- [ ] 灰度策略是否分阶段推进（而非一次全量）
+- [ ] 监控 Dashboard 和告警是否在发布前就绪
+- [ ] Feature Flag 紧急关闭是否经过验证
+- [ ] 回滚触发条件和操作步骤是否明确
+- [ ] 全量发布是否有明确的决策人和决策标准
+- [ ] 上线复盘是否在 1 周内完成
+- [ ] Flag 代码清理是否已排入 Backlog