我们只用瀑布开发做硬件，成了

先说一个真实数据：我们团队在2020年立项做一款工业级手持检测设备，从需求冻结到第一批量产机下线，整整花了14个月。在这14个月里，竞争对手至少迭代了三轮产品，其中一个品牌甚至在6个月内换了两次主控方案。但结果是什么？我们的设备上市后，开箱不良率控制在0.3%以内，渠道退货率不到1.2%，而行业平均水平分别是2.8%和6.5%。更关键的是，第一批2000台机器在两个月内售罄，靠的不是价格战，而是交付质量。

这篇文章，我想把“用瀑布模型做硬件并取得成功”这件事，从头到尾讲清楚。不是理论推导，不是方法论对比，而是我们团队真实踩过的坑、做过的决策、以及最终验证下来的判断。

一、核心结论：瀑布模型在硬件领域的“反脆弱”价值，被严重低估了

在讨论任何细节之前，先把核心结论摆出来：在硬件开发领域，瀑布模型不是一种“落后的方法”，而是一种被误解的风险控制策略。它的价值不在于“按部就班”，而在于通过强制性的阶段冻结，对冲硬件制造中不可逆的物理成本。

软件行业推崇敏捷，是因为软件修改的边际成本趋近于零。一行代码改错了，回滚即可；一个功能没做好，下个sprint重来。但硬件不是这样。开一套模具的成本从几万到几十万不等，改一次PCB layout可能导致整个EMC认证重做，一个结构件的微调可能让已经备好的几千套外壳直接报废。在这些物理约束面前，“快速试错”四个字显得轻飘飘的。

我们团队的CTO在立项时说过一句话，我至今记得：“在软件行业，敏捷是让你跑得更快；在硬件行业，如果你用敏捷的方式去跑，第一道坎就会让你骨折。”这句话后来被验证了不止一次。

我们之所以选择瀑布模型，不是因为我们“保守”，而是因为我们算过一笔账：在硬件制造中，需求变更越晚发生，造成的损失呈指数级增长。而瀑布模型的核心机制，需求冻结、设计评审、阶段门控，恰恰是在变更成本最低的早期，把所有的不确定性逼出来。这本身就是一种高级的风险管理。

还有一个很多人没意识到的问题：硬件产品的市场需求变化，其实没有互联网产品那么快。一台工业检测设备的使用周期通常是5-8年，客户的采购决策关注的不是“你有没有上周的最新功能”，而是“你的设备能不能稳定运行三年不出故障”。这意味着你不需要像做App一样每周更新版本。你有时间把需求想清楚，有时间把设计做扎实，有时间把验证做充分。瀑布模型提供的“慢”，恰恰符合这个市场的节奏。

所以，我们的核心判断是：瀑布模型在硬件领域的价值被严重低估了。它不是一种教条，而是一种基于物理世界成本结构的理性选择。接下来，我会把这个判断拆开揉碎，从需求管理、供应链、团队协作、质量验证、以及与敏捷的融合实践等多个维度，逐一展开。

二、背景与真实场景：一个“反潮流”决策是如何做出的

2020年初我们团队组建的时候，敏捷开发在国内互联网行业正如日中天。公司内部其他几条产品线，包括一个SaaS团队和一个数据中台团队，都在跑Scrum。老板甚至在全员会上说过一句话：“我希望所有团队都能向敏捷转型。”

但我和硬件负责人坐下来认真评估之后，得出了一个与公司主流方向完全相反的结论：我们这个硬件产品线，不能用敏捷。

1. 产品场景：一个不能“先上线再说”的项目

我们的产品是一台用于电力巡检的手持式局放检测仪。这个产品的用户场景有以下几个特点：

• 安全要求极高：设备需要在10kV以上的高压环境下工作，任何硬件故障都可能导致人身安全事故。这意味着我们不能接受任何“上线后快速修复”的逻辑。
• 认证周期长：产品需要通过国家电网的入网检测，包括电磁兼容、环境适应性、绝缘强度等十几项测试。每一项测试的送检周期在4-8周，如果失败一次，重测又需要同样的时间。
• 供应链复杂：核心传感器依赖进口，交期长达12-16周；精密结构件需要开模，周期6-8周。任何设计变更都会触发供应链的连锁反应。
• 用户预期明确：电网客户对产品的需求是清晰且稳定的，他们不会像C端消费者那样“看到新功能就想要”，而是严格按照招标技术规范来验收。

