我们用瀑布开发做政府项目，稳了

一、先说结论：政府项目，我赌瀑布，而且几乎每次都赢

我在政务信息化这个领域做了整整九年，经手过大大小小 40 多个项目。有一个判断我坚持到现在，而且越来越坚定：在政府项目里，选择瀑布开发不是技术保守，而是一种基于风险管理的最优解。“稳了”这两个字，从来不是运气，是方法论和治理体系的对齐。

我说得再直接一点：政府项目的核心交付物从来不只是软件，而是确定性。这个确定性里面有工期、有预算、有需求范围、有验收标准、有审计留痕。而瀑布开发，恰恰是天然长在确定性上面的方法论。它不是“老古董”，它是和甲方爸爸的管理体系长在同一个根上的东西。

我见过太多团队，拿着一套主流的敏捷方法论兴冲冲杀进政府项目，结果被现实打肿脸。问题不出在敏捷本身，而出在一个根本性错配：你用一套拥抱变化的方法，去服务一个极度厌恶变化的系统，你能不疼吗？

二、我是怎么意识到“敏捷梦”在政府项目里行不通的

1. 那个差点让我被甲方拉黑的项目

2018 年，我接手一个市级政务协同平台项目。当时我刚从一家互联网公司出来不久，满脑子都是 Scrum、Sprint、用户故事地图，觉得传统瀑布开发太笨重、效率太低。我跟甲方信誓旦旦：“咱们用敏捷，两周一个小版本，随时调整需求，保证您满意。”

前三周一切正常。到第四周，问题来了。

甲方一位处长在 Sprint Review 上提出：“这个公文流转的审批节点逻辑跟我们现行的红头文件要求不一致，得改。”我按敏捷那套爽快地回答：“没问题，下个 Sprint 优先处理。”结果第二天，甲方信息中心一个电话打过来：“你们是不是擅自变更需求了？这个模块的需求规格说明书是上个月局务会讨论通过的，任何变更要走正式流程，不然将来审计我们过不了。”

我不敢再擅自调整 Sprint 了。可甲方处长那边又催：“两周不是你说的吗？怎么又跟我说要走流程？”

这件事发展到最后的结果是：我们被要求在次月的局务会上重新汇报变更方案。一个原本可能在一周内调整完的节点，从发起变更到最终批复，整整走了 48 天。期间 Sprint 停摆，开发团队空转，预算超了 17%，甲方满意度降到冰点。我差点被拉入供应商黑名单。

那次之后我才真正明白一个道理：政府项目的需求变更不是技术行为，是行政行为。

2. 敏捷在政府项目里的四道“死墙”

后来我反复复盘，总结出敏捷在政府项目里撞上的四道死墙。不是说敏捷不好，是这些东西不是方法论能跨越的：

看懂这四道墙，你就知道为什么在政府项目里讲敏捷，结果往往是“听着很美，干着很疼”。所以我后来直接调整策略：与其用敏捷撞墙，不如把瀑布做到极致。

三、拆解三个最深的误解：很多人以为我选瀑布是因为“不懂”

1. 误解一：“瀑布意味着需求要一次写对”

这是对瀑布开发最普遍的误解，也是很多敏捷拥趸最爱攻击的点：“你怎么可能在项目开始前把所有需求都搞清楚？”

我告诉你，我在政府项目里干了九年，确实没有任何一个项目能在需求阶段把需求全部搞定。但重点是：我们追求的不是完美，而是可验证、可签字、可据此作为合同附件的“需求基线”。

在实际操作中，我用的方法是“三阶段确认法”：

• 第一阶段，框架确认：基于可研报告和初步设计，由上而下梳理出功能模块地图，核心目标是确认“要建什么系统、覆盖什么业务”，这块通常能做对 80% 以上的结构。
• 第二阶段，场景穷举：针对核心模块，拉着甲方业务处室的人，一个场景一个场景地走。每个场景必须落到“谁在什么条件下做什么操作，系统应给出什么反馈”这个颗粒度。这个过程通常需要 4-6 轮面对面的工作坊，每轮至少三个整天。
• 第三阶段，原型佐证：用 Axure 做高保真原型，把关键流程全部可视化。甲方领导可能看不懂需求文档，但一定看得懂页面原型。让他点一点、试一试，很多纸上谈兵发现不了的问题就暴露了。原型确认完毕后再成文，形成需求规格说明书。

