瀑布开发不适合快速验证产品

一、我为什么敢下这个判断：瀑布开发的核心矛盾不在“慢”，而在“验”

2018 年我参与过一个 SaaS 产品的完整重建。当时团队花了将近四个月做需求调研、PRD 撰写、技术方案评审、UI 设计定稿，按照标准的瀑布流程走完了需求冻结和概要设计阶段。我们做了 200 页的方案说明书，功能清单列了 47 项。上线之后的数据是什么？注册转化率不到 2%，核心功能日活没超过 50 人，而我们在正式发布前已经投入了 14 个工程师和 6 个月的工资成本。

这件事让我重新审视一个长期被误读的问题。很多人说瀑布开发的缺点是“太慢了”，但这不是本质。如果你做的是一栋楼、一座桥、一个卫星定位系统，慢是合理的。但当你的目标是快速验证一个产品是否值得继续投入时，瀑布开发真正的致命伤是：它在验证环节存在结构性延迟。

我们不是在做基础设施工程。我们面对的场景是：不知道用户会不会为这个功能付费，不知道这个交互逻辑是否成立，不知道为什么报名流程走到第三步就全部流失。这些问题不是“文档写得不够细”“架构设计不够完善”能解决的，而是必须让真实用户在真实场景里操作一次，看他们的反应，看数据漏斗，然后快速调整。

瀑布开发把“验证”这一环放在了整条研发流程的最后端。需求、设计、开发、测试、集成、部署，一路走下去，只有到了 UAT 或者公测阶段，你才能第一次看到用户行为数据。你烧掉了 80% 的预算，却只收到第一批有效反馈，这不是开发流程，这是赌博的流程。

很多人为瀑布开发辩护，说“只要需求写得足够清楚，就不会有问题”。这句话恰恰暴露了一个根本性的认知错误。在产品验证阶段，需求本身就是一个假设，而不是一个结论。你对用户痛点的理解、对解决方案的设想、对功能优先级的判断，在没有经过行为数据校验之前，都只是团队的集体想象。用瀑布方式去执行一个假设，等于把验证成本拉到最高，把试错机会压缩到最小。

1. 瀑布模型不是错，是用错了地方

这里必须澄清：这篇文章的目标不是全盘否定瀑布开发。 如果你在做的是一个需求明确、技术成熟、监管要求严苛的项目，比如银行核心账务系统的升级，或者医疗器械软件的合规交付，瀑布模型仍然是更安全的选择。因为在这些场景下，变更本身就意味着风险，而详细的前期文档是降低合规风险的必要成本。

但问题在于，很多产品和创业团队没有区分“执行已知”和“探索未知”这两种截然不同的工作类型。当你的产品处于 0 到 1 阶段，或者正在探索一个新的业务方向，你面对的是高不确定性，而不是高复杂度。这时候你需要的是快速获取知识，而不是快速交付功能。

瀑布模型假设你在最开始就知道要做什么，后面的所有动作都是在“正确地做这件事”。而产品验证阶段的真实情况是：你根本不确定自己要做的是不是“对的事”。这两种假设前提完全不同，套用同样的流程框架，结果必然是灾难性的。

2. 风险后置：当你看到问题的时候，已经来不及了

瀑布开发的风险管理模型有一个根本缺陷：它把最高风险的决策（需求定义）放在了信息最少的时间点（项目初期），而把最低风险的修正动作（代码重构、UI 调整）放在了成本最高的时间点（开发后期）。

2019 年我们帮助一个教育 SaaS 团队做过诊断。他们在瀑布模式下花了 8 个月开发了完整的教务管理系统，包括排课、考勤、成绩管理、家校互动四大模块。上线之后发现，学校用户真正高频使用的只有“家校互动”里的通知和打卡功能，而那些花了最多精力的工程模块，智能排课、多维度成绩分析，使用率分别只有 12% 和 7%。

问题出在哪里？不是技术实现得不好，而是当初做需求决策的时候，团队没有机会在真实场景里验证“学校教务人员每天到底打开哪个页面”。他们以为教务管理的核心痛点是“排课复杂”，实际上教务人员最头疼的是“通知家长别漏掉今天的作业”。这两个需求对应的产品形态和资源投入量级完全不同。