这四个特点加起来，指向同一个结论：这个项目需要的是确定性，而不是灵活性。

2. 团队构成：一群“瀑布派”老兵

我们硬件团队的5个核心成员，全部来自华为、中兴、大疆这类硬件大厂，平均从业经验超过12年。大家都有一个共同特征：在职业生涯中完整跑通过至少3个以上的硬件项目，从立项到量产，全流程经历过。更重要的是，每个人都至少踩过一到两次“需求变更导致量产延期”的坑。

硬件负责人在加入我们之前，上一家公司做过一个智能门锁项目。因为市场部门在开模之后临时要求增加一个指纹模组，导致结构件全部重开，项目延期4个月，错过了当年的双十一窗口期，最终整个产品线被砍掉。这个教训让他对“敏捷迭代”四个字有着本能的警惕。

当我们在立项会上提出使用瀑布模型时，这个决策几乎没有遇到团队内部的阻力。所有人的反应出奇一致：“终于可以不用假装敏捷了。”

3. 决策过程：一次长达两周的争论

真正的阻力来自管理层。当我们在项目启动会上提出“使用瀑布模型”时，会议室里的气氛可以用“错愕”来形容。老板直接问了一句：“现在谁还用瀑布？那不是二十年前的方法吗？”

我花了两周时间，和公司管理层做了三轮沟通。第一轮我讲了硬件开发和软件开发的本质区别，重点是“修改成本曲线”的差异。第二轮我拿出了团队过往项目的延期数据，证明需求变更才是最大的进度杀手。第三轮我直接摊开了一张风险评估表，列出了如果采用敏捷方式可能出现的五种失败场景，每种场景都对应了具体的金额损失和时间损失。

最终让我们拿到“豁免权”的，是第三轮沟通中的一句话：“如果我们用敏捷方式跑这个项目，第一个sprint结束的时候，我们甚至还没有拿到传感器样品。请问那个时候我们review什么？”

这句话让在座的所有人沉默了。因为大家都意识到，硬件开发的节奏和软件开发完全不同。软件的“迭代”可以在一两周内完成一个闭环，但硬件的“迭代”可能需要等待物料、等待模具、等待认证，周期以月为单位。在这种情况下，强行套用Scrum的框架，只会让团队陷入“为了开站会而开站会”的形式主义。

最终，管理层同意我们采用瀑布模型，但提出了一个条件：项目必须按计划交付，不能出现任何超过两周的延期。这个条件我们后来用结果回应了。

三、拆解常见误区：关于瀑布模型的五个流行误解

在和同行交流的过程中，我发现很多人对瀑布模型的认知停留在教科书层面，甚至是道听途说的刻板印象。这些误解如果不澄清，很难真正理解我们为什么选择这条路。

1. 误解一：瀑布模型就是“一次成型，不许改”

这是最普遍的误解。很多人以为瀑布模型意味着需求定了就不能改，设计定了就不能改，一条路走到黑。事实恰恰相反。瀑布模型的核心不是“不让你改”，而是“让你在成本最低的时候改”。

在我们的项目中，需求分析阶段持续了整整两个月。这两个月里，产品负责人和客户开了不下20次需求确认会，每一条用户故事都被反复讨论、推敲、验证。我们内部做了一件被很多“敏捷派”同行嘲笑的事情：用Excel维护了一份长达378行的需求追踪矩阵，每一条需求都标注了来源、优先级、验证标准、以及变更影响范围。

这份矩阵不是“不准改”的证据，而是“要改什么、什么时候改、改的成本是多少”的透明账簿。在需求冻结之前，我们允许任何合理的变更。但冻结之后，任何变更都必须走正式的变更控制流程，评估对成本、进度、质量的影响，然后由项目委员会审批。

这种做法带来的结果是：我们的需求变更率在冻结前是23%（这很正常，说明我们在认真讨论），冻结后降至3.7%，而且这3.7%全部是因为供应商物料停产导致的被动变更，没有一次主动的功能需求变更。