我用这个办法做了不下 20 个政府项目，最终的需求变更率平均控制在 8% 以内。再对比早期那些“先写个大框、后面边做边调”的项目，变更率经常飙到 25% 以上，哪个更省心，做过项目的人心里都有数。

2. 误解二：“瀑布不能响应变更”

这是我每次做分享都要专门反驳的一个点。瀑布开发并不是不能响应变更，它只是不允许“无管理、无成本、无约束”的变更。

我在项目里建立了一套叫“变更防火墙”的机制，核心是三样东西：

• 变更控制委员会：由甲方项目负责人、业务主管处室代表、我方项目经理三人组成。任何需求变更必须先到委员会评估，不是谁打个电话、发个微信就能让你改代码。
• 变更影响评估表：一个标准化的 Excel 模板，包含变更描述、影响的功能模块、工作量评估（人天）、对工期的影响、对成本的影响、是否有合同外增项、是否需要重新提交审批。每一项都填清楚，不允许模棱两可。
• “三选一”原则：每次变更，明确告诉甲方：在总预算和总工期约束下，增加功能 A 意味着要么删减同等工作量的功能 B，要么延长工期 C 天并追加费用 D 万元。你自己选。

这个机制带来的最大好处是什么？不是阻止变更，而是迫使甲方为变更承担决策成本。以前甲方说“把这个改一下”，我们二话不说就去改，改完之后他说“不对，再改回去”，来回几轮谁受得了？现在你让他填变更评估表，他自己先掂量掂量这个变更到底值不值。真正必要的变更，我们全力配合；拍脑袋的变更，自然就被过滤掉了。

3. 误解三：“瀑布在政府项目里只是妥协，不是最优”

这个观点是很多技术人内心深处的偏见。他们觉得：我选瀑布是因为甲方逼的、因为要过审计、因为“不得不”。好像内心深处还是觉得如果能选敏捷，项目能做得更好。

我现在的观点恰恰相反：在政府项目的管理范式下，瀑布不仅不是妥协，反而可能是效率最高的开发方式。这个“效率”不是指代码写得多快、功能迭代多频繁，而是指从合同签署到拿到终验报告的全程耗时最可控、返工最少、管理成本最低。

以我们 2021 年交付的一个省级行政审批系统为例。合同额 860 万，建设周期 12 个月，需求项 372 个。从需求确认到上线，全程严格按瀑布推进。最终数据：需求变更率 6.7%，返工工作量占比 9.3%，项目延期仅 14 天（在合同约定的 30 天缓冲期内），一次性通过终验。甲方信息中心主任验收那天跟我说了一句话：“你们这个项目，是我们近几年所有信息化项目里最省心的一个。”

“省心”这两个字，比什么技术先进性都值钱。因为省心意味着信任，信任意味着后续项目优先考虑你，意味着在预算评审时甲方愿意帮你说话。这些东西用代码行数衡量不了，但一个项目经理必须懂。

四、我的“强控型瀑布”：不是教科书那套，是在泥地里踩出来的

1. 第一步：把合同里的模糊空间压到最小

政府项目瀑布开发能不能稳得住，七成的功夫不在开发阶段，在合同和需求阶段。我的做法被同行戏称为“把甲方逼疯式需求确认”，但事后每次甲方都说“幸亏当初你逼了我们”。

具体怎么逼？拿 PingCode 这类专业研发管理工具为例，虽然 PingCode 主要服务的是中大型企业及 100 人以上组织，但它在需求管理上的结构化和严谨性，跟我在政府项目中推行的需求治理逻辑是同源的：层级清晰、关系可追溯、变更全留痕。

我们在需求阶段会做一张“需求-合同-验收”三维对照表：

这张表做好之后，甲乙双方各拿一份纸质版，逐条过、逐条签字。我对甲方讲的特别直白：“您现在签的每一个字，将来验收就是按这个来。如果您觉得拿不准，我们延期两周再签；一旦签了，您和我都得认。”

这种压迫感让很多甲方一开始不适应，但做到三分之一的时候基本都会感谢我。因为他们发现自己单位内部之前没想清楚的事情，被我们倒逼着想清楚了。一个项目前面想得越透彻，后面扯皮就越少。

2. 第二步：里程碑评审比编码更重要

很多团队做瀑布开发，资源全部砸在开发和测试上，里程碑评审沦为走过场。我在政府项目里反着来：里程碑评审是项目管控的最关键节点，必须投入最精干的力量去准备、去汇报、去留痕。