瀑布流程让团队在“为什么要做这个功能”这个问题上几乎没有压力测试。只要文档评审通过，只要技术方案可行，只要产品经理和研发负责人达成一致，这个功能就进入了开发队列。没有人问：我们有任何证据表明用户需要这个吗？

这个问题的破局点不在流程优化，而在整个研发节奏的重新设计。你必须把“验证”这个环节从流程末端提到最前端，在资源投入很少的时候，先拿到第一手的行为数据和用户反馈。

二、为什么很多团队明知瀑布有问题，还是陷在里面

过去五年我在咨询和产品评审中遇到不少团队，他们桌上的敏捷宣言海报贴得好好的，站会开得一本正经，但实际的研发节奏和瀑布开发几乎一模一样，需求提前排了两个月，一个迭代的功能范围锁死，开发完成再扔给测试，最后上线时业务方说“这不是我想要的”。

这不是执行力的问题，也不是 Scrum Master 不称职。这是一种结构性的倒退。

1. 组织惯性：KPI 和汇报体系在惩罚“验证行为”

瀑布开发之所以在公司内部获得生命力，不是因为它效率高，而是因为它符合传统的管理语言。需求文档、排期计划、里程碑节点、交付清单，这些本质上都是管理层用来获得确定感的工具。

在一个以“按时交付功能”为核心 KPI 的组织里，产品经理写出一份 60 页的 PRD，是可以被量化和考核的。而“我们用了两周时间去和 8 个用户深访，发现之前的方向是错的，所以这个迭代什么都不开发”，这种行为在大多数公司不但不会得到认可，反而会被视为“效率低下”或“产出不足”。

我见过一个典型案例。某个金融科技团队的产品负责人，坚持在开发前用低保真原型做了一轮用户测试，发现原本计划花一个月做的“智能投顾问答功能”在对话逻辑上有严重缺陷。她决定暂停开发，先做概念验证。结果在月度复盘会上，高管层的第一个问题是：“这个月你的团队产出了什么？”她回答：“我们发现了一个不该做的功能。”这句话在当时的会议室里并没有得到正面反馈。

三个月后，同行业的另一家公司硬着头皮把这个功能做了出来，投入了 4 个工程师 3 个月的时间，上线后用户 NPS 跌了 15 个点。这个事后对比才让之前的“不开发决策”显得有价值。但我们不能指望每次都用竞品的失败来证明自己的正确，这套验证逻辑需要被体系化地融入研发流程本身。

在这种管理文化下，团队自然会倾向于做那些“能被看见”的事情。写文档、排计划、画原型、堆功能，这些行为的可量化程度远高于“验证一个假设”。所以即使团队名义上是敏捷的，他们的资源分配逻辑依然是瀑布的。

2. 认知误区：把“功能上线”当成“验证完成”

这是另一个高频陷阱。很多团队把“功能做出来了”等同于“市场验证通过了”。只要代码合入主干、测试用例跑通、灰度发布没有大规模报错，这个需求就被打上了“已完成”的标签，然后产品经理开始写下一个 PRD。

但真正的验证要看的是：上线之后，用户的行为数据改变了没有？留存提升了没有？核心转化路径的通路率上升了还是下降了？如果这些数据没有达到预期，即使功能本身没有 Bug，它依然是一个失败的验证结果。区别在于，如果你是在瀑布流程里发现这个失败，你已经付出了完整的开发成本；如果你是在验证驱动的流程里发现，你可能只付出了十分之一的成本。

两个成本的差值，就是瀑布开发在验证场景下的代价。

这里我特别想强调的是，验证失败不是研发失败，研发失败才需要复盘和改进流程，验证失败恰恰说明流程在发挥作用，它帮你提前排除了一个错误选项。但瀑布开发天然不具备区分这两者的机制，它把所有没上线的、不开发的、被暂停的需求，都视为“进度落后”。

3. 工具使用不当：把 Jira 当成电子看板，把 TAPD 当成需求文档库

