03-需求管理规范需求收集、评审、拆分、基线、变更控制CMMI必备需求全生命周期一条需求从生到死CMMI3的需求管理不是写个需求文档就完事它要管的是需求从被提出来到被交付验收的全过程。这条链路我们分成五个阶段收集 → 评审 → 拆分 → 基线 → 变更控制 ↓ ↓ ↓ ↓ ↓ 需求池 评审单 任务卡 基线版 变更单每个阶段都有产物每个阶段都有准入准出条件。下面逐一拆解。一、需求收集模板与方法需求来源分类无人售货柜项目的需求来源通常有四类来源典型示例提出人业务方新增商品品类、新增支付渠道运营/商务用户反馈扫码开门慢、退款不到账客服/用户技术债接口重构、固件OTA升级研发合规要求未成年人购物限制、电子发票法务/监管需求收集模板不管来源是哪种统一进需求池每条需求填这几个字段字段说明示例需求ID唯一编号REQ-2026-0042标题一句话说清扫码开门响应时间优化至2秒内来源谁提的用户反馈/运营/技术债优先级P0-P3P1涉及端后端/固件/小程序三端验收标准怎么算做完P502sP953s状态草稿/评审中/已基线/开发中/已验收评审中负责人谁跟进张三工具不挑——飞书多维表格、Jira、甚至Excel都行。关键是所有需求都在这一个池子里别散在微信聊天记录和口头约定里。收集原则一条需求一件事别把优化开门速度和增加退款功能塞进同一条可验收每条需求必须能写出验收标准写不出来说明需求本身没想清楚有优先级没有优先级的需求池等于没有需求池二、需求评审Checklist需求评审不是走形式开个会念一遍文档而是要逐条过评审Checklist评审Checklist□ 1. 需求描述是否清晰无歧义 □ 2. 验收标准是否可测试、可量化 □ 3. 是否明确了涉及的三端后端/固件/小程序 □ 4. 是否识别了依赖关系前置需求、接口依赖 □ 5. 优先级是否合理是否被低估或高估 □ 6. 是否有遗漏的异常场景断网、断电、支付失败 □ 7. 是否影响已有功能回归风险 □ 8. 工作量估算是否在三端可接受范围内评审参与人小团队不用搞全员评审固定三个人就够产品经理主持确认需求合理性和优先级技术负责人后端/嵌入式各一确认技术可行性和工作量测试代表确认验收标准可测评审结论只有三种通过 / 修改后通过 / 驳回。驳回的需求退回需求池标明驳回原因。三、需求拆分颗粒度控制CMMI3不规定你必须拆多细但实践中有个被广泛验证的层级Epic史诗 → Feature特性 → Story用户故事 → Task任务层级定义层级颗粒度示例无人售货柜Epic一个版本级目标智能补货系统Feature一个可交付功能补货任务自动生成Story一个用户可感知的价值柜长在手机上能看到待补货清单Task一个具体开发任务后端开发补货清单查询接口拆分原则Story控制在1-3天工作量超过3天说明拆得太粗往下再拆每个Story有独立的验收标准不能验收的Story不算拆到位三端各拆各的Task同一条Story下后端、固件、小程序各有自己的Task但Story ID共享实操示例以扫码开门响应优化至2秒内这条需求为例Story: 扫码开门响应优化至2秒内REQ-2026-0042 ├── Task-后端: 开门授权接口增加缓存层目标500ms ├── Task-后端: 下发开门指令异步化不阻塞响应 ├── Task-固件: 柜门继电器驱动从串行改为中断驱动 ├── Task-固件: 网络心跳保活减少重连耗时 ├── Task-小程序: 扫码后立即展示正在开门loading态 └── Task-测试: 编写P50/P95延时自动化测试脚本三端任务挂同一个Story状态联动。后端Task没完成Story不能标完成小程序那边就不会误以为可以联调了。四、需求基线建立与冻结什么是基线基线Baseline就是某一时刻需求集合的快照。建立基线意味着“这些需求已经评审通过、拆分完成从现在起进入开发开发期间不允许随意增删改。”基线建立后新增需求走变更流程不能直接塞进当前迭代。基线建立流程1. 迭代规划会确定本迭代需求范围 2. 技术负责人确认拆分完成、工作量可接受 3. 产品经理签字确认小团队可以邮件/飞书审批 4. 标记基线版本号如Baseline-2026S2W3 5. 通知三端开发开始锁定需求基线冻结的意义基线冻结后三端拿到的是同一份需求快照。后端不会说我以为这个需求下迭代做小程序不会说我以为这个需求这版就有——基线就是铁证。五、变更控制CCB流程为什么需要变更控制无人售货柜项目最常见的变更场景运营中途说这个支付渠道这版必须加——需求插入嵌入式发现某固件功能技术上做不到——需求削减客户要求开门逻辑改成先付款后开门——需求修改这些变更如果直接口头传达、直接改代码基线就废了三端版本再次错位。CCBChange Control Board流程CCB就是变更控制委员会小团队不用搞正式委员会产品经理技术负责人两人拍板即可。流程如下1. 变更提出人填写《需求变更申请单》 - 变更内容描述 - 变更原因 - 影响范围涉及哪些端、哪些已有功能 - 紧急程度 2. CCB评审产品技术负责人 - 评估工作量影响 - 评估进度影响 - 评估风险 - 结论批准 / 批准但有条件 / 驳回 / 延期至下迭代 3. 批准后更新需求池 - 原需求状态变更 - 三端Task增删改 - 基线版本号递增如Baseline-2026S2W3-v2 - 通知三端负责人 4. 变更记录归档 - 变更单编号、审批人、时间留存档紧急变更通道生产事故级别的紧急变更可以走先改后补通道技术负责人口头授权立即修改24小时内补提交变更申请单事后复盘纳入度量分析但这条通道一个迭代不超过2次超过说明需求管理本身有问题。无人售货柜需求管理实战示例场景运营提出“用户反馈退款到账太慢希望退款后实时到账。”全流程走一遍Step 1 收集需求ID: REQ-2026-0043 标题: 退款实时到账 来源: 用户反馈 优先级: P1 涉及端: 后端、小程序 验收标准: 用户退款操作后微信支付退款到账时间1分钟 状态: 草稿Step 2 评审评审Checklist第6条——异常场景微信支付退款接口超时怎么办→ 重试3次失败转人工用户已卸载小程序怎么办→ 短信通知评审结论修改后通过。Step 3 拆分Story: 退款实时到账REQ-2026-0043 ├── Task-后端: 接入微信支付实时退款接口替换原异步退款 ├── Task-后端: 退款失败重试机制人工兜底队列 ├── Task-小程序: 退款操作后展示退款处理中状态页 ├── Task-小程序: 退款成功后推送消息通知 └── Task-测试: 退款成功/失败/超时三种场景自动化测试Step 4 基线纳入2026S2W4迭代基线版本号Baseline-2026S2W4三端对齐。Step 5 变更迭代中途运营说还要支持支付宝退款——走CCB变更单编号CHG-2026-0043-01评估后端增加支付宝退款接口工作量2天结论批准基线升级为Baseline-2026S2W4-v2通知三端整个流程跑下来需求从收集到交付全程有记录、有评审、有基线、有变更控制——这就是CMMI3需求管理的轻量落地版。下一篇讲PRD文档怎么标准化让需求管理有据可依。 03-需求管理规范：需求收集、评审、拆分、基线、变更控制（CMMI必备）
03-需求管理规范需求收集、评审、拆分、基线、变更控制CMMI必备需求全生命周期一条需求从生到死CMMI3的需求管理不是写个需求文档就完事它要管的是需求从被提出来到被交付验收的全过程。这条链路我们分成五个阶段收集 → 评审 → 拆分 → 基线 → 变更控制 ↓ ↓ ↓ ↓ ↓ 需求池 评审单 任务卡 基线版 变更单每个阶段都有产物每个阶段都有准入准出条件。下面逐一拆解。一、需求收集模板与方法需求来源分类无人售货柜项目的需求来源通常有四类来源典型示例提出人业务方新增商品品类、新增支付渠道运营/商务用户反馈扫码开门慢、退款不到账客服/用户技术债接口重构、固件OTA升级研发合规要求未成年人购物限制、电子发票法务/监管需求收集模板不管来源是哪种统一进需求池每条需求填这几个字段字段说明示例需求ID唯一编号REQ-2026-0042标题一句话说清扫码开门响应时间优化至2秒内来源谁提的用户反馈/运营/技术债优先级P0-P3P1涉及端后端/固件/小程序三端验收标准怎么算做完P502sP953s状态草稿/评审中/已基线/开发中/已验收评审中负责人谁跟进张三工具不挑——飞书多维表格、Jira、甚至Excel都行。关键是所有需求都在这一个池子里别散在微信聊天记录和口头约定里。收集原则一条需求一件事别把优化开门速度和增加退款功能塞进同一条可验收每条需求必须能写出验收标准写不出来说明需求本身没想清楚有优先级没有优先级的需求池等于没有需求池二、需求评审Checklist需求评审不是走形式开个会念一遍文档而是要逐条过评审Checklist评审Checklist□ 1. 需求描述是否清晰无歧义 □ 2. 验收标准是否可测试、可量化 □ 3. 是否明确了涉及的三端后端/固件/小程序 □ 4. 是否识别了依赖关系前置需求、接口依赖 □ 5. 优先级是否合理是否被低估或高估 □ 6. 是否有遗漏的异常场景断网、断电、支付失败 □ 7. 是否影响已有功能回归风险 □ 8. 工作量估算是否在三端可接受范围内评审参与人小团队不用搞全员评审固定三个人就够产品经理主持确认需求合理性和优先级技术负责人后端/嵌入式各一确认技术可行性和工作量测试代表确认验收标准可测评审结论只有三种通过 / 修改后通过 / 驳回。驳回的需求退回需求池标明驳回原因。三、需求拆分颗粒度控制CMMI3不规定你必须拆多细但实践中有个被广泛验证的层级Epic史诗 → Feature特性 → Story用户故事 → Task任务层级定义层级颗粒度示例无人售货柜Epic一个版本级目标智能补货系统Feature一个可交付功能补货任务自动生成Story一个用户可感知的价值柜长在手机上能看到待补货清单Task一个具体开发任务后端开发补货清单查询接口拆分原则Story控制在1-3天工作量超过3天说明拆得太粗往下再拆每个Story有独立的验收标准不能验收的Story不算拆到位三端各拆各的Task同一条Story下后端、固件、小程序各有自己的Task但Story ID共享实操示例以扫码开门响应优化至2秒内这条需求为例Story: 扫码开门响应优化至2秒内REQ-2026-0042 ├── Task-后端: 开门授权接口增加缓存层目标500ms ├── Task-后端: 下发开门指令异步化不阻塞响应 ├── Task-固件: 柜门继电器驱动从串行改为中断驱动 ├── Task-固件: 网络心跳保活减少重连耗时 ├── Task-小程序: 扫码后立即展示正在开门loading态 └── Task-测试: 编写P50/P95延时自动化测试脚本三端任务挂同一个Story状态联动。后端Task没完成Story不能标完成小程序那边就不会误以为可以联调了。四、需求基线建立与冻结什么是基线基线Baseline就是某一时刻需求集合的快照。建立基线意味着“这些需求已经评审通过、拆分完成从现在起进入开发开发期间不允许随意增删改。”基线建立后新增需求走变更流程不能直接塞进当前迭代。基线建立流程1. 迭代规划会确定本迭代需求范围 2. 技术负责人确认拆分完成、工作量可接受 3. 产品经理签字确认小团队可以邮件/飞书审批 4. 标记基线版本号如Baseline-2026S2W3 5. 通知三端开发开始锁定需求基线冻结的意义基线冻结后三端拿到的是同一份需求快照。后端不会说我以为这个需求下迭代做小程序不会说我以为这个需求这版就有——基线就是铁证。五、变更控制CCB流程为什么需要变更控制无人售货柜项目最常见的变更场景运营中途说这个支付渠道这版必须加——需求插入嵌入式发现某固件功能技术上做不到——需求削减客户要求开门逻辑改成先付款后开门——需求修改这些变更如果直接口头传达、直接改代码基线就废了三端版本再次错位。CCBChange Control Board流程CCB就是变更控制委员会小团队不用搞正式委员会产品经理技术负责人两人拍板即可。流程如下1. 变更提出人填写《需求变更申请单》 - 变更内容描述 - 变更原因 - 影响范围涉及哪些端、哪些已有功能 - 紧急程度 2. CCB评审产品技术负责人 - 评估工作量影响 - 评估进度影响 - 评估风险 - 结论批准 / 批准但有条件 / 驳回 / 延期至下迭代 3. 批准后更新需求池 - 原需求状态变更 - 三端Task增删改 - 基线版本号递增如Baseline-2026S2W3-v2 - 通知三端负责人 4. 变更记录归档 - 变更单编号、审批人、时间留存档紧急变更通道生产事故级别的紧急变更可以走先改后补通道技术负责人口头授权立即修改24小时内补提交变更申请单事后复盘纳入度量分析但这条通道一个迭代不超过2次超过说明需求管理本身有问题。无人售货柜需求管理实战示例场景运营提出“用户反馈退款到账太慢希望退款后实时到账。”全流程走一遍Step 1 收集需求ID: REQ-2026-0043 标题: 退款实时到账 来源: 用户反馈 优先级: P1 涉及端: 后端、小程序 验收标准: 用户退款操作后微信支付退款到账时间1分钟 状态: 草稿Step 2 评审评审Checklist第6条——异常场景微信支付退款接口超时怎么办→ 重试3次失败转人工用户已卸载小程序怎么办→ 短信通知评审结论修改后通过。Step 3 拆分Story: 退款实时到账REQ-2026-0043 ├── Task-后端: 接入微信支付实时退款接口替换原异步退款 ├── Task-后端: 退款失败重试机制人工兜底队列 ├── Task-小程序: 退款操作后展示退款处理中状态页 ├── Task-小程序: 退款成功后推送消息通知 └── Task-测试: 退款成功/失败/超时三种场景自动化测试Step 4 基线纳入2026S2W4迭代基线版本号Baseline-2026S2W4三端对齐。Step 5 变更迭代中途运营说还要支持支付宝退款——走CCB变更单编号CHG-2026-0043-01评估后端增加支付宝退款接口工作量2天结论批准基线升级为Baseline-2026S2W4-v2通知三端整个流程跑下来需求从收集到交付全程有记录、有评审、有基线、有变更控制——这就是CMMI3需求管理的轻量落地版。下一篇讲PRD文档怎么标准化让需求管理有据可依。