2. 误解二：瀑布模型无法应对市场变化

这个批评的逻辑是：市场变化快，瀑布模型做一年才交付，到时候需求早就变了。这个逻辑在消费互联网领域成立，但在我们服务的电力巡检市场，并不成立。

我们做过调研：国家电网的巡检设备技术规范，从2017版到2021版，核心指标的变化幅度不超过15%。客户关心的几个关键参数，灵敏度、信噪比、电池续航、防护等级，在五年内几乎没有本质变化。真正变化的是客户对产品稳定性和售后服务的期望。

这就意味着，在一个需求相对稳定的B端市场，“快速响应市场变化”本身就是一个伪命题。你不需要快速响应，因为市场没怎么变。你需要的是把产品做得足够好，好到客户买了之后五年不用换。

当然，这种判断不能推广到所有硬件品类。消费电子、智能穿戴、IoT设备这些品类的市场变化确实快，瀑布模型可能并不适用。但在工业设备、医疗器械、检测仪器这些领域，需求稳定性的窗口足够支撑瀑布模型的开发周期。

3. 误解三：瀑布模型让团队失去创造力

有人认为，瀑布模型把一切都规定好了，工程师就变成了“按图施工”的流水线工人，没有发挥创造力的空间。这个批评听起来有理，但经不起推敲。

创造力和流程规范从来不是对立关系。恰恰相反，在硬件开发中，真正的创造力需要建立在扎实的设计约束之上。一个结构工程师如果想要设计出既轻便又坚固的外壳，他首先需要知道设备的内部堆叠是什么样子、散热需求是什么、防护等级要求是什么，这些信息恰恰是瀑布模型在前几个阶段已经确定下来的。

我们团队的结构工程师老张，在开模前花了三周时间反复优化外壳的加强筋布局，最终把设备重量从1.8公斤降到1.35公斤，同时通过了2米跌落测试。这个优化的前提是他清楚地知道内部结构不会大改，他的优化工作不会被后续的变更推翻。如果是在一个“敏捷”项目中，他可能根本不敢做这种深度优化，因为谁也不知道下个迭代会不会换一块更大的电池。

4. 误解四：瀑布模型只适合大团队、大项目

这个误解的来源可能是教科书上那些“瀑布模型用于大型军工项目”的案例。但我们的实践证明，瀑布模型对于小型硬件团队同样适用，甚至可能更适用。

我们团队只有5个人，但每个人都是多面手。硬件负责人同时兼任系统工程师，结构工程师也负责散热设计，嵌入式工程师同时写固件和做底层驱动。在这种“身兼数职”的情况下，如果没有清晰的阶段划分和明确的责任边界，团队会迅速陷入混乱。

瀑布模型对于小团队的价值在于：它提供了一个不依赖“频繁沟通”就能保持协作的框架。每个人都知道当前阶段的目标是什么、自己的产出是什么、下阶段的输入又是什么。这种结构化的协作方式，在人员少、角色多的情况下，反而比利频繁的站会和面对面沟通更高效。

5. 误解五：瀑布模型和敏捷是水火不容的

这是最大的误解，也是我想重点澄清的一点。瀑布模型描述的是宏观的开发阶段，敏捷描述的是微观的协作方式，两者在硬件开发中完全可以共存。

在我们的项目中，总体流程是瀑布的：需求分析→系统设计→详细设计→样机开发→测试验证→量产。但在样机开发阶段，我们内部采用了类似“日站会”的沟通机制，每天花15分钟同步进度和阻塞项；在测试验证阶段，我们用了看板来管理缺陷的生命周期。这些做法本质上都是敏捷实践，但它们被嵌入在瀑布的大框架里，为阶段性的目标服务，而不是为了迭代而迭代。

这一点我在后面的章节会展开细讲。

四、专业判断逻辑：为什么硬件开发需要“阶段门控”

前面三章讲的是“我们做了什么”和“别人误解了什么”。这一章我想深入到方法论层面，解释一下为什么瀑布模型在硬件领域具有结构性的优势。这不是经验主义，而是基于硬件开发的物理特性推导出来的。

