2、需求工程化：量产阶段的需求分类与追溯
大家好，我是你们的老朋友。今天咱们聊聊量产阶段的需求工程化。说实话，很多团队在原型阶段需求管理得挺好，一到量产就乱了套。我见过太多项目，量产前夜还在改需求，产线停在那里等软件，那叫一个焦头烂额。
为什么会这样？因为量产阶段的需求，跟研发阶段完全是两码事。研发阶段你可以说「这个功能先做出来看看」，量产阶段不行。量产阶段的需求，必须分类清楚、追溯到位、变更受控。说白了，就是要把需求管得死死的。
2.1 量产阶段的需求分类
我个人习惯把量产阶段的需求分成三类：功能需求、性能需求、安全需求。这三类需求，在量产阶段的优先级和处理方式完全不同。
2.1.1 功能需求
功能需求就是「机器人要能干什么」。比如：
- 扫地功能：沿墙清扫、弓字形清扫、定点清扫
- 拖地功能：水箱出水控制、拖布升降
- 回充功能：自动回充、断点续扫
- APP控制：远程启动、定时清扫、区域禁扫
量产阶段的功能需求，必须是已经冻结的。我遇到过最头疼的事，就是量产前两周，产品经理说「加个新功能吧，很简单」。嗯，简单？一个功能从设计、开发、测试到产线验证，至少一周。两周时间根本不够。
2.1.2 性能需求
性能需求是量产阶段最容易出问题的。为什么？因为性能跟硬件、环境、批次都有关系。比如：
| 性能指标 | 量产要求 | 常见问题 |
|---|---|---|
| 清扫覆盖率 | ≥95% | 不同户型差异大，传感器一致性影响 |
| 单次续航 | ≥120分钟 | 电池批次差异、电机效率波动 |
| 回充成功率 | ≥99% | 红外信号干扰、充电座位置偏差 |
| APP响应时间 | ≤2秒 | 网络延迟、服务器负载 |
性能需求在量产阶段，一定要有明确的「通过/不通过」标准。不能是「差不多就行」。我曾经因为一个「差不多」的续航指标，导致一批货在海外退货率飙升。用户说「你们标称120分钟，我实际只跑了90分钟」，那你说怎么办？
2.1.3 安全需求
安全需求是底线，没得商量。量产阶段的安全需求包括：
- 电气安全：充电过流保护、电池过温保护、短路保护
- 机械安全：防跌落、防卡死、防夹手
- 数据安全：用户隐私保护、通信加密、固件签名
- 功能安全：异常状态下的自动停机、故障诊断
2.2 需求追溯矩阵的建立
需求追溯矩阵，说白了就是一张表，把「需求」和「实现」对应起来。量产阶段，这张表就是你的护身符。
为什么要做追溯矩阵？我举个例子。产线反馈说「某台机器APP连不上」。你怎么查？如果没有追溯矩阵，你得翻需求文档、翻设计文档、翻测试报告，可能还要问开发「这个功能是谁写的」。有了追溯矩阵，你直接查：这个需求对应哪个模块、哪个代码文件、哪个测试用例，一目了然。
追溯矩阵的建立，我建议分三步走：
- 需求编号：每个需求分配唯一ID。比如 FR-001（功能需求）、PR-001（性能需求）、SR-001（安全需求）
- 实现映射：每个需求对应到具体的模块、接口、代码文件、测试用例
- 验证记录：每个需求的验证结果、验证人、验证时间
举个例子：
| 需求ID | 需求描述 | 模块 | 代码文件 | 测试用例 | 验证结果 |
|---|---|---|---|---|---|
| FR-001 | 沿墙清扫功能 | 导航模块 | wall_follow.c | TC-WF-001~010 | 通过 |
| PR-002 | 续航≥120分钟 | 电源管理 | power_mgr.c | TC-PM-001~005 | 通过 |
| SR-003 | 防跌落保护 | 传感器模块 | sensor_cliff.c | TC-SC-001~008 | 通过 |
2.3 需求变更管理流程
量产阶段，需求变更是不可避免的。但变更必须受控。我见过最乱的情况是：产线发现一个问题，工程师直接改代码，改完就上线，连通知都没有。结果另一个工程师也在改同一个文件，两个人改冲突了，产线直接停摆。
所以，量产阶段的需求变更，必须走流程。我建议的流程如下：
- 变更申请：提出变更的人填写变更申请单，说明变更原因、变更内容、影响范围
- 变更评审：由变更控制委员会（CCB）评审。CCB成员包括：项目经理、架构师、测试负责人、产线负责人
- 变更实施：评审通过后，开发人员实施变更。注意：变更必须基于最新基线
- 变更验证：变更完成后，进行回归测试。测试范围包括变更影响的所有模块
- 变更发布：验证通过后，发布到产线。发布前必须通知所有相关人员
这里我分享一个实际案例。有一次，产线反馈说「机器在充电座上频繁重启」。排查后发现是充电电流检测的阈值设置太敏感。这个变更看起来很小，就改一个宏定义。但按照流程，我们走了变更申请、评审、实施、验证、发布。结果在回归测试时发现，这个改动影响了另一个型号的充电逻辑。如果当时直接改，那另一个型号的机器就会出问题。
你看，流程不是摆设。它帮你发现那些「你以为没问题」的问题。
2.4 总结
量产阶段的需求工程化，核心就三件事：
- 分类清楚：功能、性能、安全，三类需求分开管理
- 追溯到位：每个需求都能追溯到实现和验证
- 变更受控：任何变更必须走流程，不能私自改
做到这三点，量产阶段的软件质量就有保障了。嗯，今天就聊到这里。下一章咱们讲讲「量产阶段的配置管理与版本控制」，这个也是量产的大坑，到时候细说。