PingCode 这类工具在 100 人以上的研发组织里部署率并不低，但我观察到一个普遍现象：很多团队把工具用成了瀑布流程的电子化版本。需求管理模块用来存史诗和用户故事，迭代模块用来做任务分配和工时统计，评审和回顾模块只是走个过场。

关键不是工具本身的问题，而是使用工具的人没有把“验证”作为迭代目标。一个迭代的结束标准不应该是“所有任务完成”，而应该是“我们对用户/市场有了一个更清晰的判断”。如果这个判断是负面的，我们走错方向了，那这个迭代同样是有产出的，产出的是知识。

PingCode 在 Scrum 解决方案里设计了一个很重要的环节，就是迭代回顾板。这个板子的目的是记录团队在迭代过程中做对了什么、做错了什么、下一步改进计划是什么。但如果团队只用它来做个形式化的总结，写几条不痛不痒的“我们沟通需要加强”，那它就无法发挥验证驱动的作用。真正的回顾应该围绕一个核心问题：我们在这次迭代里的关键假设是什么？数据支持这个假设吗？

三、重新定义验证节奏：不是“做完了再验”，而是“验明白了再做”

要解决瀑布开发在验证场景下的结构性问题，光靠理念普及是不够的。团队需要一套可以落地的节奏设计，把“验证”从流程的末尾强行提到前端，并且让每一个验证动作都有明确的成本上限和退出条件。

我自己的实践总结下来，关键不在于你用的是 Scrum 还是 Kanban，而在于你是否把迭代目标从“交付功能”切换到了“获取知识”。

1. 用“验证里程碑”替代“功能交付里程碑”

在传统的瀑布项目里，里程碑是需求冻结、设计完成、编码完成、测试完成、上线。这些节点衡量的是进度。而在一个面向验证的节奏里，里程碑应该是“我们用多少成本验证了一个什么假设，结论是什么”。

举个例子。一个做社区团购的团队想验证“团长主动分享商品链接会不会提升订单转化”。按照瀑布的做法，这个需求会被写进 PRD 里，排进下个月的迭代，经历完整的设计、开发、测试、上线周期，至少需要 3 到 4 周。但如果他们把验证里程碑设为“用 3 天时间，让 10 个团长在现有群里手动发链接，看订单量变化”，他们一周内就能拿到初步判断，而且几乎不需要研发资源。

这个思路不复杂，但它要求团队在需求评审时多问一句：这个需求背后的假设是什么？我们能不能用更便宜的方式检验这个假设？

PingCode 的需求多级管理，史诗、特性、用户故事，在这个场景下其实可以发挥很大作用。产品负责人可以把“验证一个业务假设”设为一个史诗，下面拆解成若干个小规模的验证任务，每个任务的目标不是完整的功能交付，而是一个实验设计加上数据采集方案。

在迭代规划会上，优先级不再只按“业务价值”排序，还要考虑“信息价值”，这个需求完成之后，能帮我们消除多少不确定性？

2. 区分“探索轨”和“交付轨”的资源配置

有一个比喻说得好：你不可能用同一套施工流程既去勘探金矿又去建高楼。勘探金矿需要的是快速打孔、取样、判断含金量，成本低、节奏快、失败率高；而建高楼需要的是精准的设计、严格的审批、按图施工，成本高、节奏稳、不允许失败。

在产品研发里，很多团队犯的错误就是让“勘探队伍”按“建筑施工标准”干活。一个还在验证产品市场匹配度的新功能，却要走完整的需求评审、技术方案评审、测试用例评审流程，最后团队的验证速度被流程本身拖死。

我的建议是，把团队的资源池至少分成两条轨道：

• 探索轨： 用于验证新假设、探索新方向。迭代周期短（1-2 周），产出物不追求完整性，可以是原型、落地页、人工服务流程，只要能在真实用户那里收集到有效数据就行。团队规模小（2-4 人），MCP 由产品负责人直接决策，不需要跨部门审批。
• 交付轨： 用于已经验证过的、确定要规模化的功能。在这些功能上，团队可以继续使用更接近瀑布的流程，需求稳定、方案完整、质量要求高。因为它们的风险已经不是“方向对不对”，而是“实现得好不好”。