一个典型的项目里程碑结构是这样的：

• 需求评审里程碑：产出需求规格说明书 V1.0，由甲方业务处室负责人签字确认。确认后锁死基线，任何变更走正式流程。
• 设计评审里程碑：产出概要设计和详细设计文档，重点评审技术架构、数据模型、接口规范。这个阶段我通常要求甲方信息中心的技术骨干深度参与，因为接口和数据一旦出问题，后面返工成本极高。
• 开发完成里程碑：内部测试通过后，向甲方提交“提请初验申请”，附带完整的自测报告和已知缺陷清单。到了这个节点，核心功能必须 100% 跑通，P1 缺陷必须清零。
• 初验里程碑：甲方组织专家组进行功能测试和文档审查，形成初验意见。初验通过的模块，原则上不允许再做大调整。
• 试运行里程碑：系统在真实业务环境中运行至少 3 个月，期间产生的问题分类为“缺陷”和“优化建议”，缺陷必须在试运行期内修复。
• 终验里程碑：所有合同内需求完成，试运行报告通过，甲方出具终验报告，项目进入质保期。

这六个里程碑，每个都有明确的输入物、输出物、评审标准和签字要求。为什么不嫌麻烦？因为政府项目的本质是分阶段确认和分阶段付款。里程碑不只是技术节点，更是商务节点。你在里程碑上含糊其辞，付款的时候就有人跟你含糊其辞。

3. 第三步：用“伪迭代”化解真正的高风险模块

有人会说：你说瀑布那么好，那万一某个核心模块技术风险特别大怎么办？比如涉及跟十几年前的遗留系统做数据对接，接口文档都不全，你怎么敢在需求阶段就拍死方案？

这个问题问得特别好。我的做法是：在瀑布框架中嵌入受控的技术验证阶段，但不影响整体流程和合同承诺。我管这叫“伪迭代”，本质上是把高风险的活儿提前做、悄悄做，做完了再回到瀑布的主流程上来。

具体做法：在需求分析和设计阶段之间，加一个 2-4 周的技术验证窗口期。这个窗口期不在合同里体现，不在对甲方的公开计划里强调（当然，信息中心的技术接口人会知道），主要是我们内部把高风险的技术点用 Spike 的方式快速探一下。如果技术路线走得通，就封装到设计方案里走正常评审；如果走不通，立即调整方案并通知甲方，同时附上替代方案。

这样既保住了瀑布的框架和承诺，又不会在技术细节上摔大跟头。这个经验是我在一次数据迁移项目里用血的教训换来的：当时按瀑布直接设计方案、评审、开发，开发到第三个月才发现老系统的数据字典跟之前拿到的文档严重不符，前两个月的代码白写了。从那以后，高风险模块我必加技术验证窗口。

五、一个让你少走弯路的真实案例

1. 背景：一个传统得不能再传统的政府项目

2020 年中，我们承接了一个东部沿海城市的智慧城管综合管理平台项目。合同额 1200 万，工期 14 个月，建设内容包括：案件流转子系统、考核评价子系统、应急指挥调度子系统、大数据分析展示子系统，以及跟 6 个既有系统的数据对接。

甲方是典型的政府作风：城管局信息化分管副局长牵头，下面几个业务处室各有各的想法，信息中心就两个人还兼着其他活儿。项目启动会上，副局长说了一句让我至今记忆犹新的话：“我不懂什么敏捷不敏捷，我就要系统上线的时候所有人能用、用着不出错、审计查不出问题。”

就这一句话，我就知道这个项目必须上瀑布。而且要上“强控型瀑布”，一点懒都不能偷。

2. 过程中三次“至暗时刻”和我们的应对

第一次至暗时刻：需求调研阶段，两位处长在会议室吵起来了。

市容管理和环境卫生两个处室的业务边界有重叠，两个处长对案件的流转路径各执一词，需求访谈从下午两点开到六点没谈拢。按一般做法，这种情况就先记下来后面再说。我当时做了一个甲方一时觉得“过分”的决定：会后立即把两种方案都写成详细的需求描述，连同业务优劣对比、对其他模块的影响分析，快递送给分管副局长，请他在七个工作日内做决策。

