我们用瀑布开发做了三个月原型

我们用了三个月，用最正统的瀑布模型做了一个几乎可以乱真的原型。第 91 天，项目组一致决定：放弃它。不是放弃这个产品方向，而是放弃整个原型，连一行代码都不打算保留，全部重写。做出这个决定，不是因为我们突然觉醒了“敏捷信仰”，而是我们在三个月里踩遍了瀑布模型在原型开发中能踩到的所有坑。我现在把这些坑的位置、深度、以及我们后来怎么爬出来的，原原本本写下来。

一、核心结论：为什么“瀑布 + 原型”是一场必输的赌局

先说结论，不绕弯子。原型开发的核心目的是探索不确定性，瀑布模型的核心假设是消除不确定性。用瀑布的方式做原型，等于用一个确定性的工具去解决一个不确定性的问题，这是根本性的方法论错配。

我们这个项目的背景是这样：一家中型 SaaS 企业要做一个面向连锁零售门店的智能排班模块，业务复杂程度中等偏上，涉及班次规则引擎、员工技能矩阵、劳动法合规校验、门店客流峰值预测四个核心域。客户方（其实就是公司内部的产品委员会）给了一个 72 页的 PRD，号称“需求已经想得很清楚了”。

我们当时的判断是：既然需求已经这么明确了，那就不要搞什么“探索性原型”，直接用瀑布模型做一个高保真可交互原型，三个月后拿着这个原型去做客户验证，一次性把反馈收回来，再进入正式开发。听上去是不是很合理？实际上，这套逻辑有三个致命漏洞，我们当时一个都没看到。

第一，PRD 的“清楚”不等于用户的“清楚”。产品委员会写出来的 72 页文档，本质上是他们自己对业务的理解，而不是一线店长、区域督导、排班专员这些真正使用者的理解。文档写得越详细，反而越容易制造一种“所有问题都已经考虑清楚了”的虚假安全感。

第二，原型的验证价值在于“快出快改”，而不在于“做得多像真的”。我们花三个月做了一个像素级还原的交互原型，按钮位置、表单校验规则、页面跳转逻辑全都做完了。但这么长的时间窗口意味着：等我们终于把原型拿出去验证的时候，业务环境可能已经变了，而我们在前两个月里零反馈，完全是在闭门造车。

第三，“一次性收回反馈”这件事本身就不成立。用户看到原型的第一反应从来不是“这个功能做得对不对”，而是“这个我根本用不上”或者“你们为什么不做成那样”。第一轮反馈必然会引发第二轮、第三轮的调整需求。你不可能指望一次原型演示就把所有问题都暴露干净。

这三个漏洞不是事后诸葛亮，而是我们在第三个月复盘时，看着满墙的 JIRA 任务卡和一整套被废弃的 Axure 源文件，一条一条总结出来的。下面我把整个过程的每个阶段拆开来讲，让你看清楚“三个月瀑布原型”到底是怎么一步一步走向失败的。

二、背景与真实场景：我们当时为什么选择瀑布

我先把当时的决策逻辑完整还原出来，因为后来很多同行听完这个故事的第一反应都是“你们怎么会犯这种低级错误”。但真实情况是，在那个时间节点，选瀑布不是脑子一热的决定，而是经过了充分的“理性论证”。正是这种看似理性的论证，才让后面的失败显得特别有复盘价值。

1. 我们面对的约束条件

项目启动时有几个硬约束，这些约束直接影响了我们的方法论选择：

约束一：原型团队只有 4 个人，且技能栈不完整。一个交互设计师、一个前端开发、一个后端开发、一个产品经理兼项目经理（就是我）。前端是刚入职两个月的新人，对业务完全不熟。后端是从另一个项目临时抽调来的，手里还有一半精力在老项目上。指望这 4 个人在短时间内频繁迭代出可用于演示的原型，管理成本本身就很高。

约束二：产品委员会的交付预期是“看到真正能跑的东西”。他们不是那种你拿个 Axure 线框图就能满意的人。前面有一个项目因为原型太简陋，被委员会当场质疑“你们到底有没有认真做需求分析”。这个教训我们都记得，所以在这次项目上，我们倾向于做一个“能堵住所有质疑”的原型。

约束三：排班业务的逻辑本身确实复杂。这不像一个 CRUD 管理系统，排班涉及到规则冲突检测、多约束优化、员工偏好匹配等底层算法。即使只是做原型，这些逻辑也需要一定程度上真实实现，否则演示的时候根本走不通一个完整的业务闭环。

