背景
公司目前存在的问题:
- 团队产出无法量化考核指标,绩效考核不公平导致团队效率低下,凝聚力不足
- 产品需求质量不高导致研发反复返工
针对公司的问题设计了一套相当完整的敏捷开发流程,重点在于以下三个制度的联动:
- 需求池管理
- 故事点评估(故事点与工时脱钩,用计划扑克避免羊群效应)
- 绩效考核(记录需求驳回次数作为产品考核)。
1 | graph TD |
需求池管理与Scrum团队协作制度
目标:建立透明高效的需求流转机制,平衡产品创新与研发效率,量化团队效能
一、需求池管理规则
入口标准
- 产品经理通过标准化模板提交需求(含业务目标、用户场景、原型/逻辑说明)
- 强制字段:
业务优先级(P0-P3)
、预期价值
、关联业务模块
优先级排序
- 动态调整机制:每周由产品负责人(PO)根据市场变化刷新需求优先级排序
- 紧急通道:<10%的需求可标注
紧急插入
(需CTO联签说明)
需求驳回机制
- 驳回条件:
- 逻辑矛盾(与已有功能冲突)
- 技术不可实现(当前架构限制)
- 需求描述不完整(关键流程缺失)
- 考核指标:
- 产品经理季度驳回率 =
被驳回需求数/总提交需求数
(警戒线≥15%)
- 产品经理季度驳回率 =
- 驳回条件:
二、迭代规划流程
(1)需求评审会(每周期1次,时长≤4小时)
环节 | 执行动作 | 输出物 |
---|---|---|
需求讲解 | 产品逐条说明需求场景与技术边界 | 需求确认清单 |
故事点评估 | 全员使用计划扑克(Fibonacci数列:1,2,3,5,8…) | 带共识故事点的需求列表 |
任务拆分 | 前后端协作拆解技术任务(API/组件/数据模型) | 任务树状图 |
计划扑克执行要点:
- 每轮评估后差异≥3点需辩论(例:A说8点,B说3点 → A陈述技术风险,B提出简化方案)
- 强制规则:必须达成全员共识(禁止平均取值)
(2)迭代承诺
- 计算团队产能基准:
基准故事点 = 近3次迭代平均完成点 × 70%
(预留30%缓冲) - 扣减因子:
成员请假天数 × 0.5故事点/人/日
- 输出:
本期承诺需求清单
+总故事点范围
(如:85-92点)
三、迭代执行监控
环节 | 规则 |
---|---|
任务认领 | 研发每日站会自主领取任务(禁止分配),需标注预估工时 (精确到0.5天) |
故事点膨胀 | 开发中新增未评估复杂度 → 即时标记风险点 ,在每日站会同步 |
变更控制 | 迭代开始后禁止新增需求(紧急需求需消耗团队故事点储备池 ) |
四、迭代回顾会(核心数据闭环)
故事点重估
- 对实际完成需求重新打牌评估故事点
- 若
实际点 > 原始点
,责任研发说明膨胀原因(如:未预见的兼容性问题) - 记录:
需求ID | 原始点 | 重估点 | 膨胀原因
效能数据采集
指标 计算方式 用途 个人完成故事点 ∑(认领需求重估故事点) 产能基线 个人工时效率 ∑任务实际工时 / ∑任务预估工时 计划能力评估(目标0.9-1.1) 缺陷密度 本期产生BUG数 / 个人完成故事点 质量系数(警戒线≥0.5个/点)
五、绩效考核关联设计
六、风险控制清单
故事点通胀预防
- 建立
复杂度对照库
(例:简单CRUD=3点,跨系统集成=8点) - ScrumMaster每月审计重估需求膨胀原因TOP3
- 建立
防止考核扭曲
- 故事点上限封顶(个人单迭代≤35点,避免超负荷承诺)
- 剔除无效故事点(如:因产品变更导致的需求作废)
这套制度实现了你要求的「需求闭环管理」+「量化效能」+「双向考核」,既保障研发话语权,又倒逼产品提升需求质量。