1. 不可逆成本陷阱：硬件最残酷的经济学规律

软件开发有一个隐藏的优势：几乎所有的成本都是可逆的。你写了一段代码，发现方向错了，可以重构。你上线了一个功能，发现用户不买账，可以回滚。最坏的情况，也就是浪费了工程师的几周时间。

但硬件开发完全不同。硬件制造中存在着大量的“不可逆成本”：

• 模具成本：一套注塑模具的价格在3万到30万之间。一旦开模完成，任何结构变更都意味着修模或者重开，成本和时间都是巨大的。
• 备料成本：核心芯片和传感器的交期长达8-16周，你需要提前3-4个月下单。如果你在备料之后改了BOM，已经买回来的物料可能全部报废。
• 认证成本：安规认证、EMC认证、入网认证，每一项的测试费都在几万到十几万，而且测试周期长。一旦认证失败，重测的时间和费用都是新增成本。
• 产线成本：量产工装、测试治具、SOP文件的准备都需要时间。如果产品设计在量产前发生变更，这些准备工作可能需要重新来过。

这些不可逆成本的存在，决定了硬件开发的“试错”成本远高于软件开发。瀑布模型的价值正在于此：它在每一个不可逆成本发生之前，设置了一道门控，强制团队停下来确认“我们真的准备好进入下一阶段了吗？”

2. 质量是设计出来的，不是测试出来的

这句话在硬件领域是金科玉律。一旦你的设计存在根本性缺陷，测试只能发现它，不能修复它。要修复一个设计缺陷，你需要回到设计阶段，修改设计、重新打样、重新测试，这个周期的代价通常以月为单位。

瀑布模型通过强制性的设计评审，把质量控制的重点放在了设计阶段而不是测试阶段。在我们的项目中，系统设计评审花费了整整三周时间。我们邀请了公司内部的三个硬件专家，以及一个外部的EMC顾问，对我们的原理图、PCB布局、结构方案进行了地毯式的review。

那次评审发现了27个问题，其中最严重的一个是：电源电路布局存在潜在的EMI风险，如果不修改，极有可能导致CE认证失败。如果在打样之后才发现这个问题，修改的成本将是重新layout、重新打样、重新测试，周期至少增加8周，成本增加约5万元。但因为我们在设计阶段就发现了它，修改只需要重新画一小块PCB，成本几乎可以忽略。

这种“前期投入评审时间，后期节省返工成本”的回报，是瀑布模型最核心的经济学逻辑。

3. 供应链的物理定律：物料不会等你

硬件开发和软件开发还有一个巨大的不同：你依赖一个庞大的物理供应链。你的BOM上可能有300个物料，其中20个是关键物料，交期长达3-4个月。你需要提前很久下单，才能保证量产的物料齐套。

这就意味着，你的物料采购计划必须在设计冻结之后就能确定。你不能在备料完成之后再去调整BOM，因为那意味着已经采购的物料可能无法使用，而新的物料又要重新等待漫长的交期。

瀑布模型通过严格的设计冻结阶段，为供应链提供了一个稳定的BOM基础。我们的BOM在设计冻结后只发生过一次变更，一颗电源管理芯片因为TI停产而被迫替换。但这次替换是在设计冻结后的第三周发生的，距离量产备料还有两个月的时间窗口，我们有足够的时间重新测试和认证。

如果我们的流程是敏捷的、BOM是逐步演进的，那供应链管理将成为一场灾难。你永远不知道什么时候需要备什么料，每次变更都可能触发供应链的连锁延迟。

4. 团队协作的确定性红利

这一点很少有人提到，但对于小团队来说至关重要。瀑布模型提供的清晰阶段划分，极大地降低了团队的沟通成本。

在我们的项目中，5个核心成员之间不需要频繁同步信息，因为每个人都知道：当前这个阶段的目标文档是什么、自己的产出物是什么、下个阶段自己需要从谁那里获得什么输入。这种“文档驱动”的协作模式，在人员少、角色多的情况下，效率远高于“会议驱动”的模式。