副局长批示很快，三天就出来了。两个处长虽然有人不满意，但这是领导拍板的事，后面没有任何人再拿这个点来为难我们。这件事让我更坚定一个信念：政府项目里，最可怕的不是决策错误，而是不决策。瀑布开发通过阶段评审和签字锁定的方式，逼着甲方把该定的早点定下来。

第二次至暗时刻：开发第三个月，收到一条“上级文件”要求新增垃圾分类功能。

这是真正的不可抗力，市委发了红头文件，要求智慧城管平台必须包含垃圾分类监管模块，而且年底要见初步成果。按常规，这个模块不在合同范围内，工作量评估下来至少 150 人天，工期至少延长两个月，费用增加约 90 万。

我们启动变更防火墙机制：三天内拿出完整的变更影响评估表，列清楚新增功能范围、工作量、工期影响和费用明细。同时给出了一个替代方案：先用最小可行范围（只做分类投放数据的采集和统计展示）满足上级文件的底线要求，验收后在二期扩展。甲方权衡之后选了替代方案，变更费用控制在 35 万以内，工期仅延长 18 天。

这个过程中最重要的一个细节：所有的讨论、沟通、方案比选都有会议纪要和签字留痕。后来审计查这个项目的变更流程，一字一句都对得上。

第三次至暗时刻：试运行期间，一个核心流程每天下午三点必崩。

排查了整整一周，最后定位到是跟既有系统的数据接口在高并发下存在死锁。这时候项目已经进入试运行第三个月，距离终验只有不到 20 天。团队压力巨大，甲方的耐心也在消耗。

我们当时做了三个动作：第一，立即回滚到这个接口上线前的稳定版本，用临时方案保证业务不断；第二，调集公司架构师和 DBA 组成突击小组，在隔离环境上修复并全面回归测试；第三，每天下午五点前向甲方信息中心发一份当日进展简报，让对方知道我们在做什么、预计什么时候能修复。最终在第 12 天完成修复并上线，系统运行至今再未出现过同样的问题。

甲方后来的评价是：“你们出问题我理解，但你们出了事之后的处理流程让我觉得放心。”这句话的分量，做过政府项目的人都懂。政府客户要的不是你不犯错，而是你犯错之后有一整套可追溯的、透明可见的应对流程。这一点上，瀑布开发固有的阶段管理和文档沉淀，恰恰提供了最强的支撑。

3. 最终成绩

项目于 2021 年 9 月完成终验，实际工期比合同约定延长 18 天（在 30 天缓冲期内），实际成本控制在合同额 103%，需求变更率 5.8%，返工率 8.1%，终验专家组一次性通过。2022 年，该城管局的二期项目直接走了单一来源采购，理由就是“一期项目交付质量优秀，服务满意”。

这件事让我彻底想明白了一件事：政府项目最大的竞争力不是技术能力，而是交付确定性和信任积累。而瀑布开发，恰恰是构建这种确定性的最好骨架。

六、不同场景的行动建议：什么时候你可以学我，什么时候你得换个思路

我不想把话说成“瀑布开发最牛、什么政府项目都该用瀑布”。真实世界里没有万能方法，只有合适不合适。以下是基于我九年经验总结的一套判断框架：

1. 我强烈建议你用瀑布的场景

• 合同里有明确的交付清单，每一项都对得上验收标准
• 甲方有严格的分阶段付款计划（需求确认付 30%、初验收付 40%、终验付 30% 这类）
• 项目需要经过财政投资评审或第三方审计
• 甲方负责人明确说过“需求我们内部已经讨论清楚了”或者“上级已经批了方案”
• 项目金额超过 500 万，参与方超过 3 家单位
• 你判断甲方内部决策链条较长，重大事项需要上局长办公会或党组会

以上六条中满足三条以上，基本上不用犹豫了，上瀑布版本是安全选择。

2. 你可能需要考虑混合模式的场景

• 甲方内部对某些业务摸得还不清楚，无法在三个月内给出明确需求
• 项目包含大量数据可视化、大屏展示类的需求，甲方对效果要“看了才知道好不好看”
• 核心业态是数据分析和报表类建设，需求探索属性较强
• 甲方信息中心有一定技术能力，愿意深度参与且沟通高效

这些场景下，我的建议是：大框架走瀑布，高风险或高不确定性模块先用原型验证或小范围敏捷探路。但这里有一个前提条件必须满足：甲方的合同签署人和项目验收批准人是同一个人或同一层级，不存在“A 承诺了但 B 不认账”的隐患。否则，在责任不清的前提下搞混合模式，后患无穷。