这三个约束叠加在一起，给了我们一个强烈的暗示：这件事不适合“小步快跑”，更适合“谋定而后动”。当时我们自己是这样说服自己的，

“既然需求已经写得这么详细了，团队能力又不足以支撑高频迭代，业务逻辑本身的复杂度也要求必须先想清楚架构，那不如老老实实按瀑布来：先花两周做详细设计，再用两个半月做开发和内部测试，最后拿一个完整的高保真原型去做验证。”

现在回头看，这段话里的每一个分句都站不住脚。但当时，整个团队没有一个人提出反对意见。

2. 我们的瀑布阶段是怎么划分的

按照经典的瀑布模型，我们把三个月切成了六个阶段：

这张表当时贴在项目作战室的墙上，每个人每天路过都能看到。它给我们一种强烈的“可控感”，你知道自己现在在哪个阶段，知道下一个里程碑是什么，知道距离终点还有多远。这种可控感在项目管理中通常是个好东西，但在原型开发中，它恰恰是最大的幻觉。因为原型开发的“终点”不应该是“做出来”，而应该是“验出来”。

我们一直到第 12 周才第一次把原型拿给真实用户看。前面的 11 周，所有的判断、设计、开发、测试，全部基于产品委员会 72 页 PRD 的“纸上需求”。这 11 周的用户反馈真空期，是整个项目坍塌的根本原因。

三、拆解常见误区：关于原型开发的五个错误假设

复盘这个项目的时候，我发现团队里每个人，包括我自己，脑子里都装着一些关于原型开发的“默认假设”。这些假设平时不会拿出来讨论，但会在做决策的时候悄悄起作用。它们才是导致我们选错方法论的深层原因。

1. 误区一：“原型做得越像真的，验证效果越好”

这是我们犯的最核心的错误。原型的验证价值不在于“逼真度”，而在于“反馈速度”。

我们花了大量时间在前端交互细节上：按钮的 hover 态、表单的逐字段校验、Loading 动画、数据为空时的占位图，甚至连排班甘特图的拖拽吸附效果都做到像素级还原。这三个月里，交互设计师大概 60% 的时间花在了这些“让原型看起来像真的”的工作上。

但真实用户在验证的时候，关心的从来不是这些。他们上来就问三个问题：

• 这个能不能直接导入我现在用的排班表？
• 员工请假了，这个排班能不能自动调整？
• 区域督导审核流程和我们现在的一样吗？

这三个问题，没有一个跟我们精心打磨的交互细节有关。它们全部指向业务逻辑和数据流转，而这些恰恰是我们在“先写文档再开发”的瀑布流程中，最容易被固化、最难被挑战的部分。因为一旦详细设计文档写完了，再改底层逻辑的成本太高，我们潜意识里就会抗拒方向性调整，转而沉迷于“把表面打磨得更好看”这件事。

越逼真的原型，越容易掩盖真正的业务问题。因为用户和决策者都会被漂亮的界面带偏，注意力从“这个功能对不对”转移到“这个界面好不好看”上。等你把界面改到大家都满意了，底层逻辑的问题可能要等到实际开发阶段才会暴露，那时候的返工成本就不是改几行 CSS 的事了。

2. 误区二：“前期文档写得越细，后面返工越少”

这句话在建筑工程领域可能是真理，在软件原型领域可能是毒药。

我们第 1-2 周产出的需求规格说明书 V2.0，一共 87 页，比产品委员会给的 PRD 还多了 15 页。里面光是“排班规则冲突优先级矩阵”就画了三张表，覆盖了 20 多种可能的冲突场景。整个团队都觉得自己把问题想透了。

但真实情况是：文档越详细，它承载的那些未经验证的假设就越根深蒂固。我举一个具体的例子。我们在文档里定义了一条规则：“当员工技能等级相同时，系统按照上月排班次数倒序排列，优先给排班次数少的员工分配班次。”这个规则在文档层面完全自洽，技术评审和业务评审都过了。但在第 12 周用户验证时，一个区域督导当场就炸了：“你们这么排的话，新员工永远分不到好班次，因为上月排班少的人可能是上个月刚入职的，技能等级评测还没更新！”

