第1章 机器人原型说明的价值
1.1 为什么需要原型说明?
在机器人产品开发中,一个清晰、结构化的原型说明是连接产品经理、研发、测试和验收的关键纽带。它不仅仅是一份文档,更是团队共同的语言和约定。本章围绕“用户场景→业务问题→用户访谈→需求拆解→方案表达→指标验证→验收标准→交付物模板”的课程主线,阐明原型说明在四个核心维度上的不可替代价值。
📌 核心观点:原型说明不是“写出来”的,而是“协作出来”的。它的价值只有在被团队真实使用时才能体现。
1.2 用户场景:谁在用原型说明?
| 角色 | 典型场景 | 使用原型说明的目的 |
|---|---|---|
| 产品经理 | 向研发阐述机器人功能逻辑 | 确保需求被正确理解 |
| 硬件工程师 | 确认传感器布局与机械结构 | 对齐物理实现边界 |
| 嵌入式开发 | 定义控制接口与通信协议 | 明确状态机与数据流 |
| 测试工程师 | 设计功能与可靠性测试用例 | 获得可量化的测试基准 |
| 项目验收方 | 检查交付物是否满足合同要求 | 提供客观的验收依据 |
1.3 业务问题:没有原型说明的混乱
- 需求歧义:口头沟通导致“我以为”和“你以为”不一致,研发返工率高达40%+。
- 测试无基准:测试人员凭经验判断“正确行为”,同一功能在不同版本中出现冲突判定。
- 验收扯皮:客户或内部评审时无法证明“完成了什么”,陷入无休止的修正循环。
- 知识流失:人员变动后,新成员需要重新探索整个机器人逻辑,成本高昂。
1.4 用户访谈聚焦:原型说明的四大价值
通过对20+机器人项目的产品经理、研发和测试负责人进行访谈,我们归纳出原型说明必须解决的四个核心价值:产品协同、研发对齐、测试基准、验收依据。它们构成了原型说明的“价值四象限”。
1.5 价值详解:从问题到方案
价值一:产品协同
解决的问题:产品、设计、市场、项目管理等多角色对机器人功能理解的碎片化。
用户访谈案例:扫地机器人项目初期,产品经理口头描述“沿墙清扫”逻辑,结构工程师设计了错误的轮子布局,导致样机无法贴墙。痛点过后,团队开始编写原型说明,明确“沿墙距离阈值5cm,触发姿态调整”。
如何实现:通过结构化场景描述(用户场景卡)和业务问题拆解表,将每个需求与真实使用场景绑定。
价值二:研发对齐
解决的问题:硬件、嵌入式、算法、云端开发各自采用不同的接口约定,集成时频繁冲突。
需求拆解示例:机器人避障模块的原型说明中需定义:
输入:激光雷达点云(频率10Hz,范围0.2-12m)
输出:避障转向角度(-30°~+30°,精度1°)
触发条件:前方障碍物距离 < 0.5m
状态机:IDLE → AVOIDING → RECOVER → IDLE
方案表达工具:状态机图、接口定义表、时序图。
价值三:测试基准
解决的问题:测试人员无法判断机器人行为是否正确,因为缺乏明确的“预期结果”。
指标验证例子:原型说明中必须包含可量化的验收指标,如:
指标名称:紧急制动响应时间
目标值:≤ 200ms
测量条件:机器人以0.8m/s直行,前方1m处放置障碍物
通过标准:连续10次测试,成功率100%
测试基准交付物:测试用例模板、指标清单。
价值四:验收依据
解决的问题:项目结项时,客户或管理层不清楚“到底完成了哪些功能”,导致反复修改。
验收标准模板:
功能模块:自主充电
验收项:
1. 机器人剩余电量低于20%时,自动导航至充电座
2. 对接成功指示灯亮起(LED绿色)
3. 充电电流 ≥ 2A
4. 充电完成自动退出并继续任务
检查人:______ 日期:______ 结果:☐ 通过 ☐ 不通过
💡 关键交付物模板:原型说明文档应包含:
① 版本与变更记录|② 用户场景列表|③ 需求拆解表(功能/非功能)|④ 方案表达图(状态机、接口表)|⑤ 指标验证矩阵|⑥ 验收检查清单。
① 版本与变更记录|② 用户场景列表|③ 需求拆解表(功能/非功能)|④ 方案表达图(状态机、接口表)|⑤ 指标验证矩阵|⑥ 验收检查清单。