PMP职场实战108问 · 第105问

三年前，我在一家中型互联网公司带一个企业级SaaS产品项目。客户是某连锁零售集团，要上线一套门店管理系统。启动会上，客户CTO拍着桌子说：“我们流程很规范，每个阶段必须签字验收，不接受迭代交付。”我点头答应，但转头跟团队开内部会时说的是另一套话：“兄弟们，稳着来，但别真按瀑布走——先做个最小可用版，下个月必须让采购看到真东西。”

为什么这么拧巴？因为那个项目，是我第一次被“两套方法论”撕扯到失眠的案例。

会议室里的两张面孔

刚开始，我们真按瀑布推进了。需求文档写了120页，客户业务部签了字。可写到第30页时，采购部经理突然跳出来说：“你们这流程不对，退货审批怎么要三级？我们实际上只有一级。”问题在于，签字的是业务部，干活的却是采购部。典型的大型组织“签字者不用，用者不签字”。

如果死守瀑布，等全部需求冻结再开发，至少浪费两周返工。但硬改敏捷，客户CTO每天早上站在白板前指着用户故事追问“这个做完了吗？”——他受不了这种“不明确”的状态。

我做了个妥协。表面走瀑布：有阶段门、有里程碑、有签字确认。但内部开发跑双周迭代，每次迭代交付一个可演示的功能子集。对外，我把这些迭代叫“阶段验证版”，客户CTO觉得那是阶段评审的产物；对内，团队知道我们正在调优优先级。

这就是我理解的“混合”——不是各取一半，而是让同一个流程在不同人眼里长不同的脸。

踩过的坑才叫教训

第一个坑是文档。我让团队写迭代计划时，才发现按瀑布模板写出40页的计划书根本跑不通。WBS分解到第三层，需求已经变了。后来我发明了一个土办法：只写两页纸的迭代目标，但保持一份“伪瀑布”的甘特图挂在墙上。甘特图上的里程碑是固定的，但每条横线背后的具体任务清单是活的。客户来看，指着图说“嗯，7月15日功能冻结，没问题”；我团队知道，“冻结”只是不再改界面布局，但后端算法随时可以更新。

第二个坑是变更管理。按瀑布，变更要走CCB（变更控制委员会），审批至少一周。但有一次，运营部门发现竞品上线了一个“扫码即会员”功能，要求我们两周内必须跟上。我跟客户CTO摊牌：走CCB来不及，我直接让开发插了一个迭代。CTO犹豫了一下，说：“行，但别跟我说细节，就说在‘需求池里评审过了’。”

你看，混合模式里，有些信息不需要所有人都知道。 不是欺骗，是用不同的颗粒度去对齐不同角色关心的东西。CTO关心风险可控，我关心响应速度。

我自己用的那个工具

每次项目切换混合模式时，我都会在项目启动会上手画一张图，不是PPT里的，是一张大白纸上的两个圈。

左边的圈叫“承诺区”，里面写着固定需求——比如满足法规的报表、必须对接的第三方API。这些用瀑布锁死，变更必须经过价格谈判。

右边的圈叫“探索区”，放着那些“听起来很美但谁也没做过”的功能——比如AI推荐算法、门店自动补货的阈值。这些走敏捷，每两周展示结果，能用的合并，没用的砍掉。

为什么这个工具好用？ 因为画完图之后，我会问客户和团队一个问题：“我们现在要在哪个区花力气？”这个问题的价值，是逼所有人承认：不是所有需求都值得被冻结，也不是所有东西都要边做边改。真正落地混合模式的人，不是技术选型，而是需求分类。

最后说个反常识的判断

我见过太多团队在“瀑布还是敏捷”上纠结，最后卡在方法论之争上出不来。其实落地模式的选择，本质不是技术问题，是信任问题。

如果客户（或上司）对你不信任，你推敏捷，他会觉得你在耍滑头；你守瀑布，他会觉得你效率低。更务实的做法是：用瀑布的仪式感去建立信任，用敏捷的灵活性去换取时间。等信任建立起来了，再逐步把仪式感藏起来——把站会时间从15分钟压缩到5分钟，把评审会从全员参加改成只叫关键决策人。

那个SaaS项目最后延期了两个月，但不是因为方法论，而是因为客户的CEO在第三个月把预算砍掉了30%。但即使如此，我们在延期时间内交付了核心功能，客户CTO在验收时说了句：“我知道你们跑得快，只是没跟我说而已。”这句话我记到现在。

📌 今日动作：拿出你当前的一个项目，在纸上画两个圈：承诺区和探索区。把需求清单分到两个区，要求每个需求必须有“为什么它属于这个区”的理由。然后对照实际进度，看你的投入比例是否和分类匹配——我猜你会发现问题。

📚 返回 PMP职场实战108问 目录 →