这条规则从文档到设计到编码，贯穿了整个瀑布流程。要改它，意味着前端排班算法模块、后端规则引擎、甚至数据库里“员工技能表”的字段结构都要动。当时已经是第 12 周了，改还是不改？改，前面两周的代码几乎白写；不改，原型验证的价值就大打折扣，因为验证出来的问题你没修，那你还验证什么呢？

这个困境不是任何一个团队成员的错，而是“先写细节文档再开发”这套流程自身带来的结构性矛盾。文档把假设锁死了，而原型应该用来挑战假设。两者的方向本身就是反的。

3. 误区三：“瀑布模型适合需求明确的场景”

这句话每个学过软件工程的人都背过，但它有一个隐含的前提没有被说清楚：“需求明确”不是指“有人把它写清楚了”，而是指“这个问题域本身是稳定的、公认的、没有争议的”。

72 页 PRD 摆在那里，看起来需求是很明确。但连锁零售门店的智能排班是一个稳定无争议的领域吗？远远不是。不同区域的门店，排班逻辑可能完全不同。社区店和商场店的客流曲线就不一样。有的门店员工是固定班制，有的是弹性班制。有的区域劳动法规定连续工作 6 天必须休息 1 天，有的地方是 7 天。这些差异不是产品委员会坐在会议室里能全部覆盖的。

我们把“文档的详细程度”当成了“需求的确定程度”，这个错误直接导致我们选择了一个根本不匹配的方法论。真正的判断标准应该是：这个问题域里，有多少答案是已知的，有多少是需要通过和用户互动才能发现的。如果后者的比例超过 30%，瀑布模型就不应该作为首选。

4. 误区四：“团队能力不够，所以需要强流程来规范”

这是我们当时选择瀑布的一个重要理由：团队只有 4 个人，还有新人，能力不足以支撑 Scrum 或看板这种“高自由度”的方法论，所以需要瀑布的强流程来兜底。

这个逻辑链的谬误在于：它假设流程的“规范性”能够弥补人的“能力不足”。但实际上，瀑布模型的强流程只在一个前提下有效，做的东西是对的。如果方向是错的，强流程只会让错误被更高效地复制到后续所有阶段。

我们那个刚入职的前端开发，在第 2 周就拿到了交互设计师画好的全部页面交互说明。他接下来两个月的任务就是按照说明把页面写出来。这期间，他不需要理解排班业务，不需要思考用户场景，只需要“照着做”。两个月下来，他的技术执行效率确实很高，但直到第 12 周用户验证那天，他才第一次知道原来“智能排班”和“手动排班”在操作逻辑上有本质区别，而他之前写的那些页面，是按照手动排班的逻辑去做的交互。

对于一个经验不足的团队成员，最可怕的不是“他不知道怎么做”，而是“他不知道自己不知道什么”。瀑布模型阻断了他在早期通过用户反馈来发现盲区的可能性，让他在错误的道路上心无旁骛地狂奔了两个月。这不是在保护他，而是在放大他的盲区。

5. 误区五：“一次性演示收集一次性反馈，效率最高”

这是我们给自己设定的最理想化的一条假设。我们设想了一个完美的场景：第 13 周，把原型往产品委员会和 5 个门店督导面前一摆，花半天时间完整演示一遍，大家提一轮意见，我们记下来，回去统一改。多高效。

现实是什么？第一次演示只看了 15 分钟就被打断了。一个门店督导指着排班日历说：“这个视图和我每天要看的东西完全不一样，你们这个版面我得横着拉三屏才能看完一天的数据。”然后整个演示就偏离了预定流程，变成了所有人围着一台显示器讨论“排班日历到底应该怎么布局”。原定 3 小时的演示，实际有效推进的新功能演示不到 40 分钟。

更糟糕的是，这次演示暴露出来的问题说明：我们对用户真实操作场景的理解，从一开始就是错的。门店督导不是在办公室用 27 寸显示器看排班表的，他们每天早上 6 点半在卖场用手机看。这个信息在产品委员会的 PRD 里完全没有提到，因为委员会的人自己也没在一线门店待过。

如果我们在第 2 周就拿一个纸面原型或低保真线框图去给门店督导看 10 分钟，这个信息第一天就能拿到。但在瀑布模型下，我们等了整整 11 周，等代码已经写完了，才拿到这个本该在最开始就知道的信息。

四、专业判断逻辑：怎么判断你的原型该用什么方法论