我能回忆起最典型的一个场景：在样机开发阶段，嵌入式工程师需要知道硬件接口定义来确定驱动开发计划。他不需要去问硬件工程师，直接打开系统设计文档就找到了所有需要的信息。如果这个信息在两周前的一次站会上口头说过，但在三天前又改了，而他没有参会，这种事情在敏捷项目中经常发生，那他可能需要花半天时间去追溯最新的信息。

确定性本身就是一种效率红利。而当你的团队只有5个人的时候，每个人每天浪费半小时去同步信息，一周下来就是15个工时，足够完成一个中等规模的功能模块了。

五、具体案例与数据观察：从BOM到量产的真实数字

讲完了理论，这一章我拿出真实数字。这些数据来自我们项目的实际运营记录，时间跨度从2020年6月立项到2022年3月完成首批量产交付。

1. 需求管理：378条需求的一生

我们在需求分析阶段共识别并记录378条用户需求。这些需求按照来源分为四类：客户招标规范（占比62%）、行业标准要求（占比18%）、竞品基准功能（占比12%）、团队自研创新点（占比8%）。

在需求冻结之前，我们对这378条需求进行了优先级划分：

• P0（必须实现）：287条，对应招标规范和行业标准的硬性要求。这部分一条都不能少。
• P1（应该实现）：64条，对应竞品基准功能和基础用户体验需求。在时间和资源允许的情况下尽量实现。
• P2（可以实现）：27条，对应创新功能和差异化亮点。如果与P0/P1冲突，可以砍掉。

在需求冻结之后，P0需求零变更，P1需求发生过一次调整（因为一颗传感器的性能指标无法达到预期，我们降级替换了一颗稍低规格的方案，这条P1需求被标记为“部分实现”），P2需求因为资源约束最终砍掉了11条。总体来说，冻结后的需求稳定性达到了96.3%。

作为对比，我们翻看了公司内部另一个硬件产品线（他们采用的是“半敏捷”模式，迭代周期4周）的需求变更记录：在相同的时间窗口内，需求变更次数达到47次，其中11次发生在开模之后，直接导致3套模具报废，总损失超过20万。

数字摆在这里，谁的风险控制更好，一目了然。

2. 设计阶段：一次评审值多少钱

我们的系统设计评审持续了三周，前后开了四次评审会，邀请了公司内外共5位专家参与。直接成本（外部顾问费+内部评审工时折算）约3万元。

那次评审发现的问题清单如下：

也就是说，花3万块做评审，避免了35万的后期返工成本，ROI超过10倍。而且这还没算上避免的时间损失，如果这些问题全部在打样后暴露，项目至少延期16周。

3. 供应链：BOM稳定性的红利

我们的BOM在设计冻结后，总共包含321个物料编码。从设计冻结到量产备料完成，时间跨度约5个月。在这个期间，因为TI的物料停产通知，我们确实被迫替换了一颗电源管理芯片。但除此之外，BOM没有发生任何主动变更。

BOM稳定带来的红利体现在两个维度：

• 采购成本：因为BOM稳定，采购部门可以提前锁定价格和交期。我们核心物料的采购成本比市场均价低约8%，因为供应商喜欢“确定性订单”，他们更愿意给长期稳定的订单降价，而不是给频繁变动的订单加价。
• 库存成本：同样因为BOM稳定，我们没有产生任何呆滞物料。321个物料全部在量产中使用了。而隔壁那个“半敏捷”产品线，因为设计变更产生了约12万元的呆滞物料库存。

4. 量产质量：0.3%的开箱不良率是怎么做到的

首批2000台量产机，开箱不良率0.3%（6台），渠道退货率1.2%（24台）。而行业中间值分别是2.8%和6.5%。同行看到这个数据的第一反应是“你们运气好”，但我知道这不是运气。

这背后是测试验证阶段的充分投入。我们的测试验证周期持续了12周，包括：

• 功能测试：20台样机，每台跑完157项功能测试用例，覆盖全部需求规格。
• 可靠性测试：10台样机，每台完成温度循环（-20℃到70℃）、振动测试、跌落测试、盐雾测试、防护等级测试。
• 长周期老化测试：5台样机，每台连续运行超过1000小时，监控各项性能指标的漂移情况。
• 小批量试产：100台试产机，在真实产线上完成组装和测试，暴露工装治具和SOP的问题。