这个双轨模式不是新概念，很多团队在理论层面认可，但在执行层面很难落地。因为大多数项目管理工具没有为“探索”设计专用流程。关键还是要靠团队自己建立规则。比如在 PingCode 的项目管理里，可以专门建一个“验证看板”，限制在制品数量，强制每个验证卡片的预算上限（比如不超过 3 人天），并且要求每个卡片在完结时必须有明确的数据结论，证明或证伪都可以。

3. 把“不开发”当成一种正常的迭代产出

这是我观察下来最难推行的一条，但也是验证驱动模式能否真正跑起来的关键。如果一个团队在迭代结束时什么都没开发，但获得了“这个方向不值得做”的结论，这个迭代不能被称为“没产出”。

要做到这一点，需要在迭代规划阶段就明确每个待办事项的信息价值。怎么衡量信息价值？可以问三个问题：

1. 如果不做这个事项，我们对用户需求的理解会有多模糊？（信息缺口）
2. 如果这个假设被证伪，我们能在下一个迭代里省掉多少无效投入？（风险规避价值）
3. 这个结论会影响多少个下游决策？（杠杆效应）

如果一个需求在这三个维度上得分都很低，那它更适合放在交付轨里流程化处理。如果得分很高，比如它的结论会影响接下来三个迭代的功能优先级，那无论多小的事，都应该优先做验证。

PingCode 的用户故事和特性管理在这里可以配合使用。产品负责人在给需求设定优先级和业务价值时，可以额外增加一个字段叫“信息价值评分”，作为迭代规划时的排序依据之一。这个事情不需要工具支持，一张表格也能做，关键在于团队是否愿意在迭代计划会议上花 10 分钟讨论“我们的关键假设是什么”。

四、一个具体的对比：用同一需求跑两个流程，数据差距有多大

为了让这个判断更具象，我用一个自己参与过的需求作为案例来对比。这个需求是：“在课程详情页增加‘好友拼团价’模块，验证能否提升报名转化率”。

需求本身不复杂，业务方的假设是：家长看到拼团价会更愿意分享给其他家长，从而带来新用户。这个假设是否成立，在没有数据之前谁也不知道。

1. 瀑布流程下的执行路径

按照当时团队的实际流程：

• 需求分析阶段（1 周）： 产品经理写 PRD，业务方确认需求细节，UI 同步开始设计。
• 设计评审（3 天）： 交互方案、视觉稿、后端接口定义同步进行，涉及课程、订单、拼团三个模块。
• 开发阶段（3 周）： 前端开发拼团展示模块、价格计算逻辑，后端开发拼团创建、加入、成团状态判定，测试编写用例。
• 测试与灰度（1 周）： 覆盖正常流程、边界情况、并发拼团逻辑。
• 全量上线（1 天）： 监控报错、转化数据。

全流程耗时约 5 周半，投入约 13 人周（前后端、测试、产品），总成本按中等薪资折算约 8 到 10 万元。

上线后的结果是：拼团功能的使用率在前两周达到 8%，但真正通过拼团完成付款的新用户占比不到 1.2%。转化提升微乎其微，ROI 远低于预期。

2. 验证驱动流程下的执行路径

同一个需求，如果按照验证驱动的思路重做一次，路径会完全不同：

• 假设拆解阶段（半天）： 产品负责人和业务方一起拆解假设。核心假设是“看到拼团价会激发分享行为并带来转化”，但这个假设可以被拆成两个子假设：
  1. 用户看到拼团价后，点击分享按钮的意愿会提升。
  2. 被分享者点击链接后的购买转化率高于自然流量。
• 低成本实验设计（半天）： 不开发拼团功能，而是在现有课程详情页上临时增加一个静态 banner，文案为“邀请好友一起学，立减 XX 元”，点击后跳转到客服微信。由客服人工处理拼团流程，整个过程靠人力跑通。
• 实验执行（5 天）： 选择 3 门课程做 A/B 测试，对照组为原有页面。每天统计 banner 点击率、加微信人数、最终成团转化。
• 数据分析与结论（1 天）： 5 天跑下来，banner 点击率 3%，远低于预期。加微信的 30 个用户中，最终成团付款的只有 3 人，转化率约 10%，但考虑到前端的点击基数太小，整体新增付费用户数为 3 人。