说完了我们踩过的坑，我来给一套我自己现在用的判断框架。这套框架是在这个项目之后，经过四五个后续原型项目的实践验证和迭代，逐渐打磨出来的。

核心判断维度有四个：需求不确定性等级、业务复杂度等级、团队成熟度等级、反馈可获得性等级。四个维度不是简单的加总平均，而是有一个优先级排序。

1. 第一优先级：需求不确定性等级

这是我排在第一位的判断维度，因为它的影响力最大、最不可控。我把需求不确定性分为三级：

• 低不确定性：问题域有成熟的行业标准或现成的对标产品，用户对自己要什么有清晰且稳定的认知，需求方和开发方对“完成”的定义一致。典型场景：做一个类 Excel 的报表导出功能，交互模式已经被全行业教育过了。
• 中不确定性：问题域在行业内有参考方案但不是标准件，需要根据具体业务裁剪，用户能说清楚痛点但说不清楚方案。典型场景：我们做的智能排班，市面上有产品但不是为连锁零售定制的。
• 高不确定性：问题域是全新的，没有成熟参照物，用户自己也不知道需要什么，需要通过不断试用来逐步定义需求。典型场景：探索一个基于 AI 的门店客流预测与动态排班联动机制。

我们的那个智能排班项目，需求不确定性在“中”到“高”之间，而我们用了一个只适合“低不确定性”的瀑布模型。这就是根本性错配。

判断标准很简单：如果你的需求不确定性在中级或以上，就不要用纯瀑布模型。至少要在需求分析和设计阶段插入迭代验证机制，哪怕只是在 Excel 里画几个关键页面的草图拿出去聊，也比闷头写两个月文档强。

2. 第二优先级：业务复杂度等级

这是最容易和“需求不确定性”混淆的维度，但它们是两个独立变量。一个业务可以很复杂但需求很明确（比如社保计算引擎），也可以很简单但需求很不确定（比如一个营销活动落地页的交互形式）。

业务复杂度我主要看三个指标：

• 逻辑分支数：核心业务流程中有多少 if-else 判断节点。我们那个排班规则引擎，单是班次分配逻辑就有超过 40 个判断分支。
• 数据依赖深度：业务逻辑依赖多少层外部数据输入。排班模块依赖员工数据、门店客流数据、劳动法规数据、历史排班数据，四层以上的依赖链。
• 跨域耦合度：一个功能的实现需要牵扯多少个不同的业务域。排班同时涉及人力资源域、门店运营域、合规域、薪酬域（因为班次影响津贴计算）。

业务复杂度高不等于应该用瀑布，但它意味着你不能用纯低保真原型。因为有些核心逻辑如果不做到一定真实度，用户根本看不出问题来。后来我们学到的做法是：把原型拆成“核心逻辑原型”和“交互体验原型”两轨。核心逻辑原型用真实代码跑通最关键的 3-5 条业务链路，早点拿出去验证；交互体验原型可以用低代码工具快速搭出来，验证操作流程和页面布局。两轨并行，而不是像我们当时那样一条瀑布串行到底。

3. 第三优先级：反馈可获得性等级

这个维度很多方法论比较里都不提，但它在我们这个项目里起到了决定性作用。你选的任何方法论，都建立在“你能多快拿到真实用户反馈”这个前提之上。

反馈可获得性主要看三个因素：

• 用户触达难度：你能不能随时找到目标用户做验证？我们的情况是：门店督导是能约到的，但需要至少提前一周预约，因为他们日常工作时间很满。这个时间成本本身就需要纳入方法论选型的考量。
• 用户反馈质量：用户能不能清晰地表达自己的需求和感受？我们面对的门店督导群体，表达能力强但业务知识内隐，很多操作习惯是他们做了五年已经自然化了的东西，你直接问“你需要什么功能”他们说不出来，但你把一个错误的东西摆在他们面前，他们两秒钟就能告诉你“这不对”。这意味着你需要的是“高频小步暴露错误”的验证模式，而不是“一次给一个完整的东西”的验证模式。
• 决策链路长度：用户提的反馈需要经过几层审批才能变成开发决策？我们的情况是：门店督导提的反馈要经过区域经理、产品委员会才能落到开发任务上。这个链路越长，你越需要把反馈收得“准”，而不是收得“全”。因为每一轮反馈的传递成本都很高。

