上篇聊了系统监控与运维机器人部署后需要持续监控和更新。今天换个视角聊项目管理。很多工程师觉得项目管理是项目经理的事和自己无关。这个想法很危险——你不了解项目管理的基本方法论就无法理解为什么团队要做某些决策、为什么有些看似低效的流程不能省。面试时如果被问到你怎么看待项目管理回答我只管写代码会让面试官觉得你缺乏全局视野。机器人项目的复杂度在几个方面软硬件耦合软件改了可能需要重新标定硬件、多模块并行感知、控制、导航同时开发、测试依赖真机模拟环境和真实环境总有差异。这些特点决定了机器人项目不能简单套用纯软件的项目管理方法需要做一些适配。瀑布模型——不是洪水猛兽很多人一提瀑布模型就摇头觉得它过时了。但瀑布模型在机器人项目中有不可替代的价值。瀑布模型的核心是阶段化需求分析→系统设计→详细设计→编码实现→集成测试→系统测试→验收。每个阶段有明确的输入和输出上一阶段的输出是下一阶段的输入。它最大的优势是过程可追溯——每个决策都有文档记录出了问题能回溯到哪个阶段出的差错。机器人项目中和安全相关的部分几乎必须用瀑布模型。ISO 13849功能安全标准要求的V模型开发流程后面会专门聊本质上就是瀑布的变体。你不能说安全机制我们用敏捷的方式迭代着来——安全设计必须在开发前确定安全验证必须覆盖所有预定义的故障场景。瀑布模型的缺点也很明显需求变更的代价很大。到了编码阶段才发现设计有问题需要回退到设计阶段重新来时间和人力成本都很高。所以瀑布适合需求明确、变更较少的项目——比如量产阶段的工业机器人产品规格已经冻结主要工作是把软件做出来并通过认证。敏捷开发——快但有纪律敏捷开发的核心思想是小步快跑把大项目拆成小迭代Sprint每个Sprint交付一个可用的增量根据反馈调整下一个Sprint的方向。最常用的框架是Scrum——每日站会、Sprint计划会、Sprint评审会、Sprint回顾会。敏捷在机器人项目的软件开发部分效果不错。感知算法的迭代、UI界面的优化、云端服务的功能开发——这些模块的需求经常变化用两周一迭代的节奏能快速响应需求变化。我们团队的感知模块就是纯敏捷每个Sprint做一个小改进在数据集上跑测试验证效果效果好了合入主分支。但敏捷在机器人项目中有几个天然的挑战硬件迭代跟不上软件的节奏。软件两周一个Sprint硬件改版可能要两三个月。你的代码写好了硬件还没到没法做真机测试。所以涉及软硬件联调的部分不能纯粹按Sprint节奏来。集成测试的时间被压缩了。敏捷鼓励每个Sprint交付可用增量但机器人的集成测试需要把感知、导航、控制全跑起来在真机上验证这个过程本身就可能需要一周。如果每个Sprint都做完整集成测试开发效率会大打折扣。安全相关的开发不适合敏捷。前面说了安全设计需要前置不能迭代着来。还有个容易被忽视的问题敏捷要求团队成员高度参与各种会议站会、计划会、评审会、回顾会这对机器人团队意味着什么算法工程师正在调一个很复杂的标定参数思路刚好理顺被叫去开站会——回来后思路断了又得花二十分钟进入状态。所以机器人团队的站会建议控制在十分钟以内并且尽量安排在上午的固定时间点让工程师能规划好不被打断的工作时间段。Sprint评审会在机器人团队里有特殊的做法不只是看PPT和Demo要做真机演示。算法团队在数据集上跑出的指标再好客户关心的是机器人在我的仓库里能不能跑起来。所以每个Sprint的评审环节至少要有一个真机演示的环节让产品经理和客户看到真实的运行效果。混合模型——大多数团队的真实选择实际上大多数成熟的机器人团队用的是混合模型项目层面用瀑布做整体规划模块层面用敏捷做迭代开发安全相关部分用V模型做严格验证。具体来说项目启动时做完整的需求分析和系统设计瀑布确定整体架构、接口规范和安全要求。然后各模块团队用Scrum做迭代开发敏捷每个Sprint交付模块级别的增量。关键里程碑节点做全系统集成测试。安全相关模块走独立的V模型开发流程有自己的评审和验证节点。这种混合模型的关键是接口管理。各模块可以独立迭代但接口不能随便改。接口变更必须走变更控制流程——提申请、评估影响、各方确认、更新文档。没有接口管理的敏捷在机器人项目里就是灾难你改了导航模块的输出格式控制模块没跟着改机器人就开始画蛇。# Sprint计划中典型的任务拆分 sprint_goal: 实现在动态环境中的自适应导航 tasks: - name: 动态障碍物检测接口 module: perception story_points: 5 safety_related: false - name: 局部路径重规划算法 module: navigation story_points: 8 safety_related: false - name: 安全速度限制器 module: control story_points: 3 safety_related: true # 走V模型流程项目估时——机器人项目为什么总延期机器人项目延期几乎是常态。原因很具体硬件到货延迟、真机调试时间被低估、传感器在不同环境下表现不一致、软硬件联调发现的问题比预期多。怎么让估时更准确几个经验法则参考历史数据。上次做一个类似功能的导航模块花了多久把那个数字拿出来作为基准再根据这次的复杂度差异做调整。没有历史数据的项目估时误差通常在2到3倍。把大任务拆小。一个实现SLAM系统的任务没法估时拆成激光雷达驱动适配、里程计融合、回环检测、地图保存就清楚多了。每个子任务估时再求和比整体估一个数字靠谱。给不确定性留缓冲。硬件相关的任务额外加30%的缓冲时间涉及新算法研究的任务额外加50%。这不是注水而是对不确定性的合理尊重。识别和管理依赖关系也至关重要。机器人项目的依赖链很长硬件选型确定后才能写驱动驱动写好后才能做传感器融合融合做完后才能调算法。如果这些依赖都串行等待项目周期会非常长。实际做法是用模拟数据先开发上层算法等硬件就绪后再做真机适配。同时在项目计划里标出关键路径——关键路径上的任务延一天整个项目就延一天。项目经理的精力应该重点放在关键路径的任务上。风险登记本是个好用的工具。项目启动时团队一起头脑风暴列出所有能想到的风险供应商倒闭怎么办核心成员离职怎么办客户改需求怎么办评估每个风险的发生概率和影响程度为高风险项提前制定应对方案。这不是走过场——我见过一个项目因为没提前考虑传感器供应商停产的风险临时换传感器整个感知模块重做了两个月。面试追问你们用敏捷还是瀑布混合模型。项目整体用瀑布做阶段化管理每个阶段有明确的里程碑和交付物。模块级别的开发用Scrum两周一迭代。安全相关模块走V模型。这种混合方式在机器人行业比较常见。怎么处理需求变更分情况。UI层面、参数层面的变更在Sprint评审会上提出评估工作量后放入下一个Sprint。涉及接口变更的需求走变更控制流程需要架构师和相关模块负责人评审。涉及安全相关功能的变更必须重新做风险评估。Sprint回顾会你们怎么做每次Sprint结束后开一小时。前半段回顾这个Sprint做了什么、哪些没做完、为什么没做完。后半段讨论流程改进——哪些做法效果好要继续保持哪些做法有问题需要调整。关键是回顾出来的改进项要真正落地不能说完就忘。项目管理不是束缚创造力的枷锁而是让团队高效协作的框架。没有项目管理十个人的团队可能各干各的代码互相冲突接口对不上最后集成时全是问题。好的项目管理让你把精力集中在真正重要的技术问题上而不是浪费在协调和返工上。机器人项目的管理比纯软件难因为多了硬件这个维度。但核心思路是一样的明确目标、拆解任务、管理依赖、控制风险。理解了这些基本原理不管你在哪个团队都能更快地适应和融入。下一篇聊需求分析。再好的技术方案如果解决的不是真正的需求就是浪费。从客户的模糊想法到清晰的技术规格这个过程比写代码更有挑战性。如果这篇文章对你有帮助欢迎点赞、在看、转发三连。 你的支持是我持续更新的最大动力。「机器人软件开发面试·从入门到精通」连载系列上一篇第335篇 系统监控与运维——日志/告警/远程更新的方案设计下一篇预告第337篇 需求分析——从客户需求到技术规格的方法有任何问题欢迎评论区留言我会尽量回复。