3. 你一开始就不该碰瀑布的场景

• 纯互联网产品、面向 C 端用户的 App，用户体验驱动而非合规驱动
• 初创团队内部自研产品，需求本身还在市场验证中
• 项目资金来自风险投资而非财政拨款，不存在审计要求
• 甲方明确要求采用敏捷交付模式且已在合同里写明

对需要快速验证的初创团队，如果你们的项目管理复杂度还不高，可以考虑先用轻量级工具把需求管理起来。但等到团队发展到上百人、开始服务中大型客户、需要对接客户复杂的采购和验收流程时，对需求层级管理、迭代进度透明度的要求会快速上升。PingCode 在这方面做得比较成熟，它完整支持从史诗、特性到用户故事的多级需求管理，同时跟代码、测试、CI/CD 打通，对于既要保持内部敏捷节奏、又要拿出外部瀑布交付承诺的混合模式特别实用。但我要特别说明：前提是你们确实到了那个阶段，不要为了用工具而用工具。

七、不同情况下的取舍：有些东西你得认，有些东西值得争

1. 认了不丢人的三件事

第一，工期比预期长。瀑布开发的工期天然包含需求确认、评审、签字、审批的时间。别拿敏捷的开发速度来跟瀑布比，比的是从签合同到拿到尾款的总周期可控性。光快但验收通不过、不下付款单，那叫白快。

第二，需求变更响应慢。这是瀑布的木耳汤里本来就有的东西。你不追求快速响应变更，你追求的是“让变更在发生之前就被卡掉”。响应慢不是缺陷，在一定意义上它是故意这么设计的。

第三，甲方体验没那么“爽”。敏捷交付多爽啊，两周一个版本，甲方领导每次来都有新东西看。瀑布开发的话，前面半年全在开会和写文档，甲方可能觉得你们根本没干活。这需要你在商务沟通上多下功夫，定期汇报进展（哪怕只是文档完成情况），让甲方一直有掌控感而不是感觉你把项目“藏起来了”。

2. 打死都不能妥协的三件事

第一，需求签字。你不签字，我不开发。这句话我从来没让过步。任何以“先做出来看看效果”为起点的需求，最终都会变成“做都做了就直接上线吧”然后附带一堆缺陷和无形成本。永远不要在甲方还没签字的情况下动核心模块的代码。

第二，变更成本明示。每次变更，必须把工时、费用、工期影响写成白纸黑字给对方看。绝对不能因为“这个改动不大”就免费帮甲方做了。因为政府项目里有一个很可怕的现象：今天你免费帮他改一个小功能，下周他默认你还能免费再改五个，到最后他根本不知道哪些东西是你合同外的付出。审计也不会认你的“人情账”。

第三，文档闭环。从启动会纪要、需求评审意见、设计评审记录、里程碑确认函到终验报告，全套文档必须可以串成一条完整的时间线。少一个签字，就少一层保护。遇到甲方换人、遇到审计倒查、遇到合同纠纷，这些文档是你唯一的武器。

八、最后一点真心话

我写了这么多，不是要给瀑布开发唱赞歌。我在有的项目里也用敏捷，用得很好。但我始终觉得，真正成熟的 PM，不是执着于某一种方法论，而是能读懂不同项目背后的治理体系，然后选择最优匹配方式。

政府项目的治理体系是计划驱动、审批驱动、审计驱动的，它的基因决定了它追求确定性大于灵活性。你非要用灵活的方法去灌一个刚性的体系，不是体系有毛病，是你的判断力有毛病。

如果你现在正在做一个政府项目，正在纠结该用瀑布还是敏捷，我的建议很简单：坐回办公室，把合同和招标文件从头到尾读三遍。看里面出现了多少次“必须”、多少次“不得变更”、多少次“经甲方书面确认”。这些词的数量会告诉你要怎么选。

选瀑布，不代表你技术不行，不代表你老土。它代表你是一个能看清战场、然后选择最适合这个战场的打法的人。而这，恰恰是一个真正值钱的 PM 该有的素质。

最后送你一句话，也是我这篇长文最想说的：“稳了”从来不是一个方法论自动带来的结果，而是你深刻理解了甲方的管理体系之后，用最匹配的方法，把项目从头到尾扛下来的那份底气。