反馈可获得性越低，你越不能指望“一次性收集全部反馈然后一次改到位”这种模式。而这恰恰是瀑布模型的原型验证策略。

4. 第四优先级：团队成熟度等级

把这个放在最后不是因为它不重要，而是因为前三个维度的因素往往是客观的、不可改变的，而团队问题是可以想办法解决的。

我们对团队成熟度的判断是：4 个人里有 1 个新手，2 个中级，1 个资深（我自己勉强算）。这个配置说实话用 Scrum 完全够用，不需要因为它不够“资深”就退回到瀑布。

一个更务实的团队成熟度判断标准是：你的团队有没有能力把一个模糊需求拆成可以在 1-2 周内交付的小颗粒度功能切片。如果团队做不到这个，那不管是 Scrum 还是看板都会跑不起来。但这个问题可以通过引入一个相对有经验的人来做“需求拆分教练”来解决，不需要直接改成瀑布。

五、具体案例拆解：以 PingCode 为例看成熟工具如何支撑原型级迭代

我在这个项目失败之后，花了不少时间去研究那些在原型阶段跑得比较顺的团队是怎么做的。一个很有参考价值的案例来自一个使用 PingCode 的研发团队，他们做的是一个面向 200 人以上组织的采购审批流引擎，业务复杂度和我们那个排班项目在一个量级，但他们的方法截然不同。

这个团队规模 7 人，比我们稍大一些，但同样面临需求不确定性高、业务逻辑复杂、用户触达有延迟的问题。他们选择的做法是在 PingCode 的 Scrum 项目模板里，把原型阶段的每个验证目标拆成独立的冲刺任务。下面是我跟他们交流后梳理出来的几个关键做法：

1. 用史诗-特性-用户故事三级结构拆解原型需求

和我们当时把整个原型当成一个“大需求”不同，他们把三个月的原型开发拆成了三层结构：

• 史诗级：“智能排班原型验证”，这是最高层级的验证目标，不直接用来排期。
• 特性级：比如“排班规则引擎核心逻辑验证”、“排班日历交互方案验证”、“员工偏好收集界面验证”。每个特性对应一个需要独立验证的核心假设。
• 用户故事级：比如“作为门店督导，我需要在手机上查看未来 3 天的排班表并能在 10 秒内完成一次换班操作”。

这个拆法的价值在于：它把“验证”这件事从“三个月做完了再一起验”变成了“每两周验一个核心假设”。他们在第三周就拿排班日历的线框图去找门店督导验证了一次，在第五周用一段独立跑通排班引擎核心逻辑的代码去做了第二轮验证。每一个验证周期都是完整的“规划-开发-演示-反馈”闭环，而不是像我们那样规划 11 周、开发 11 周、验证 1 周。

PingCode 里的用户故事可以设定优先级和业务价值评分，产品负责人能在冲刺规划会上直观地看到：当前这个冲刺要验证的 5 个用户故事里，哪些是高风险的（比如用户体验完全没有参照物），哪些是低风险的（比如标准 CRUD 操作）。高风险的故事会被排到冲刺的前半段，确保验证结果能尽早到手。

2. 站立会议在原型阶段的实际价值

我对站立会议长期有一个偏见：觉得它就是每个人报一下进度，形式大于内容。但观察完这个团队的做法后，我发现是我用错了站立会议的关注点。

在原型开发阶段，站立会议最重要的产出不是“进度同步”，而是“假设暴露”。他们每天 15 分钟的站会里，每个人除了报昨天做了什么、今天要做什么之外，必须回答一个问题：“你昨天在做的事，有没有遇到和你一开始设想不一样的地方？”

这个问题问了一个月之后，团队积累了 12 条“与初始假设不符”的记录。其中有一条后来被证明是最关键的：前端开发在做排班日历的拖拽交互时发现，门店督导实际上习惯了在另一个内部系统里用键盘快捷键操作，完全不习惯拖拽。这个发现让他们在第四周就调整了交互方案，而不是像我们那样在第 12 周才第一次看到用户的真实操作方式。

PingCode 的迭代看板在这个过程中提供了一个很实用的功能：每个人在开发任务上可以标记“阻塞项”和“风险标签”，这些标记会同步显示在迭代概览页面上。冲刺进行到一半的时候，项目经理可以通过燃尽图和阻塞项分布，直观地看到当前冲刺里有多少验证任务走不通、被什么卡住了，而不是等到冲刺评审的时候才发现一堆问题。

