上篇聊了项目管理，敏捷还是瀑布取决于项目特点。但不管用什么管理方法，有个环节做不好项目一定出问题——需求分析。很多工程师觉得需求分析是产品经理的活，自己只管实现就好。结果就是产品经理写了句"机器人要能自动避障"，你做了一个基于激光雷达的局部路径规划，交付时客户说他要的是"机器人看到人过来要让到路边等人走过去再走"——这两个东西的实现复杂度差了一个量级。

需求分析的核心挑战是：客户说的和客户真正想要的，往往不是一回事。客户说"要一个自动导航的机器人"，你追问下去会发现他真正需要的是"减少仓库里搬运工的数量"。导航只是解决方案之一，也许一个固定路线的AGV加上简单的磁条导航就够了，根本不需要上SLAM。

需求获取——多问"为什么"

需求获取的第一步不是记录客户说了什么，而是理解客户为什么这么说。

经典的技巧是"五个为什么"——对客户提出的每个需求，连续追问五次"为什么"。举个例子：客户要求"机器人移动速度要达到2米/秒"。为什么？"因为要提高搬运效率"。为什么要2米/秒？"因为人工搬运的速度大概是这个数"。为什么一定要达到人工搬运的速度？"不然老板觉得买机器人不划算"。好，到这里你就明白了——真正的需求不是"2米/秒"，而是"搬运效率要明显优于人工"。也许1.5米/秒但路径更优化的方案，整体效率反而更高。

需求获取的渠道不能只听客户的。要到现场去观察实际操作流程（很多问题是客户自己都没意识到的），要采访一线操作人员（他们的需求和采购经理的需求可能矛盾），要研究竞品是怎么做的（参考已有的解决方案可以减少试错）。

机器人项目的需求获取还有个特殊环节：现场勘测。你的机器人要在什么环境里运行？地面材质、通道宽度、坡度、光照条件、温湿度、有没有电磁干扰——这些环境参数直接决定了技术方案的选择。不勘测就做设计，等于蒙着眼睛开车。

我们团队有一个标准化的现场勘测清单：地面平整度（影响底盘选型）、通道最窄处（决定机器人尺寸上限）、最大坡度（决定电机功率需求）、环境光照变化（影响视觉传感器）、WiFi信号覆盖（决定通信方案）、人流量分布（影响路径规划策略）。每次去客户现场，工程师带着激光测距仪和照相机，把清单上的项目全部记录下来。这些一手数据比客户口头描述的"大概有三米宽"可靠得多——实测可能只有2.6米，你的机器人设计成2.8米宽就过不去了。

用户故事地图（User Story Mapping）在机器人项目中也很实用。横轴是用户的操作流程（开机→选择任务→机器人执行→结果确认→充电），纵轴是每个步骤下的用户故事（"作为操作员，我希望一键启动，这样不需要输入复杂指令"）。这张图能帮你发现需求中的空白——比如你可能发现"机器人执行过程中如果卡住了怎么办"这个场景没有对应的用户故事，那就是需求遗漏。

需求分类——MoSCoW方法

拿到一堆需求后，需要做优先级排序。机器人项目的资源总是有限的，不可能所有需求都满足。

MoSCoW方法是个简单好用的分类框架：Must have（必须有，没有产品不能用）、Should have（应该有，对用户体验影响大）、Could have（可以有，锦上添花）、Won't have（明确不做，这个版本不考虑）。

分类时要注意两点。一是客户经常把所有需求都说成"Must have"，你需要帮他区分——如果这个功能没有，产品还能不能用？能用就不是Must have。二是分类结果要和客户确认，不能工程师自己排。你觉得不重要但客户觉得核心的功能，排错了优先级会导致客户不满意。

技术需求（非功能性需求）也要纳入分类。"系统延迟低于100毫秒"、"连续运行72小时不崩溃"、"支持远程OTA更新"——这些虽然客户不会主动提，但对产品质量至关重要。工程师有责任把技术需求摆到台面上来，和客户一起讨论优先级。

处理冲突需求是需求分析中最考验功力的部分。采购经理说"机器人成本要控制在十万以内"，运营总监说"机器人必须配两个激光雷达保证安全"，技术负责人说"两个激光雷达的数据融合会大幅增加计算量，需要更强的计算平台"——这三个需求互相打架。怎么解？把冲突摆到台面上，用数据说话：两套方案的总成本对比、性能差异、风险差异。让客户在充分了解trade-off的情况下自己做决策，而不是工程师偷偷替客户做选择。