这12周的测试验证，不是瀑布模型的“冗长”，而是保证0.3%不良率的必要投入。很多敏捷派团队在测试验证阶段会“快跑”过去的，因为觉得前面的迭代已经验证过了。但硬件测试有一个铁律：样本量不够，问题就发现不了。100台试产中发现的问题，和10台样机中发现的问题，完全是两个数量级。

六、行动建议：不同情况下的瀑布实践指南

前面讲了我们的经验和判断，这一章是给读者的实操建议。根据团队规模、产品类型和市场环境的不同，瀑布模型的实践方式需要有所调整。

1. 适合使用纯瀑布模式的场景

如果你的项目满足以下条件中的至少三条，建议直接采用完整的瀑布模型：

• 产品需求来源于招投标规范或行业标准，需求稳定且明确。
• 开模成本超过10万元，或者物料备料周期超过8周。
• 产品需要通过强制认证（医疗、电力、汽车、航空等）。
• 量产数量超过5000台，品质问题带来的召回成本不可接受。
• 团队经验丰富，能够在前端设计阶段预判大部分后端问题。

在这些场景下，瀑布模型的“确定性红利”远大于“灵活性损失”。不要犹豫，直接用。

2. 适合使用“瀑布框架+敏捷实践”混合模式的场景

如果你的项目虽然主体是硬件，但包含一定的软件成分（比如嵌入式固件），可以考虑混合模式。具体做法是：

• 整体流程保持瀑布框架：需求分析→系统设计→详细设计→样机开发→测试验证→量产，阶段门控和冻结节点不变。
• 在“样机开发”和“测试验证”阶段引入敏捷实践：这两阶段内的固件开发、测试用例执行、缺陷修复可以用看板管理，每日站会同步进度。
• 在“需求分析”和“系统设计”阶段引入用户验证：虽然不追求可用的软件原型，但可以用功能样机、交互原型等方式，尽早获取用户的定性反馈。

我们项目就是在采用这种混合模式。需求冻结之后，固件开发团队在4周内完成了第一个可运行的版本，然后内部测试团队用看板管理缺陷，每天站会同步进度。这种嵌入式的敏捷实践，在保持整体架构稳定的前提下，提升了开发阶段的信息透明度。

3. 不适合使用瀑布模型的场景

诚实地说，瀑布模型不是万能的。以下场景不建议使用：

• 消费电子快消品类，市场窗口期短于6个月。
• 硬件创业的种子轮阶段，商业模式和产品方向可能发生根本性调整。
• 团队初次涉足该品类，缺乏足够的技术积累和评审能力（瀑布模型对前期判断能力的要求很高）。
• 产品的软件和服务部分占据核心价值，硬件只是载体。

在这些场景下，敏捷或者精益创业的框架可能更合适。关键是要实事求是地评估自己的项目特征，而不是盲从任何一种方法论。

七、取舍与权衡：瀑布模型不是免费的午餐

为了保持客观，这一章我必须谈谈瀑布模型的代价。任何选择都有trade-off，瀑布模型也不例外。

1. 前期时间投入巨大

我们项目从立项到需求冻结，花了两个月；从需求冻结到设计冻结，又花了两个月。也就是说，在项目启动后的前四个月，团队没有产出任何一行可运行的代码或一块可触摸的硬件。这在敏捷团队看来是不可以接受的，“四个月你们什么都没做？”

但这四个月的投入，换来了后面八个月的顺畅执行。如果前期不愿意投入这个时间，后面可能会因为一个设计缺陷多花四个月返工。这个trade-off每个团队需要根据自己的项目周期和风险偏好来决定。

2. 对团队能力要求更高

瀑布模型对前期设计阶段的质量要求极高。如果你在设计阶段没有发现潜在问题，这些问题就会一直潜伏到测试阶段甚至量产阶段才暴露，届时修复成本将是指数级的。这意味着团队必须在设计阶段就具备预判后端问题的能力，这对工程师的经验和评审机制的完善程度要求很高。

一个没有做好设计评审的瀑布项目，是最危险的：它带来的是一种“虚假的安全感”，大家以为设计通过了评审就没问题了，但实际上问题只是没有被发现而已。