3. 迭代评审与回顾的“轻量版”做法

这个团队在原型阶段的做法是：每两周做一次评审，但不是正式的、全团队的、有演示流程的大评审，而是“轻量评审”。每次只拉一个真实用户（一个门店督导或一个区域经理），花 30 分钟，只看这一个冲刺做出来的 1-3 个功能点。用户边看边操作，团队边观察边记录。不做 PPT，不写展示脚本，原型打开直接上手。

这种“轻量评审”在传统的瀑布流程里几乎不可能实施，因为瀑布的交付物是阶段性的、整体的、不可拆分的。但在 PingCode 的 Scrum 模式下，每个冲刺产出的都是一个可独立演示的增量，你可以选择只拿出其中最高风险的那个增量去做验证，其他东西不演示也没关系。

回顾会议他们也做了简化。不搞什么“开始-停止-继续”的表格（团队觉得太抽象），而是只聚焦一个问题：“这个冲刺里，我们学到了什么在上一个冲刺里不知道的东西？”每次回顾会产出一条“新知记录”，在下一次迭代规划的时候作为假设调整依据。

4. 从“数据打通”看全流程可追溯性的价值

这个团队使用的另一个让印象深刻的能力是 PingCode 各产品模块之间的数据互通。他们的原型需求在 PingCode Project 里管理，测试用例在 Testhub 里管理（即使是原型阶段，他们也会为核心规则引擎写自动化验证脚本），技术文档在 Wiki 里沉淀。

当他们在第五周的评审中发现排班规则冲突检测算法漏掉了一个边界条件时，研发人员可以在 PingCode Project 的任务卡片上直接看到这个需求对应的测试用例、关联的技术文档以及之前的评论记录。不需要来回切换 JIRA、Confluence、TestRail 三套系统去追查“这个需求当时是怎么写的、谁评审的、测试用例覆盖了哪些场景”。

对于原型开发来说，这个全流程可追溯性的价值在于：每一次“验证发现的问题”都能被精确地定位到上游的“哪个需求假设错了”，而不是笼统地总结为“用户对排班视图不满意”。当团队在回顾会上分析“排班规则冲突优先级矩阵漏掉了新员工场景”这个问题时，他们可以直接点开对应的史诗、特性、用户故事和测试用例，看这条需求链路上哪个环节没有考虑到这个场景。这种精确的归因能力，在瀑布模型那种“文档→代码→发现”的线性流程里几乎是做不到的，因为中间环节太多，信息衰减太严重。

需要说明的是，这里以 PingCode 为例，是因为这个案例团队恰好用的就是 PingCode，而且他们选 PingCode 的原因也和团队规模有关（200 人以上的组织，项目管理工具的选择往往不是一个人说了算，而是要考虑整个研发体系的兼容性）。如果你的团队只有 5 个人，你用 Trello 或者飞书多维表格跑 Scrum 也完全没问题。工具不是重点，重点是把“每两周拿出来给用户看一次”这种节奏跑起来，而不是憋三个月再亮出来。

六、行动建议：如果你现在正准备做一个原型

如果你读到了这里，很可能你的团队正在面临一个类似的决策：接下来三个月要做原型验证，该走什么流程？我结合踩过的坑和后来验证过的有效做法，给一套可以直接拿去用的行动框架。

1. 第一个动作：做一次“不确定性审计”

在决定用什么方法论之前，先花两个小时做一次团队内部的“不确定性审计”。方法很简单：

1. 把原型要验证的所有核心假设列出来。比如“用户会在手机上使用排班功能”、“门店督导需要拖拽交互”、“员工偏好对排班结果影响权重应该大于客流预测”等等。
2. 给每一条假设打分，1 分表示“我们非常确定这是对的”，5 分表示“这完全是猜的”。
3. 统计得分在 4 分和 5 分的假设有多少条。如果超过总数的 40%，你就不能选纯瀑布模型，必须引入迭代验证机制。

我们当时的项目如果做这个审计，至少有 50% 的假设是 4 分以上的，但我们完全没有意识到这一点。

2. 第二个动作：画一条“用户可触达曲线”

在项目启动第一周，项目经理就应该去摸底一件事：目标用户群体在接下来的三个月里，分别在什么时间段、以什么形式可以被拉到验证中来。

