القائمة
产品规划技能。制定产品路线图，拆解OKR到团队和个人，进行版本规划与资源评估。适用于年度/季度规划、团队目标对齐、项目排期等场景。当用户需要制定产品规划、拆解团队目标、评估项目资源时使用此skill。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
季度竞品分析技能。每季度系统化收集市场竞品情报、构建竞争全景图、深度画像竞品、分析市场格局演变、提炼战略洞察，输出完整季度竞品分析报告。适用于产品战略规划、年度路线图制定、投融资汇报、高管决策支持等场景。当用户需要每季度深入了解竞争格局、识别战略机会、形成完整竞品分析报告时使用此 skill。
Git 标准操作流程 SOP，包含 init、add、commit、push、status、log、pull 等常用操作及自动检查验证。使用场景：用户要求执行 git 操作时。
API design specifications. 当用户需要设计 API、讨论 RESTful 规范、设计 GraphQL schema 或制定 API 规范时使用此skill。
Architecture quality assessment. 当用户需要评估架构质量、检查系统性能、分析安全风险或评估可扩展性时使用此skill。
System architecture design. 当用户需要设计系统架构、画架构图、讨论微服务拆分、CQRS、事件驱动、DDD等架构模式时使用此skill。
Code architecture review. 当用户需要评审代码架构、讨论设计模式、检查代码质量或进行代码评审时使用此skill。
| name | pm-beta-product-planning |
| description | 产品规划技能。制定产品路线图，拆解OKR到团队和个人，进行版本规划与资源评估。适用于年度/季度规划、团队目标对齐、项目排期等场景。当用户需要制定产品规划、拆解团队目标、评估项目资源时使用此skill。 |
系统化进行产品路线图制定、OKR拆解、版本规划与资源评估。
产品路线图定义
产品路线图是产品长期发展的战略蓝图，明确"做什么、不做什么、先做什么"。
路线图制定流程
战略对齐 → 目标设定 → 需求池梳理 → 优先级排序 → 路线图输出
三层次规划模型
| 层次 | 时间跨度 | 内容 | 颗粒度 |
|---|---|---|---|
| 战略层 | 1-3年 | 产品愿景、方向、重大里程碑 | 季度/半年 |
| 规划层 | 6-12月 | 功能域、目标、关键项目 | 月度/双月 |
| 执行层 | 1-3月 | 具体功能、版本计划 | 周/版本 |
路线图模板
## 产品路线图 [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应对变化？
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编写规范
【好的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制定
版本规划原则
版本规划 = 用户价值 + 技术可行 + 商业回报 + 竞争需要
版本类型
| 版本类型 | 定义 | 典型周期 | 注意事项 |
|---|---|---|---|
| 大版本 | 重大功能发布，品牌升级 | 季度/半年 | 充分测试，预留buffer |
| 常规版本 | 功能迭代，体验优化 | 2-4周 | 保持节奏，持续交付 |
| 紧急版本 | Bug修复，安全补丁 | 按需 | 尽量控制范围 |
| 实验版本 | A/B测试，灰度发布 | 按需 | 有明确退出机制 |
版本节奏模板
## 版本规划 [月份]
### 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执行情况
- 改进点
版本容量评估
【团队产能估算】
公式：
有效工作日 = 总工作日 × 0.7（去除会议、杂事、buffer）
人均产能 = Story Points/ Sprint（基于历史数据）
团队总产能 = 人均产能 × 人数 × 系数
示例：
团队5人，Sprint 10个工作日
有效工作日 = 10 × 0.7 = 7天/人
历史人均产能 = 10点/Sprint
系数（经验值）= 0.8
团队总产能 = 10 × 5 × 0.8 = 40点
资源评估框架
资源评估 = 人力 + 时间 + 预算 + 技术风险
人力估算方法
1. 功能点估算法（FP）
步骤：
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天
资源评估模板
## 资源评估报告
### 项目基本信息
- 项目名称：
- 负责人：
- 评估日期：
- 需求版本：
### 功能清单
| 功能模块 | 功能点 | 研发工时(天) | 设计工时(天) | 测试工时(天) | 合计 |
|---------|-------|------------|------------|------------|-----|
| 模块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（无法并行）