上篇聊了项目管理敏捷还是瀑布取决于项目特点。但不管用什么管理方法有个环节做不好项目一定出问题——需求分析。很多工程师觉得需求分析是产品经理的活自己只管实现就好。结果就是产品经理写了句机器人要能自动避障你做了一个基于激光雷达的局部路径规划交付时客户说他要的是机器人看到人过来要让到路边等人走过去再走——这两个东西的实现复杂度差了一个量级。需求分析的核心挑战是客户说的和客户真正想要的往往不是一回事。客户说要一个自动导航的机器人你追问下去会发现他真正需要的是减少仓库里搬运工的数量。导航只是解决方案之一也许一个固定路线的AGV加上简单的磁条导航就够了根本不需要上SLAM。需求获取——多问为什么需求获取的第一步不是记录客户说了什么而是理解客户为什么这么说。经典的技巧是五个为什么——对客户提出的每个需求连续追问五次为什么。举个例子客户要求机器人移动速度要达到2米/秒。为什么因为要提高搬运效率。为什么要2米/秒因为人工搬运的速度大概是这个数。为什么一定要达到人工搬运的速度不然老板觉得买机器人不划算。好到这里你就明白了——真正的需求不是2米/秒而是搬运效率要明显优于人工。也许1.5米/秒但路径更优化的方案整体效率反而更高。需求获取的渠道不能只听客户的。要到现场去观察实际操作流程很多问题是客户自己都没意识到的要采访一线操作人员他们的需求和采购经理的需求可能矛盾要研究竞品是怎么做的参考已有的解决方案可以减少试错。机器人项目的需求获取还有个特殊环节现场勘测。你的机器人要在什么环境里运行地面材质、通道宽度、坡度、光照条件、温湿度、有没有电磁干扰——这些环境参数直接决定了技术方案的选择。不勘测就做设计等于蒙着眼睛开车。我们团队有一个标准化的现场勘测清单地面平整度影响底盘选型、通道最窄处决定机器人尺寸上限、最大坡度决定电机功率需求、环境光照变化影响视觉传感器、WiFi信号覆盖决定通信方案、人流量分布影响路径规划策略。每次去客户现场工程师带着激光测距仪和照相机把清单上的项目全部记录下来。这些一手数据比客户口头描述的大概有三米宽可靠得多——实测可能只有2.6米你的机器人设计成2.8米宽就过不去了。用户故事地图User Story Mapping在机器人项目中也很实用。横轴是用户的操作流程开机→选择任务→机器人执行→结果确认→充电纵轴是每个步骤下的用户故事作为操作员我希望一键启动这样不需要输入复杂指令。这张图能帮你发现需求中的空白——比如你可能发现机器人执行过程中如果卡住了怎么办这个场景没有对应的用户故事那就是需求遗漏。需求分类——MoSCoW方法拿到一堆需求后需要做优先级排序。机器人项目的资源总是有限的不可能所有需求都满足。MoSCoW方法是个简单好用的分类框架Must have必须有没有产品不能用、Should have应该有对用户体验影响大、Could have可以有锦上添花、Wont 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模型在机器人开发中的应用有任何问题欢迎评论区留言我会尽量回复。