如果门店督导只能在每周三下午 2-4 点之间接受 30 分钟的验证访谈，那你的冲刺节奏就必须围绕这个时间窗口来设计。比如每个冲刺的评审时间固定在周三下午，冲刺周期设为 7 天或 14 天。不要让用户来适配你的开发节奏，要让开发节奏适应用户的可得性。

3. 第三个动作：拆出“高风险先行”的冲刺计划

把第一个冲刺的目标设定为：验证不确定性最高的那 1-2 个假设。不要在第一轮就想着搭一个完整的项目骨架或基础架构。原型阶段不存在“基础架构”，只有“需要被验证的假设”。

具体拆法：

• 第一轮冲刺（第 1-2 周）：做一个只有排班日历核心页面的低保真原型，拿给 3 个门店督导看，只验证“他们的日常操作路径和这个页面布局是否匹配”这一个假设。其他功能点全部用占位符或假数据代替。
• 第二轮冲刺（第 3-4 周）：在第一轮反馈的基础上，加入排班规则引擎的 3 条最核心规则，做成一个能跑通的极简链路，再次拿给同一批用户验证“规则逻辑是否符合他们的实际业务”。
• 第三轮以后：根据前两轮暴露出的新假设，逐步追加功能模块。

这种拆法让团队在前两周就能拿到反馈，而不是在第 12 周一次性面对 42% 的无效功能要返工。

4. 第四个动作：建立“假设-验证-记录”的习惯

在团队内形成一个硬性规范：每一个开发任务的开端，都必须用一句话写明“我们假设用户会……”，在这个任务的评审或演示环节，必须有至少一个真实用户的反馈来支持或推翻这个假设。推翻了的记录下来，成为团队“领域知识库”的一部分。

这个习惯的价值远远超过一个项目本身。我们后来在一个新项目上推行了这个做法，三个月下来积累了 37 条“被验证过的用户行为假设”，其中 11 条是推翻初始认知的。这 11 条记录后来成了产品委员会的必读材料，避免了后面的项目在同一个地方再踩一遍坑。

七、不同情况下的取舍：没有银弹，只有适配

写到这里，我必须说一句可能会推翻前面部分观点的话：并不是所有场景下瀑布模型都不适合做原型。有一些特殊场景，瀑布模型的某些特性反而能帮你控制风险。关键在于你能不能清楚地识别你的场景属于哪一种。

1. 场景一：法律合规驱动的原型

有些原型的核心验证目标不是“用户喜不喜欢”，而是“这个方案能不能通过监管审核”。比如我们后来做的一个涉及跨境数据合规的模块，核心需要验证的是数据流转路径是否符合 GDPR 要求。

在这种情况下，瀑布模型的“前置文档化”反而是一个优势。因为监管审核需要完整的、可追溯的、有时间戳的设计文档。你的用户不是门店督导，而是法务和合规官。他们对“可演示的软件”没有诉求，他们需要的是“可审查的文档”。这时候，把文档写清楚拿去做合规预审，比做一个可交互的原型优先级更高。但即使在这种场景下，也建议在瀑布流程里插入最少两个“文档评审节点”，而不是等到全部写完再一口气送审。

2. 场景二：硬件依赖或第三方系统耦合度极高的原型

如果一个原型需要对接一个上线周期很长、接口文档不完善的第三方系统（比如某些银行的支付网关或政府的政务数据接口），而且原型的大部分不确定性都集中在“对方系统实际返回什么数据”这一点上，那瀑布模型的阶段性交付物（特别是接口规格文档）可能会有用。

但这种场景下的正确做法不是“回归纯瀑布”，而是把第三方依赖的部分单独抽出来用“文档先行”策略，其他用户交互验证的部分仍然走迭代模式。两条轨道用不同的节奏跑，在集成点汇合。

3. 场景三：甲方合同强制要求阶段性文档交付

这是最无奈但也最常见的一种场景。有些甲方的合同里明确写了：第几周交付需求规格说明书，第几周交付详细设计文档，文档不签字不付下一笔款。

面对这种硬约束，你能做的是在“必须交付文档”的前提下，内部偷偷跑小循环。比如合同要求第 4 周交付详细设计文档，你在第 2 周内部就拿低保真原型去做一次用户摸底，把摸到的核心发现写到设计文档里。这样虽然方法论层面走的还是瀑布，但文档的内容质量是经过快速验证的，而不是闭门造出来的。