全流程耗时 7 天，投入约 0.5 人周（产品+客服人工），总成本不到 2000 元。

结论：拼团逻辑对转化提升不明显，至少在当前课程价格和用户场景下不成立。这个需求被标记为“验证未通过”，不再进入交付轨道。

3. 两条路径的效率差异，不是倍数级的，是指数级的

把两组数据放在一起对比：

这组数据不是偶然的。在我过去帮助团队做过的类似对比里，验证驱动流程在信息获取效率上通常比瀑布流程高出 10 到 50 倍，具体取决于需求的复杂度和实验设计的巧妙程度。

这个案例里还有一个容易被忽略的细节：在瀑布流程中，因为投入了 5 周的研发资源和大量的跨部门协调成本，即使上线后数据很差，团队也会倾向于继续优化拼团功能而不是放弃，因为“已经投入这么多了，再改改说不定能起来”。这种沉没成本效应在瀑布模式里被放大得尤其严重。

而验证驱动模式让团队在 7 天内就拿到了结论，心态上更容易“止损”。决策质量的高低，不只取决于信息本身，还取决于你做决策时已经投入了多少成本。

五、如何在 PingCode 里搭建一套“验证友好”的 Scrum 流程

PingCode 的产品定位是做标准 Scrum 流程的数字化落地，它本身并没有“双轨模式”这样的预设模块。但它的灵活度足够支持团队根据自己的业务节奏，在标准流程里嵌入验证驱动的机制。

下面是我在实际项目中总结的几条操作建议，都是在 PingCode 里可以直接落地的。

1. 需求分级：史诗、特性、用户故事的验证属性标注

PingCode 支持三级需求管理：史诗、特性、用户故事。我建议团队在整个需求结构的最上层，史诗层，增加一个维度的判断：这个史诗属于“探索型”还是“交付型”？

• 探索型史诗： 目标是在限定成本内验证一个业务假设。其下面的用户故事不一定是“要完成的功能”，而是“要执行的实验步骤”。比如“在 3 门课程上挂静态 banner 并统计点击率”，这个在系统中完全可以建为一个用户故事。
• 交付型史诗： 目标是高质高效地交付一个已经被验证过的功能。下面的用户故事是标准的开发任务。

产品负责人在创建史诗时，可以在自定义字段里加上“信息价值评分”和“验证预算上限”。前者帮助迭代规划时做优先级排序，后者是一个硬约束，防止探索型需求悄悄膨胀成完整开发项目。

2. 迭代规划：引入“假设评审”环节

在迭代计划会议上，产品负责人通常会把高优先级的需求拿出来给大家讲解。PingCode 的这个流程设计本身没有问题，但我建议在讲解之前加一个 15 分钟的“假设评审”环节。

具体做法：

• 产品负责人把本次迭代要做的需求背后的假设，用一句话写出来。格式为“我们相信【目标用户】有【某个痛点/需求】，因此如果我们提供【某个解决方案】，将会看到【某个行为/数据变化】”。
• 团队一起审这个假设：逻辑上成立吗？有没有现有数据可以佐证或者反驳？能不能花更低的成本先测验一下？
• 如果假设在评审环节就被挑战得体无完肤，那这个需求可以直接降优先级或者退回 backlog。

这个过程不需要额外工具，几分钟就能完成。但它对于阻止那些“看起来合理但经不起推敲”的需求进入开发，非常有效。

3. 迭代开发：用 PingCode 的集成能力做实验追踪

PingCode 支持与代码托管平台和 CI/CD 系统集成，这个能力在探索型需求上有一个特殊用法：实验分支的管理。

当一个用户故事本质上是实验而不是功能时，可以要求开发人员只在实验分支上做最小化实现，不与主分支合并，通过 Feature Flag 或独立环境上线给一小部分用户。PingCode 的开发面板可以追踪到这些实验分支的任务状态，但不会污染主干的交付节奏。

