上篇聊了系统监控与运维，机器人部署后需要持续监控和更新。今天换个视角，聊项目管理。很多工程师觉得项目管理是项目经理的事，和自己无关。这个想法很危险——你不了解项目管理的基本方法论，就无法理解为什么团队要做某些决策、为什么有些看似低效的流程不能省。面试时如果被问到"你怎么看待项目管理"，回答"我只管写代码"会让面试官觉得你缺乏全局视野。

机器人项目的复杂度在几个方面：软硬件耦合（软件改了可能需要重新标定硬件）、多模块并行（感知、控制、导航同时开发）、测试依赖真机（模拟环境和真实环境总有差异）。这些特点决定了机器人项目不能简单套用纯软件的项目管理方法，需要做一些适配。

瀑布模型——不是洪水猛兽

很多人一提瀑布模型就摇头，觉得它"过时了"。但瀑布模型在机器人项目中有不可替代的价值。

瀑布模型的核心是阶段化：需求分析→系统设计→详细设计→编码实现→集成测试→系统测试→验收。每个阶段有明确的输入和输出，上一阶段的输出是下一阶段的输入。它最大的优势是过程可追溯——每个决策都有文档记录，出了问题能回溯到哪个阶段出的差错。

机器人项目中，和安全相关的部分几乎必须用瀑布模型。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篇 需求分析——从客户需求到技术规格的方法

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