从需求到技术规格——可验证是关键

需求分析的最终产出是技术规格书（Technical Specification）。它和客户需求的最大区别是：每条技术规格都是可验证的。

客户说"机器人要能搬很重的东西"，这不是技术规格。"机器人额定负载50公斤，在满载情况下最大移动速度不低于1.0米/秒，续航不低于8小时"——这才是技术规格。可测量、可验证、没有歧义。

写技术规格有个模板：功能描述+性能指标+约束条件+验证方法。每条规格都要能回答"怎么测"的问题。如果答不上来，说明这条规格写得还不够清晰。

需求ID: REQ-NAV-003
描述: 机器人应能在仓库环境中自主导航到目标位置
性能指标: 
  - 定位精度: ±5cm (在已建地图环境中)
  - 导航成功率: ≥99.5% (目标点在可行走区域内)
  - 路径效率: 实际路径长度/直线距离 ≤1.3
约束条件:
  - 通道宽度不低于1.2米
  - 地面为环氧漆或混凝土，坡度≤3%
验证方法: 在测试仓库中执行100次导航任务，统计成功率

需求变更管理——不能随意改

项目进行中客户要改需求，这是常态。但需求变更不能随便接受，也不能随便拒绝。需要一个变更控制流程：

变更提出→影响评估（改这个需求会影响哪些模块？工作量多少？工期影响？）→变更评审（各方确认影响后可接受）→变更批准→更新规格书和计划。

关键步骤是影响评估。很多团队跳过这一步直接答应客户"可以改"，结果改完发现影响了其他三个功能，又得继续改，陷入无休止的返工。

需求追溯矩阵（Traceability Matrix）是管理需求变更的利器。它是一个表格，横轴是需求ID，纵轴是设计文档、代码模块、测试用例。每条需求对应了哪些设计、哪些代码、哪些测试，一目了然。客户要改一条需求，你马上能从矩阵里看到会影响多少东西。没有追溯矩阵的团队，需求变更的影响评估全靠人脑记忆——人脑记忆的可靠性大家都知道。

我们团队的实践经验是：每次Sprint开始前，花半小时检查需求追溯矩阵。看看上一轮迭代新增的代码有没有关联到需求，有没有需求对应了设计但没有对应测试用例的情况。这个检查虽然花时间，但能提前发现"需求写了但没人做"或者"做了但没测"的问题。

面试追问

"你怎么处理客户提出的模糊需求？"追问和量化。客户说'机器人要快'，我就问'快到什么程度？比现在快多少？有没有参考数值？'。把模糊的定性描述变成可测量的定量指标。如果客户自己说不清楚，就做一个原型让他体验，通过体验来明确需求。

"需求和技术方案的关系怎么处理？"需求先行，方案后选。先搞清楚'要做什么'，再决定'怎么做'。最忌讳的是客户还没说清楚需求，工程师已经开始选方案了——这样很容易做出技术上很酷但客户不需要的东西。

"你们的需求文档用什么格式？"我们用模板化的需求规格书，每条需求有唯一ID、描述、优先级、验收标准、关联的上下游需求。需求管理工具用Jira或者Confluence，方便追踪需求状态和变更历史。小项目用Excel也行，关键是每条需求都要可追溯。

---

需求分析是技术团队和客户之间的翻译器。翻译得准，后面的设计、开发、测试全顺。翻译得歪，每一步都在纠错。很多机器人项目失败的根因不是技术问题，而是从一开始就没搞清楚到底要做什么。

工程师参与需求分析不是越俎代庖，而是对自己工作的负责。你理解了需求背后的"为什么"，做出来的技术方案才不会跑偏。而且能参与需求分析的工程师，在团队里的话语权会比只做实现的工程师大很多——因为你掌握了"做什么"的决策权，而不只是"怎么做"的执行权。

下一篇聊系统设计方法论，重点讲V模型在机器人开发中的应用。V模型是连接需求和验证的桥梁，在安全关键的机器人项目中尤其重要。

---

如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。 你的支持是我持续更新的最大动力。

「机器人软件开发面试·从入门到精通」连载系列 

上一篇：第336篇 项目管理基础——机器人项目的敏捷/瀑布选型

下一篇预告：第338篇 系统设计方法论——V模型在机器人开发中的应用

有任何问题欢迎评论区留言，我会尽量回复。