在站立会议上，Scrum Master 打开迭代任务板时，可以明确区分：哪些任务是“实验性”的（目标是收集数据、目标用户限定），哪些是“确定性”的（目标是稳定交付、面向全部用户）。两者并存在同一个看板上，但管理方式和验收标准完全不同。

4. 进度跟踪：把“验证结果”纳入迭代概览

PingCode 的迭代概览页面提供了燃尽图、任务完成比例等进度跟踪指标。这些都很好，但它们默认衡量的是“任务做完了没有”。对于探索型需求，我建议团队在迭代概览上额外手工维护两个指标：

• 假设验证完成率： 本轮设定的关键假设中，已获得数据支撑（无论证明或证伪）的比例。
• 信息产出密度： 影响下游决策的结论数量除以本迭代投入的人天数。

这两个指标可以用 PingCode 的自定义字段或者 Wiki 模块来手动记录。它们的意义在于给管理层的汇报提供另一种叙事：“这个迭代我们没有交付完整功能，但我们获得了三个关键决策依据，将直接影响下个月 60% 的研发资源分配。”如果管理层能接受这种叙事，团队才能真正摆脱“唯交付论”的束缚。

5. 评审与回顾：围绕假设做复盘

PingCode 内置了迭代回顾板，很多团队会在上面写“做得好”“做不好”“改进计划”。但要让回顾真正有用，需要把它和迭代初期的假设关联起来。

我建议团队在回顾时回答三个结构化问题：

1. 本轮迭代我们验证了哪些假设？结论分别是什么？（对照迭代计划会上的假设列表逐一复盘）
2. 哪个假设被证伪了？如果提前知道结论，我们会如何重新分配资源？（为下一轮迭代提供优先级调整的依据）
3. 验证方法的成本是否可以进一步降低？（优化实验设计能力）

这三个问题直接写进回顾板的对应区域，下次迭代计划时拿出来对照。持续做 3-5 个迭代之后，团队对“验证成本”的感知会变得非常敏锐。

六、快速验证的边界：什么时候“验不起来”以及怎么办

说了这么多验证驱动的好处，有必要明确它的适用边界。不是所有需求都能找到低成本的验证手段，有些情况下，验证本身的成本就接近开发成本，这时候强求“先验再建”反而会误事。

1. 基础能力建设类需求：验证很难前置

比如“把数据库从 MySQL 迁移到 TiDB，提升读写性能”，或者“搭建统一日志采集平台，为后续的数据分析做准备”。这类需求的特点是：它的价值要在长期运行中才能体现，而且短期内用户感知不到。

对于这类需求，验证驱动的思路不是“要不要做”（因为技术判断已经足够支撑），而是“做到什么程度可以先收到反馈”。比如你可以先迁移一个非核心业务模块，跑一个月看延迟和吞吐量的变化，再决定是否全面铺开。这本质上还是验证，但验证的不是用户价值，而是技术假设。

2. 合规与安全类需求：没有验证空间

支付系统、权限体系、数据脱敏、等保相关功能，这些需求没有“试一下看用户反应”的空间。一旦出问题就是事故。对于这类需求，瀑布流程中详细的前期文档和评审机制是必要的，因为它们是在降低法律和合规风险，而不是在验证用户需求。

这里的关键是不要把合规需求当成产品需求来讨论要不要做。合规需求没有“要不要”这回事，只有“怎么做更安全、成本更低”。这类需求放在交付轨上，走完整的瀑布或者类瀑布流程，完全合理。

3. 强依赖外部资源的验证：时间窗口和成本难以控制

有些验证需要依赖第三方数据接口、硬件设备、或者特定场景（比如线下门店、展会现场）。这类验证的机会窗口很窄，而且组织成本高。如果硬要“先验证再开发”，等实验条件准备好的时候，窗口可能已经过去了。

在这种场景下，我的建议是反过来：先做一个最小可用版本，抢在窗口期内上线，然后立刻采集数据。这个“最小可用版本”不是瀑布模式里的“完整版”，而是功能阉割到只跑通主链路、UI 可以丑、后台可以手工操作的版本。它介于传统开发和纯实验之间，适用于时间约束压过成本约束的场景。