所以，如果你们团队的资深工程师比例不高，或者公司内部缺乏跨领域的评审资源，瀑布模型的风险可能会被放大。在这种情况下，可能需要先建立评审机制，再推广瀑布流程。

3. 市场变化的风险仍然存在

虽然我前面论证过“B端市场需求稳定”，但这不是绝对的。如果在你开发周期内，行业标准突然更新、或者竞争对手突然发布了一款革命性的产品，瀑布模型确实可能让你错失应对窗口。

针对这个风险，我们的做法是：在需求分析阶段就把“标准演进预期”纳入考量。具体来说，我们会调研行业标准委员会未来18个月的标准更新计划，如果有即将发布的新标准，提前预留兼容设计的空间。这不是需求变更，而是需求前瞻。

4. 团队士气需要特别关注

瀑布模型的早期阶段（需求分析、系统设计）产出物主要是文档，没有肉眼可见的硬件或软件。这对于一些习惯看到“可见进展”的团队成员来说，可能会产生焦虑感，“我们到底在做什么？为什么还没看到东西？”

我们的应对方式是：在每个阶段门控评审会上，清晰地展示当前阶段的产出物和下一阶段的目标，让每个人都看到“我们即将进入哪个阶段、我们为之准备了什么”。同时，不要嘲笑这种焦虑，要正视它。因为对于初级工程师来说，四个月看不到实物确实是一种心理考验。

八、关于PingCode与瀑布场景的实践观察

在聊完我们自己的项目之后，我想补充一个来自工具侧的观察。PingCode是我们公司其他软件产品线使用的项目管理工具，它的Scrum模块设计得很完整，从需求管理到迭代规划再到燃尽图，对于纯软件团队来说确实好用。

但我想说的是另一个角度：即使是用瀑布模型做硬件，我们也从PingCode的需求管理模块中受益了。

具体来说，我们的378条需求被录入PingCode的需求池后，通过史诗、特性、用户故事的层级结构进行管理。产品负责人可以给每一条需求标注优先级和业务价值，这在需求冻结前的讨论中起到了关键作用，哪些需求是P0、哪些是P1、哪些可以砍掉，直接可以在系统中呈现，而不是靠Excel邮件来回传递。

另外，PingCode的需求追溯功能，让我们在需求冻结后可以追踪任何一条用户故事的生命周期：从需求提出到设计实现，再到测试用例覆盖，最后到量产验证，全链路透明。对于瀑布模型来说，这个追溯能力意味着，当有人提出变更需求时，我们可以快速评估这条需求关联的设计模块、测试用例和物料，变更影响分析从半天缩短到半小时。

不过需要说明的是，PingCode在瀑布场景下的适配并非完美。它的迭代规划和燃尽图功能是为Scrum设计的，在瀑布项目中使用需要一定的配置调整。但需求管理和追溯能力，对于瀑布模型来说确实提供了实打实的效率提升。这一点对于正在考虑用工具来支撑瀑布流程的硬件团队，可以提供参考。

最终回到核心观点：方法论的争论不重要，重要的是你的项目特征、团队能力、市场环境，是否和你选择的方法相匹配。我们之所以“只用瀑布开发做硬件，成了”，不是因为我们证明了瀑布比敏捷更好，而是因为我们选择了一种匹配我们项目现实的方法，并且把它执行到位。

如果你也在做一个硬件产品，正纠结于方法论的选择，我想给你三个建议：

1. 先看物理成本：你的项目中有多少不可逆成本？如果开模、备料、认证的费用和时间足够高，瀑布模型的风险控制价值就越大。
2. 再看需求稳定性：你的目标客户群需求变化快吗？如果行业规范五年不变、客户招标参数三年不变，你不需要用敏捷去应对一个不存在的变化。
3. 最后看团队能力：你的团队有没有足够资深的人能在设计阶段预判后端问题？如果有，瀑布模型会放大他们的价值；如果没有，先建立评审机制和能力。

不要因为“瀑布模型很老”就排斥它，也不要因为“敏捷很流行”就盲从它。在硬件这个充满物理摩擦的领域，很多时候，慢，就是快。