# Pm Beta Product Planning

> 产品规划技能。制定产品路线图，拆解OKR到团队和个人，进行版本规划与资源评估。适用于年度/季度规划、团队目标对齐、项目排期等场景。当用户需要制定产品规划、拆解团队目标、评估项目资源时使用此skill。

- Skill: `fengqiliu/pm-beta-product-planning` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add fengqiliu/pm-beta-product-planning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fengqiliu/pm-beta-product-planning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: fengqiliu (https://skillmd.com/u/fengqiliu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fengqiliu/pm-beta-product-planning

---


# 产品规划

系统化进行产品路线图制定、OKR拆解、版本规划与资源评估。

## 核心模块

### 1. 路线图制定

**产品路线图定义**

产品路线图是产品长期发展的战略蓝图，明确"做什么、不做什么、先做什么"。

**路线图制定流程**

```
战略对齐 → 目标设定 → 需求池梳理 → 优先级排序 → 路线图输出
```

**三层次规划模型**

| 层次 | 时间跨度 | 内容 | 颗粒度 |
|------|---------|------|--------|
| 战略层 | 1-3年 | 产品愿景、方向、重大里程碑 | 季度/半年 |
| 规划层 | 6-12月 | 功能域、目标、关键项目 | 月度/双月 |
| 执行层 | 1-3月 | 具体功能、版本计划 | 周/版本 |

**路线图模板**

```markdown
## 产品路线图 [2024年度]

### 产品愿景
[一句话描述产品长期目标和方向]

### 战略主题
| 主题 | 目标 | 成功指标 |
|------|------|---------|
| 用户增长 | 扩大用户规模 | DAU从X增长到Y |
| 商业化 | 提升变现能力 | ARPU提升Z% |
| 体验优化 | 提升用户满意度 | NPS从A提升到B |

### Q1 规划
**主题：[季度主题，如：用户激活与留存]**

| 功能 | 类型 | 优先级 | 时间 | 负责人 | 成功指标 |
|------|------|--------|------|--------|---------|
| 新手引导2.0 | 新功能 | P0 | 1月 | 张三 | 留存率提升5% |
| 消息推送优化 | 优化 | P1 | 2月 | 李四 | 召回率提升10% |
| 个人主页改版 | 优化 | P2 | 3月 | 王五 | 个人页渗透率提升 |

### Q2-Q4 规划（方向性）
- Q2：[规划方向]
- Q3：[规划方向]
- Q4：[规划方向]
```

**路线图沟通原则**

- 对上（管理层）：重点讲战略价值和资源需求
- 对平（研发/设计）：重点讲实现路径和依赖关系
- 对外（合作方）：重点讲时间节点和接口约定

**路线图评审检查**

```
[ ] 是否与公司战略目标对齐？
[ ] 是否覆盖核心用户的关键需求？
[ ] 优先级排序是否有明确依据？
[ ] 时间规划是否考虑研发产能？
[ ] 重大风险是否有备选方案？
[ ] 是否预留了buffer应对变化？
```

### 2. OKR拆解

**OKR基础概念**

```
O（Objective）：目标，回答"我们要去哪里"
KR（Key Result）：关键结果，回答"如何衡量是否到达"

O = 定性的方向描述（激发团队热情）
KR = 定量的衡量标准（可评估、可衡量）
```

**OKR vs KPI**

| 维度 | OKR | KPI |
|------|-----|-----|
| 导向 | 目标导向（去哪） | 指标导向（做了什么） |
| 考核 | 不直接关联薪酬 | 直接关联薪酬 |
| 设定 | 挑战性目标（0.6-0.7达成率是理想状态） | 保守可达（100%达成是标准） |
| 数量 | 1-3个O，每个O 2-4个KR | 可以很多 |

**OKR拆解流程**

```
公司OKR → 产品线OKR → 团队OKR → 个人OKR
   ↓           ↓           ↓           ↓
  方向        支撑关系    支撑关系    具体执行
```

**OKR编写规范**

```markdown
【好的OKR特征】
- O：方向清晰、有挑战性、能激发热情
- KR：可量化、有时限、有明确基准和目标值

【常见问题】
- O太空洞 → 应具体到可感知的改变
- KR太抽象 → 应转化为可测量的指标
- 数量过多 → 每个层级不超过3个O
- 与KPI混淆 → OKR关注"做对的事"，KPI关注"把事做对"
```

**OKR拆解示例**

```
【公司OKR】
O：成为细分市场用户满意度第一的产品
KR1：NPS从35提升至50
KR2：用户推荐意愿评分从7.2提升至8.5
KR3：核心功能好评率从70%提升至85%

【产品线OKR】
O：构建让用户惊喜的核心体验
KR1：核心流程转化率从25%提升至40%
KR2：用户问题一次性解决率从60%提升至80%
KR3：新功能采用率从30%提升至50%

【团队OKR - 产品团队】
O：打造行业领先的交互体验
KR1：主流程操作步骤减少30%
KR2：新手引导完成率从50%提升至80%
KR3：用户反馈处理时效从48h缩短至24h

【团队OKR - 研发团队】
O：构建高性能、高可用的技术架构
KR1：核心页面加载时间从3s缩短至1s
KR2：系统可用性从99.5%提升至99.9%
KR3：技术方案评审通过率从70%提升至90%
```

**OKR复盘机制**

```
周检视（每周）
- 本周KR进展如何？
- 是否有偏离目标的风险？
- 需要什么支持？

月复盘（每月）
- KR达成率自评（0-1分）
- 未达成的原因分析
- 下月调整方向

季复盘（每季）
- OKR整体回顾
- 经验总结
- 下季OKR制定
```

### 3. 版本规划

**版本规划原则**

```
版本规划 = 用户价值 + 技术可行 + 商业回报 + 竞争需要
```

**版本类型**

| 版本类型 | 定义 | 典型周期 | 注意事项 |
|---------|------|---------|---------|
| 大版本 | 重大功能发布，品牌升级 | 季度/半年 | 充分测试，预留buffer |
| 常规版本 | 功能迭代，体验优化 | 2-4周 | 保持节奏，持续交付 |
| 紧急版本 | Bug修复，安全补丁 | 按需 | 尽量控制范围 |
| 实验版本 | A/B测试，灰度发布 | 按需 | 有明确退出机制 |

**版本节奏模板**

```markdown
## 版本规划 [月份]

### V3.2.x 常规版本
- 发布时间：[目标日期]
- 负责人：[PM]
- 功能范围：
  - [功能1] - P0，Must Have
  - [功能2] - P1，Should Have
  - [功能3] - P2，Could Have
- 测试重点：[回归范围]
- 发布条件：[门禁标准]

### V3.3.0 大版本（规划中）
- 计划启动：[日期]
- 计划发布：[日期]
- 核心功能：[方向]
- 当前状态：[规划中/设计中/开发中]
```

**版本排期方法**

**敏捷迭代排期**

```
Sprint周期：2周

Sprint Planning（第一天）
- 从Backlog中选取本Sprint要做的Items
- 估算工作量（Story Points）
- 确认交付目标

每日站会（每天）
- 昨天完成了什么
- 今天要做什么
- 有什么阻碍

Sprint Review（最后一天）
- 演示已完成的功能
- 获取反馈

Sprint Retrospective
- 复盘Sprint执行情况
- 改进点
```

**版本容量评估**

```markdown
【团队产能估算】

公式：
有效工作日 = 总工作日 × 0.7（去除会议、杂事、buffer）

人均产能 = Story Points/ Sprint（基于历史数据）
团队总产能 = 人均产能 × 人数 × 系数

示例：
团队5人，Sprint 10个工作日
有效工作日 = 10 × 0.7 = 7天/人
历史人均产能 = 10点/Sprint
系数（经验值）= 0.8
团队总产能 = 10 × 5 × 0.8 = 40点
```

### 4. 资源评估

**资源评估框架**

```
资源评估 = 人力 + 时间 + 预算 + 技术风险
```

**人力估算方法**

**1. 功能点估算法（FP）**

```markdown
步骤：
1. 将功能拆解为独立的功能点
2. 每个功能点根据复杂度分为：简单/中等/复杂
3. 查表得出工时

复杂度工时参考（单人天）：
- 简单页面（CRUD）：0.5-1天
- 中等功能（含逻辑）：1-3天
- 复杂功能（多系统交互）：3-7天
- 重大功能（全新架构）：7-15天

总工时 = Σ(功能点 × 复杂度系数) × 缓冲系数
缓冲系数：1.2（成熟团队）/ 1.5（新手团队）/ 1.8（高风险项目）
```

**2. 类比估算法**

```
参照历史类似项目的实际工时：
项目A（类似功能）开发用了X天
项目B（类似功能）开发用了Y天
本项目预计：取平均值 × 调整系数
```

**3. PERT估算法**

```
乐观时间(O)：一切顺利的情况
最可能时间(M)：正常情况
悲观时间(P)：最坏情况

期望时间 = (O + 4M + P) / 6

示例：
O = 10天，M = 15天，P = 25天
期望时间 = (10 + 60 + 25) / 6 = 15.8天
```

**资源评估模板**

```markdown
## 资源评估报告

### 项目基本信息
- 项目名称：
- 负责人：
- 评估日期：
- 需求版本：

### 功能清单

| 功能模块 | 功能点 | 研发工时(天) | 设计工时(天) | 测试工时(天) | 合计 |
|---------|-------|------------|------------|------------|-----|
| 模块A | 功能1 | 3 | 1 | 1 | 5 |
| 模块A | 功能2 | 2 | 0.5 | 0.5 | 3 |
| 模块B | 功能3 | 5 | 2 | 2 | 9 |
| 小计 | | 10 | 3.5 | 3.5 | 17 |

### 资源汇总
- 研发：10人天 → 需要 2人 × 5天 或 1人 × 10天
- 设计：3.5人天 → 需要 1人 × 4天
- 测试：3.5人天 → 需要 1人 × 4天

### 风险评估
| 风险 | 概率 | 影响 | 应对 |
|------|------|------|------|
| 第三方接口延期 | 中 | 高 | 提前约定接口时间，预留mock |
| 需求变更 | 高 | 中 | 控制变更流程，设置变更窗口 |
| 技术难点 | 低 | 高 | 提前预研，引入专家 |

### 结论
- 总工时：17人天
- 建议周期：3周（含测试和buffer）
- 建议团队：后端2人 + 前端1人 + 设计1人 + 测试1人
- 关键路径：模块B功能3（无法并行）
```

## 输出规范

- 路线图每季度至少Review一次，根据市场变化动态调整
- OKR对齐需确保至少70%的KR能支撑上级O
- 版本规划需提前1个月确认下月范围，提前1周确认发布内容
- 资源评估误差控制在±20%以内为合格