4. 验证成本逼近开发成本时的取舍

这是最微妙的情况。当一个假设的验证方案本身就需要接近完整开发的工作量（比如需要打通三个外部系统、涉及复杂权限逻辑），团队可能会质疑：反正验和建的成本差不多了，为什么不直接建？

我的判断标准是：看这个假设被证伪之后的损失有多大。如果被证伪之后，不仅是这个需求白做，还可能拖累其他功能的上线节奏（比如占用了关键的技术资源、造成架构层面的技术债），那即使验证成本高，也值得先验。如果失败成本只局限在这个需求本身，且在可承受范围内，那直接开发也可以接受。

这需要产品负责人有一个明确的风险意识：我们不是在追求“零无效投入”，而是在追求“在可接受的代价范围内，尽可能减少系统性误判”。验证不是目的，降低决策风险才是目的。

七、从“做出来”到“做对事”：三件事从明天就可以开始

理论和方法论讲了很多，但真正推动改变的往往是几个具体的、低门槛的动作。下面这三件事，不需要你完成组织架构调整，不需要说服高管层改变考核方式，在自己的团队范围内就可以开始做。

1. 在下一个迭代计划会上，问三个问题

下个迭代开始之前，花 20 分钟，让团队成员一起回答：

• 我们这个迭代里最具不确定性的假设是什么？（只选一个，不要贪多）
• 如果这个假设是错的，我们的计划会受到多大影响？（给出具体的影响范围，比如“可能导致 2 个迭代的功能白做”）
• 有没有办法在这个迭代内，用一个人天以内的成本，先拿到一些数据来判断这个假设？（强迫思考最低成本方案）

如果团队对第三个问题有答案，那就把这个验证任务加到迭代里，优先级高于其他开发任务。如果没有答案，至少你们意识到了自己在“裸奔”，这份意识本身就有价值。

2. 在需求管理工具里，给每个史诗标注“验证状态”

无论你在用 PingCode、Jira 还是 Excel，在需求列表里加一个字段：“验证状态”。取值只需要四种：

• 未验证：这个需求背后的假设还没有被数据检验过。
• 已验证-通过：假设成立，可以进入交付。
• 已验证-未通过：假设不成立，暂停或归档。
• 不适用：基础设施、合规类需求，无需市场验证。

这个字段的存在本身，就是给每次需求评审时一个提醒：在进入开发之前，我们有证据表明这个方向对吗？一个没有数据支撑的“已验证-通过”标签，比“未验证”更值得警惕。

3. 建立一个“实验档案”，让失败的验证被看见

这是对组织文化的反向施压。把团队历史上所有验证失败的实验（比如那个拼团功能的低成本测试）记录在一个共享文档或 Wiki 里，包含：假设是什么、验证方法是什么、数据结果是什么、最终避免了多大的无效投入。

这份档案有两个作用：

• 对内： 帮助新成员理解“验证失败是好事”，降低团队对于“不开发等于没产出”的焦虑。
• 对外： 当管理层质疑“为什么这个迭代什么都没交付”时，你可以拿出这份档案说：我们在迭代里排除了一个高风险选项，这为公司节省了预估 8 万元的无效研发成本。用他们听得懂的语言，讲他们关心的数字。

PingCode 的 Wiki 模块很适合做这件事。实验档案的结构可以很简单：时间、假设、验证方案、数据结论、决策影响、避免的无效投入估算。每季度整理一次，就是一份团队知识资产。

最后我想说一句我在每次团队分享时都会重复的话：瀑布开发没有错，错的是我们把它当成唯一的选项。当你面对的是一个需要快速验证的产品方向时，请记住，你的目标不是做出一个完美的功能，而是用最便宜的方式搞明白：这条路到底通不通。搞明白这件事本身，就是最重要的交付。

从明天开始，在你的迭代列表里，至少放一个“验证任务”。它不需要一行代码，但它可能帮你省掉未来三个月的无用功。这，就是验证驱动的意义所在。