第二章：项目生命周期模型——瀑布与敏捷在自动化项目中的实战选择

聊到项目生命周期模型，很多刚入行的朋友会问我：「到底选瀑布还是选敏捷？」

我的回答通常是：别急着站队，先看看你的自动化项目到底长什么样。

做了十几年流程自动化项目，我见过太多「瀑布翻车」和「敏捷跑偏」的案例。今天咱们就掰开揉碎，把这两个模型在自动化项目里的适用性、混合玩法，以及阶段划分和里程碑设定，一次性讲清楚。

2.1 瀑布模型：什么时候该「按部就班」？

瀑布模型，说白了就是「先画图纸，再盖房子」。需求、设计、开发、测试、部署，一个阶段做完才能进下一个。

我个人习惯在以下场景优先考虑瀑布：

• 需求极其稳定——比如合规性自动化，监管要求白纸黑字写死了，不会变
• 技术方案成熟——比如用现成的RPA工具做财务对账，套路大家都懂
• 团队异地协作——我在项目中遇到过跨国团队，时差大，频繁沟通不现实，瀑布反而更可控

瀑布模型的典型阶段划分：

阶段	关键活动	里程碑
需求分析	业务流程梳理、SOP文档编写	需求规格说明书签批
系统设计	架构设计、接口定义、异常处理方案	设计评审通过
开发实现	脚本编写、组件封装、单元测试	代码冻结
系统测试	集成测试、UAT验收、性能压测	测试报告签批
部署上线	灰度发布、生产验证、回滚预案	上线确认单

2.2 敏捷模型：自动化项目也能「小步快跑」？

很多人觉得自动化项目就是「写死脚本」，不适合敏捷。其实不然。

你想想看，如果一个自动化流程涉及多个业务部门的频繁变更，比如电商大促期间的订单处理规则，每周都在调——这时候瀑布就是找死。

敏捷模型在自动化项目中的适用场景：

• 需求频繁变化——比如营销活动自动化，规则每周都在变
• 探索性项目——比如用AI做文档识别，效果好不好得试了才知道
• 小团队、短周期——3-5人的团队，2周一个迭代，快速验证

敏捷模型的迭代节奏：

# 一个典型的2周Sprint
第1-2天：Sprint规划 + 需求澄清
第3-8天：开发 + 每日站会（15分钟）
第9-10天：测试 + 修复
第11天：Sprint评审（演示给业务方看）
第12天：Sprint回顾（团队内部复盘）

2.3 混合模型：我实际项目中最常用的「折中方案」

说实话，纯瀑布或纯敏捷，在真实的自动化项目里都不多见。我大部分项目用的是「瀑布+敏捷」的混合模型。

怎么混？举个例子：

• 整体框架用瀑布——需求调研、架构设计、上线部署这些大节点，按瀑布走
• 开发阶段用敏捷——每个模块内部，2周一个迭代，快速交付

我在一个供应链自动化项目中就是这么干的：

1. 第一阶段（瀑布）：花3周做全流程调研，输出「端到端自动化蓝图」
2. 第二阶段（敏捷）：把蓝图拆成12个模块，每个模块2-3个Sprint完成
3. 第三阶段（瀑布）：最后2周做集成测试和全量上线

2.4 阶段划分与里程碑设定——实战中的「锚点」

不管选哪种模型，阶段划分和里程碑设定都是项目管理的「锚点」。没有锚点，项目就像没舵的船。

我一般把自动化项目分成5个阶段，每个阶段设一个硬性里程碑：

阶段	里程碑名称	通过标准
可行性分析	ROI评估通过	自动化收益 > 投入成本，且技术方案可行
流程设计	流程设计评审	业务方、开发、测试三方签字确认
开发迭代	功能冻结	所有核心功能开发完成，无P0/P1缺陷
测试验证	UAT验收通过	业务方在测试环境跑通全部场景
上线运营	稳定运行30天	无重大故障，自动化率达标

2.5 我的选择框架——一张图帮你决策

最后，分享一个我用了多年的决策框架。遇到新项目，我会问自己三个问题：

1. 需求确定性高吗？（高→瀑布，低→敏捷）
2. 技术方案成熟吗？（成熟→瀑布，探索→敏捷）
3. 团队规模大吗？（大→瀑布，小→敏捷）

三个问题都指向瀑布，那就用瀑布；都指向敏捷，那就用敏捷；有分歧，就用混合模型。

举个例子：

• 需求确定性高（✓瀑布）
• 技术方案成熟（✓瀑布）
• 团队5人（✓敏捷）

结果：2:1，偏向瀑布，但团队小，所以用「瀑布框架+敏捷开发」的混合模型。

下一章，咱们聊聊自动化项目的需求管理——这块才是真正「坑最多」的地方。