下面这张表总结了不同场景下的策略取舍：

八、带走的经验：三个月换来的三条铁律

那个被我们废弃的原型，代码删掉了，源文件归档了，但从它身上总结出来的三条经验，后来我们用在了之后每一个原型项目上。在这里分享出来，希望你不用再花三个月去验证它们。

铁律一：原型的价值用“学到什么”来衡量，不用“做成了什么”来衡量。我们废弃了 42% 的功能代码，看起来是巨大的浪费。但如果这些功能在正式开发阶段才被废弃，浪费至少要乘以 4（因为正式开发的代码质量要求、测试覆盖、部署维护成本都远高于原型）。原型阶段“废掉”的代码不是浪费，是帮你省下了正式开发阶段要交的学费。关键是你有没有在废弃之前从这些代码里学到东西。我们当时学到的东西包括：排班日历的布局方案错了、优先级矩阵漏了新员工场景、门店督导用的是键盘不是拖拽、他们每天在手机上操作不是在电脑上。这些信息，某种程度上比一个“成功的原型”更有价值，前提是你真的把它们记录下来了，并且用到了后续的决策里。

铁律二：用户反馈的“早”比“全”重要十倍。第 2 周拿到的 5 分钟反馈，价值远超第 12 周拿到的一份两小时的完整评审报告。因为越早的反馈，你用来调整方向的时间就越充裕，调整的成本就越低。我们第 2 周如果能知道门店督导是在手机上看排班表的，整个交互设计方案都会重做，但那时候重做的成本大概就是设计师一周的工作量。等到第 12 周才知道，改变的代价是前端两个月的工作量加上设计师一周的工作量，还不算重构对团队士气的影响。

铁律三：流程是为了暴露问题，不是为了掩盖问题。瀑布模型的强流程给我们带来的“可控感”，本质上是把问题往后推的一种心理安慰。我们把所有的不确定性都压缩在需求分析阶段，好像只要文档写到了 87 页，所有的坑就都被探明了。但实际上，文档只是把坑的位置画在了纸上，并没有把坑填上。当你按照图纸走到那个位置的时候，坑还是在那里，一个没少。好的流程不应该是让你觉得“一切尽在掌握”，而应该是让你尽快知道“哪些东西并不在掌握之中”。

九、下一步怎么做：给读到这里的你一个可以立刻执行的动作

如果你现在手头正有一个原型项目要启动，或者一个已经跑偏的原型项目要拉回来，我不建议你立刻去推倒重来或者革命性变革（团队受不了，你自己也扛不住）。我建议你做一件事：

在你的下一个迭代计划会议上，做一次“假设排序”。

操作步骤如下：

1. 让团队每个人花 10 分钟，各自写下来他们对这个产品最重要的 3 个“未经验证的假设”。比如“用户会接受 AI 自动排班的结果而不需要手动调整”、“班次冲突的解决方案可以通过规则自动化解 80% 以上”、“连锁门店的排班逻辑可以标准化到不需要分区域定制”。
2. 把所有人写的假设收集起来，去掉重复的，得到一张假设清单。然后在每个假设后面标一个星星数，1 颗星表示“如果这个假设是错的，只需要微调”，5 颗星表示“如果这个假设是错的，整个方案要从头来过”。
3. 把 5 颗星的假设挑出来，选一个可以在两周内完成验证的做成一个冲刺任务。这个冲刺任务的目标不是“做出什么功能”，而是“用最小的成本验证这个假设是真的还是假的”。
4. 两周结束后，拿着验证结果回到团队里，把被证伪的假设划掉，把被证实的假设升级为“已确认的设计依据”。然后选下一个 5 星假设，继续循环。

这个过程不需要你立刻切换到 Scrum，不需要你买新的项目管理工具，甚至不需要你说服老板支持“敏捷转型”。你只需要在你的瀑布流程里硬插入这样一个循环，然后再决定要不要在下一个原型项目上彻底改变方法论。

我们就是这么走出来的。那个废弃了三个月的排班原型之后，下一个项目我们只用了六周就完成了全部的验证工作，而且最终进入正式开发阶段的功能规格里，没有一条是从那 87 页 PRD 里直接搬过来的，全部是经过真实用户验证后重新写的。那六周的效率，远高于之前的三个月。不是因为我们变聪明了，而是因为我们终于把“验证”这件事放到了它应该在的位置上：最前面，而不是最后面。