输入与输出

输入：业务方、客户方的反馈

过程活动：维护需求池

参与者：产品负责人（产品总监）

输出：调整排序后的需求池（可以简化为一个Excel表格）

干货

在我们的团队，负责维护需求池的是产品总监，而不是某个产品经理。

产品经理从需求池中按优先级选择出某个需求来向下推进。

如何维护需求池

以下是一个 产品列表（Product Backlog）的示例，包含常见的格式和内容，供你参考和学习：

产品需求列表（Product Backlog）示例

项目名称：在线教育平台
产品负责人：张三
版本：V1.2（2024年Q2迭代）

ID	用户故事/需求	优先级	估算（故事点）	状态	备注
PB001	作为学生，我希望能够通过关键词搜索课程，以便快速找到感兴趣的内容。	高（Must）	5	待开发	需支持模糊搜索
PB002	作为教师，我需要上传课程视频并设置章节分类，以便学生按顺序学习。	高（Must）	8	开发中	支持MP4格式，最大2GB
PB003	作为用户，我希望注册时通过手机验证码登录，简化注册流程。	中（Should）	3	已完成	已集成第三方短信服务
PB004	作为管理员，我需要统计课程访问量和用户活跃度，以便优化运营策略。	低（Could）	13	待开发	需设计可视化报表
PB005	技术任务：重构课程推荐算法以提高性能（当前算法响应时间超过1秒）。	高（Must）	5	待开发	技术债务，需优先解决
PB006	缺陷修复：用户支付成功后偶尔未跳转到课程页面（重现概率约10%）。	高（Must）	2	已排期	需排查支付回调接口问题
PB007	作为用户，我希望在个人中心查看学习进度和完成证书。	中（Should）	8	待开发	需设计证书模板

产品列表关键要素说明：

1. ID：唯一标识符，便于跟踪和讨论（如PB001）。

2. 用户故事/需求：

   • 格式：作为[角色]，我希望[目标]，以便[价值]（符合用户故事模板）。
   • 内容：功能需求、技术任务、缺陷修复等均需纳入列表。

3. 优先级：

   • 常用 MoSCoW法则 划分（Must/Should/Could/Won’t）或数字（1-5）。
   • 动态调整：例如PB005技术债务可能因系统性能问题临时提高优先级。

4. 估算：

   • 通常用 故事点（Story Points）表示复杂度，而非具体工时（如斐波那契数列：1,2,3,5,8…）。 也可使用“大、中、小”。

5. 状态：

   • 标明当前进展（待开发/开发中/已完成/已验收）。

6. 备注：

   • 补充关键细节（如技术限制、依赖项、外部接口等）。

产品列表的动态性示例：

假设在迭代评审会上，团队收到用户反馈并调整列表：

1. 新增需求：

   • PB008：作为用户，我希望课程支持离线下载，以便在地铁等网络差的环境学习。（优先级：高）

2. 调整优先级：

   • PB007（学习证书）因客户需求变化降为低优先级。

3. 拆分细化：

   • PB002（上传课程）拆分为：

     • PB002a：上传视频基础功能（优先级高）
     • PB002b：章节拖拽排序功能（优先级中）

提示：

• 颗粒度控制：顶层条目较粗，进入迭代前需细化成具体任务（Sprint Backlog）。
• 协作维护：产品负责人主导优先级，但需与团队和利益相关者讨论。
• 可视化工具：可用Jira、Trello或Excel管理，核心是保持透明和可更新性。
• 每周至少与团队Review一次需求优先级
• 技术债务单独建立子列表维护
• 不可将用户故事写成技术方案（如：“开发Redis缓存模块”）

关于估算工作量（故事点）

在Scrum和敏捷开发中，故事点（Story Points） 是一个抽象的相对估算单位，没有固定的物理单位（如小时、天数）。它的核心目的是通过团队协作，对比不同任务的复杂度、工作量和风险，而非直接关联具体时间。以下是详细解释：

1. 故事点的本质

• 相对性：通过比较任务间的复杂度（如“任务A大约是任务B的2倍工作量”）。
• 多维因素：综合评估开发任务的复杂度、不确定性、技术难度和协作成本。
• 团队独特性：不同团队对故事点的基准定义可能不同（例如，团队A的1个故事点 ≠ 团队B的1个故事点）。

2. 常见的故事点单位表示

团队通常使用 非线性数列（如斐波那契数列）来估算，避免陷入“精确时间”的误区：
1, 2, 3, 5, 8, 13, 20…

• 为什么用非线性数列？

  • 任务复杂度越高，不确定性越大，精确估算越难。
  • 避免团队纠结于微小差异（例如区分“6点”和“7点”无意义）。

• 有些团队也会用 T-shirt尺码（XS, S, M, L, XL）作为替代。

3. 如何确定故事点的基准？

团队需先定义一个 基准任务（Reference Story）：

• 例如：“一个简单的登录页面开发” = 1个故事点。

• 其他任务与此基准对比：

  • 若某个任务复杂度是基准的5倍，则估算为 5个故事点。
  • 若任务模糊或风险高（如涉及未知技术），可能直接定为 13点。

4. 故事点与时间的关系

• 故事点 ≠ 时间：1个故事点不直接对应具体工时，但团队可通过历史数据计算 速率（Velocity）（例如：平均每迭代完成30个故事点）。
• 长期预测：根据速率，可估算未来迭代能完成的工作量（如“下个迭代约处理25-35点”）。
• 团队自组织：故事点帮助团队关注“相对工作量”，而非被“承诺工时”束缚。

5. 故事点的实际应用示例

假设团队基准任务是 “用户注册页面开发”（1点）：

任务	复杂度对比	故事点
登录页面开发	与基准相当	1
课程搜索功能	复杂度是基准的3倍	3
支付系统集成	涉及第三方API，风险高	8

6. 为什么不用“小时”直接估算？

• 主观偏差：不同开发者对同一任务的时间估算差异极大（新手 vs 资深工程师）。
• 压力与焦虑：精确到小时的估算容易让团队陷入“完不成计划”的挫败感。
• 灵活性：故事点更适应需求变更和技术不确定性。

模板

需要模板的读者，请下载附件集中的模板。

产品需求池示例（电商平台）模板

当前版本： V2.3   维护人： 张伟（产品负责人）
最后更新时间： 2023-08-20 总条目数： 37  冲刺周期： 2周

优先级	用户故事（User Story）	业务价值	估算（故事点）	备注	状态
P0	作为买家，我希望在商品页面看到库存数量，以便判断能否立即下单	高	5	- 移动端/PC端显存标识 - 库存≤5时显示“仅剩X件” - 接口响应<500ms	Ready
P1	作为商家，我需要批量上传商品信息，以提高运营效率	高	8	- 支持CSV文件导入 - 错误数据自动生成报告 - 单次处理≤500条	原型中
P2	作为用户，希望使用Google账号直接登录，降低注册门槛	中	3	- 授权流程符合OAuth 2.0协议 - 新用户自动补充默认头像	待细化
P3	作为客服主管，需要查看每日退货原因统计，以优化售后服务	低	13	- 按时间筛选退货数据集 - 生成环形图/柱状图 - 支持Excel导出	待拆分