破局者序章：那个被瀑布和敏捷同时坑过的项目经理

凌晨一点的北京西二旗，互联网公司的写字楼还亮着零星的灯，张磊盯着电脑屏幕上的数据，后槽牙咬得发酸——他带的短视频新产品上线两周，用户满意度28.7%，7日留存率12.3%，公司投进去的900万推广费打了水漂，老板刚才在项目群里@他，让他明天上午去办公室做闭门汇报。他揉了揉熬得通红的眼睛，把屏幕上的数据截图发到自己的复盘笔记里，这是这个月他第三次做同一个项目的复盘了。

三个月前立项会上的场景还历历在目：老板拍着桌子说短视频是今年公司的战略赛道，要做“对标抖音的轻量级剪辑工具”，核心功能明确，开发周期定死3个月，上线后投流推广。当时张磊在互联网公司做了3年项目经理，之前带的都是ToB后台系统项目，一直用瀑布模式，交付稳、风险可控，他觉得这个项目功能清晰、需求明确，瀑布模式再合适不过——甚至都没提需求调研要不要加用户访谈，就接下了这个活。

瀑布的幻灭：按流程走，为什么还是崩了？

张磊后来翻自己当时写的项目计划书，才发现从一开始就埋下了祸根。立项会上老板拍板的“核心功能”，其实只是产品部几个经理拍脑袋想的：上传、剪辑、发布、关注、点赞，一共5个核心模块，至于目标用户是谁、核心痛点是什么、和竞品的差异点是什么，没人说得清楚。产品经理当时拍胸脯说“短视频功能大家都懂，不用调研那么细”，张磊也觉得没必要浪费时间，直接就按瀑布的流程走了：需求分析、设计、开发、测试、上线，一步接一步。

问题出在开发到第二个月的时候。那天产品经理突然冲进开发办公室，说老板昨天刷抖音看到别人加了直播功能，觉得我们这个产品必须有，不然没竞争力。张磊当时就急了：“我们现在在开发阶段，按瀑布的变更流程，要走影响评估、变更审批、计划调整，至少半个月，工期肯定赶不上。”产品经理撇了撇嘴：“老板已经签过变更单了，你就加进去吧，不就加个模块吗，没那么难。”

张磊拗不过，只能硬把直播模块塞进开发计划，把原本留给测试的时间又压缩了一半。接下来的一个月，开发团队天天加班，测试人员连用例都没写完就被拉去测功能，上线前一周的bug统计表上，严重级别的bug有27个，中等bug有103个。张磊当时跟老板汇报，说能不能推迟一周上线，把bug修完，老板说“推广费已经付了，渠道都谈好了，推迟一天损失几十万，必须上线”。

上线第一天的数据就崩了：服务器因为bug扛不住流量，直接宕机2小时，很多用户一打开APP就闪退，好不容易进去的用户发现剪辑功能卡得要死，发个视频要等5分钟，评论区里全是骂的。张磊当时带着团队连续一周每天睡4小时修bug，但杯水车薪，两周后的用户调研显示，满意度只有28.7%，留存率更是惨不忍睹，900万推广费砸进去，连个水花都没溅起来。

> 📌 电子版侧边栏：扫码观看张磊复盘当时立项会的录音片段（此处可插入音频超链接） > > 📄 纸书侧边栏：本章核心概念速查——瀑布模式：以线性流程为核心的项目管理方法，需求在前期冻结，后续变更走正式审批流程，适合需求稳定、变更少的项目。

张磊当时写了30页的复盘报告，把问题归结为“需求调研不充分”“变更管控不到位”，老板看了之后皱着眉说：“人家互联网公司都搞敏捷，你怎么不搞？瀑布这么老的方法，早就不适合互联网项目了。”张磊当时觉得有道理，第二天就报了CSM（认证Scrum Master）的培训班，学了两周考了证，回来就准备在公司硬推Scrum。

敏捷的陷阱：为什么套了框架反而更累？

张磊当时把Scrum的三大角色、五大事件、六大工件背得滚瓜烂熟，觉得只要按规则来，肯定能解决之前的问题。他开全员会宣布从下周开始转Scrum：团队拆成两个5人小组，每个小组配一个产品负责人（PO）、一个Scrum Master（SM），每天9点开15分钟站会，每个人必须讲“昨天做了什么、今天做什么、遇到什么障碍”，每两周一个迭代，迭代结束开评审会，给 stakeholders 演示交付的功能，最后开回顾会总结问题。

前两周还像那么回事，站会每个人都在发言，张磊还觉得自己推得快。但第三周开始就变味了：开发为了站会不暴露自己进度慢，故意把任务拆得特别碎，比如“写登录按钮的样式”“写注册页面的接口”，每天发言都是“昨天写了登录按钮，今天继续写注册页面，没有障碍”，15分钟站会10分钟就结束了，比原来的日报还省时间。张磊一开始还追问“真的没有障碍？”，开发笑着说“真的没有，都挺好的”，后来张磊也懒得问了，反正问了也问不出实话。

迭代评审会更是一言难尽。每次开评审会，老板、产品、运营、销售都来，张磊按照Scrum的规则，先讲这个迭代交付的功能，然后演示。演示到一半老板就打断：“这个颜色不好看，改红色。”“这个功能用户可能用不上，加个分享到朋友圈的功能。”“别人家都有会员体系，你怎么没有？”张磊当时想反驳说“迭代范围已经冻结了，变更要放到产品待办列表里排优先级”，老板白了他一眼：“敏捷不就是说要快速响应变化吗？你怎么这么死板？”

每次迭代结束，承诺交付的10个功能点，能完成6个就不错了，剩下的4个要么是老板临时加的，要么是开发说技术实现不了要改方案。团队怨声载道，原来下班就走的人，现在每个迭代最后三天都要加班到11点，原来还能周末双休，现在周末经常要过来修bug。张磊自己也懵：明明Scrum的所有规则都按书上来的，怎么落地就变成“站会变汇报、评审变走形式、迭代变加工期”了？

最崩溃的是上个月的迭代回顾会，张磊问团队“我们这个迭代有什么问题要改进吗”，开发组长苦笑着说“最大的问题就是别加需求了，我们再加班真的要猝死了”。张磊当时坐在会议室里，突然觉得自己特别可笑：学了那么多敏捷的方法，考了证，看了十几本书，结果项目比之前用瀑布的时候还烂。

那天他下楼抽烟，碰到了公司里的老项目经理李明，李明比张磊大十岁，在公司待了八年，带过传统软件项目，也带过互联网项目，平时话不多，但张磊一直挺佩服他。李明看他蹲在楼梯间抽烟，就递了一根过来，问：“听说你带的那个短视频项目黄了？”

张磊苦笑着点头：“可不是嘛，瀑布没做好，转敏捷也搞砸了，我现在都不知道该怎么办了。”

李明吐了个烟圈，慢悠悠地问：“你当初推瀑布的时候，有没有问过开发团队，那个剪辑特效的实现要多久？有没有问过产品，需求文档里的那些功能，用户真的需要吗？你后来推Scrum的时候，有没有问过运营，他们是不是真的需要两周看一次新功能？有没有问过团队，他们能不能接受每天开站会、每两周迭代一次？”

张磊愣住了，他当时推瀑布的时候，是觉得老板之前做的ToB项目都是这么走的，肯定没问题；推Scrum的时候，是觉得书上说敏捷适合互联网项目，肯定没问题，从来没问过团队、问过 stakeholder 的真实情况。

李明笑了笑，说：“我十年前刚做项目经理的时候，跟你一样，把PMP当圣经，什么项目都要按五大过程组、十大知识领域来，后来做个政府项目，需求方今天说要改个字段，明天说要加个报表，我按变更流程走了半个月，需求方直接找领导把我换了。后来我才明白，方法都是死的，人是活的，没有通用的项目管理方法，只有适配场景的工具组合。你之前用瀑布，不是瀑布不好，是你那个项目需求本来就不稳，你硬套瀑布，肯定崩；你现在推Scrum，不是Scrum不好，是你的团队没做好准备， stakeholder 也不懂敏捷，你硬套Scrum，肯定变味。”

> 📌 电子版侧边栏：点击查看李明分享的15年项目管理经验思维导图（此处可插入思维导图超链接） > > 📄 纸书侧边栏：核心命题提示——本书全篇围绕“场景优先”的破局思维展开，所有方法论讲解都会结合具体场景，拒绝空泛的概念堆砌。

张磊那天在楼梯间坐了很久，李明走的时候跟他说了一句话：“工具没有对错，只有合不合适。你以后做项目，先别想着我要用瀑布还是敏捷，先搞清楚三个问题：这个项目的需求稳不稳？你的团队能不能接受到底 stakeholder 要的是什么？公司能不能接受你试错？这三个问题搞清楚了，用什么工具都行。”

中级项目经理的集体困境：懂概念，却解不了实际问题

和张明聊完之后，张磊在公司内部做了个小调研，问了身边10个工作3-5年的项目经理，发现大家的情况跟他几乎一模一样：都考了PMP，很多人还考了CSM、ACP、Prince2，各种方法论的书看了十几本，Scrum的三大角色五大事件能倒背如流，看板的WIP限制、流动效率也知道是什么意思，但一到实际项目，还是各种问题：

有人带的ToB项目，需求明确，合规要求高，硬推Scrum，每次迭代都要走合规评审，效率比瀑布还低，最后项目延期了3个月，被客户投诉； 有人带的新产品项目，团队是第一次合作，没有敏捷经验，一上来就推完整的Scrum，站会、评审会、回顾会一个不落，结果团队天天开会，写代码的时间少了，迭代交付的东西bug一堆； 还有人带的运维项目，需求都是突发的，比如线上出问题了要马上修，硬套Scrum的迭代周期，结果迭代里的任务完不成，只能天天加班，团队怨声载道。

张磊后来查了PMI（项目管理协会）2023年发布的《项目经理职业发展报告》，里面有组数据让他很震撼：72%的中级项目经理认为“方法论与实际场景不匹配”是他们面临的最大痛点，这个比例比“不懂项目管理方法论”高了整整3倍；68%的中级项目经理表示“硬套框架导致项目效率更低”，甚至有31%的人表示“学了更多方法论之后，项目反而更难做了”[^1]。

这组数据其实并不奇怪：大多数中级项目经理都处于“知道是什么，但不知道怎么办”的阶段，懂各种方法论的概念，但不知道什么时候该用什么，不知道该怎么结合自己的场景调整，最后只能硬套框架，越套越累。就像张磊之前的状态，知道瀑布的流程，知道Scrum的规则，但不知道为什么要用，不知道自己的场景适合什么，最后只能把失败归结为“团队不行”“老板不支持”“需求方太傻逼”，从来没想过是不是自己的方法选错了。

这种困境其实本质上是“工具崇拜”的陷阱：很多人觉得只要学了足够多的工具，就能解决所有问题，就像一个人手里攥着锤子，看什么都像钉子，不管什么项目，上来就套自己最熟悉的方法，不管合不合适。但项目管理从来不是“选A还是选B”的问题，而是“怎么把A和B组合起来，适配自己的场景”的问题。

比如同样是短视频项目，某大厂的内容中台项目组，在立项之初先花了2周做用户调研，明确目标用户是18-25岁的大学生，核心需求是“10秒就能剪出适合发朋友圈的短视频”，然后根据场景组合了工具：用Scrum做迭代，每两周交付一个核心功能，用看板做任务可视化，限制在制品数量，站会只讲阻塞问题，评审会只邀请10个目标用户参加，不搞形式主义， stakeholder 的变更需求统一放到产品待办列表里排优先级，迭代期间不随便加。最后这个项目上线的时候，用户满意度达到65%，7日留存率达到28%，比张磊的项目好了一倍不止。

这个案例其实就说明了，没有最好的方法，只有最合适的方法：大厂的团队成熟度高， stakeholder 懂敏捷，能接受试错，所以可以用敏捷的组合；而张磊的项目，需求一开始就不清晰，团队是第一次合作，老板对敏捷的理解只有“快速响应变化”，硬套Scrum的规则，肯定要出问题。

> 📌 电子版侧边栏：点击查看大厂短视频项目组的方法组合全景图（此处可插入动态图表超链接） > > 📄 纸书侧边栏：避坑提示——很多项目经理在推敏捷的时候容易陷入“形式主义陷阱”：为了做敏捷而做敏捷，把站会、评审会、回顾会当成任务来完成，忽略了敏捷的核心是“快速响应变化、持续交付价值”，反而比瀑布还低效。

破局思维的起点：场景优先，而不是方法优先

李明那天跟张磊说的话，其实点破了项目管理最核心的逻辑：所有的方法论都是工具，不是信仰，工具的价值只有在适配场景的时候才能体现。就像你给一个刚学会走路的小孩穿42码的篮球鞋，再贵的鞋也没用，甚至会让他摔得更惨。

那什么是“场景”？很多人觉得场景就是行业，是ToB还是ToC，是互联网还是制造业，但其实不是，场景的核心是三个要素： 1. 需求的稳定程度：你的项目需求是不是明确的？变化率有多高？比如政务系统、工业软件的需求，变化率通常低于10%，属于稳定需求；而创新产品、短视频、社交产品的需求，变化率通常高于30%，属于不稳定需求。 2. 团队的成熟程度：你的团队是不是第一次合作？有没有敏捷经验？能不能接受变化？比如一个合作了5年的老团队，大家配合默契，接受过敏捷培训，那推行敏捷的成本就很低；如果一个团队是第一次合作，之前都是做瀑布的，从来没接触过敏捷，那硬推Scrum肯定要出问题。 3. 组织的容错程度：你的公司能不能接受试错？出了问题会不会追责？比如互联网创业公司，容错率高，允许快速试错，那可以用更灵活的敏捷方法；如果是国企、政务单位，容错率低，出了问题要追责，那肯定要选更稳妥的方法。

这三个要素的不同组合，会形成完全不同的场景，对应完全不同的工具组合。比如：

• 需求稳定、团队成熟度低、组织容错率低的场景（比如传统企业的信息化项目）：适合用瀑布模式加阶段性敏捷评审，前期把需求定死，开发阶段按瀑布走，每到一个里程碑做一次小范围的用户评审，快速调整小的需求，既稳妥又能响应变化。
• 需求不稳定、团队成熟度高、组织容错率高的场景（比如互联网公司的创新产品项目）：适合用完整的Scrum加看板，每两周一个迭代，用看板限制在制品数量，快速交付、快速验证、快速调整。
• 需求不稳定、团队成熟度低、组织容错率中等的场景（比如中小互联网公司的新产品项目）：适合先从看板开始，先做任务可视化，限制在制品，提升流动效率，等团队适应了，再加迭代，慢慢过渡到Scrum，不要一上来就套完整的敏捷框架。

张磊后来把那个失败的短视频项目重新梳理了一遍，发现当时的场景其实是“需求不稳定、团队成熟度低、组织容错率中等”：一开始需求就没搞清楚，团队是第一次合作，之前都是做后台系统的，没做过C端产品，老板对敏捷的理解只有“快速响应变化”，硬套Scrum的规则，肯定要出问题。如果当时他先花两周做用户调研，把需求搞清楚，然后先从看板开始，做任务可视化，限制在制品，等团队适应了再加迭代，最后的结果肯定不一样。

> 📌 电子版侧边栏：点击进入场景化选型自测工具，输入你的项目参数，自动推荐适配的方法组合（此处可插入交互工具超链接） > > 📄 纸书侧边栏：本章核心总结——项目管理没有通用的“银弹”，所有的框架、方法都是工具，只有适配场景的工具才是好工具。中级项目经理的破局关键，不是学更多的框架，而是建立“场景优先”的思维，先搞清楚场景，再选工具。

后来张磊又接了一个新的短视频工具项目，这次他没急着推瀑布或者Scrum，而是先花了3天时间问了三个问题：需求稳不稳？团队能不能接受？公司能不能试错？然后根据调研结果，组合了工具：先花一周做用户调研，明确核心需求是“一键生成字幕”，然后用看板做任务可视化，限制每个开发同时只能做2个任务，每两周一个迭代，迭代评审会只邀请核心用户和产品负责人参加， stakeholder 的变更需求统一放到待办列表里排优先级，迭代期间不加新需求。这次项目上线后，用户满意度达到58%，7日留存率达到24%，虽然不算爆款，但比之前的项目好太多了。老板在会上表扬他，问他这次用了什么方法，张磊笑着说：“没什么特别的方法，就是先把场景搞清楚，再选工具。”

其实这就是全书想要传递的核心：我们见过太多项目经理，把瀑布当圣经，觉得按流程走就万事大吉，结果需求变了流程不管用；也见过太多项目经理，把敏捷当圣经，觉得套了框架就万事大吉，结果越套越累。但项目管理从来不是非黑即白的选择题，没有最好的方法，只有最合适的方法。而找到最合适的方法的前提，就是建立“场景优先”的破局思维，先搞清楚你手里的活是什么，你的团队是什么，你的公司是什么，再选工具，组合工具，甚至创造工具，最终的目标只有一个：把项目做成，把价值交付出去。

---

[^1]: 数据来源：PMI《2023年项目经理职业发展报告》，https://www.pmi.org/learning/library/project-management-future-2023

> 📌 纸书排版提示：本章小结可独立成页，方便读者快速回顾核心命题 > > 本章小结 > 1. 传统瀑布模式并非一无是处

张磊那天在公司楼下的台阶上坐了足足四十分钟，手机里妈妈下午发的消息还亮着屏：“儿啊，这周回不回家吃饭？你爸买了你爱吃的排骨。”他攥着手机回了句“这周加班，下周回”，熄了屏抬头看，对面写字楼的灯已经暗了一半，只有几盏还亮着，像极了他此刻的心情——熬了三个月的项目黄了，学了两周的敏捷也没用，他突然觉得自己学了那么多方法论，就像手里攥了一堆钥匙，却不知道哪一把能开自己面前这扇门。

直到李明递过来的那根烟烧到滤嘴烫到了手指，他才猛地回过神。李明手里还攥着半份十年前的政府项目变更申请单，泛黄的纸页上还留着当年他写的批注：“流程是给项目服务的，不是让项目给流程服务的

张磊那天在公司楼下的台阶上坐了足足四十分钟，手机里妈妈下午发的消息还亮着屏：“儿啊，这周回不回家吃饭？你爸买了你爱吃的排骨。”他攥着手机回了句“这周加班，下周回”，熄了屏抬头看，对面写字楼的灯已经暗了一半，只有几盏还亮着，像极了他此刻的心情——熬了三个月的项目黄了，学了两周的敏捷也没用，他突然觉得自己学了那么多方法论，就像手里攥了一堆钥匙，却不知道哪一把能开自己面前这扇门。

直到李明递过来的那根烟烧到滤嘴烫到了手指，他才猛地回过神。李明手里还攥着半份十年前的政府项目变更申请单，泛黄的纸页上还留着当年他写的批注：“流程是给项目服务的，不是让项目给流程服务的。”那是2015年李明刚升高级项目经理时接的某市社保系统升级项目，当时他也跟张磊一样，把PMP的五大过程组、十大知识领域当圣经，所有变更必须走15天的审批流程，需求方要加个“异地社保转移自动核算”的字段，他硬生生按流程走了半个月，需求方等不及直接找了公司领导把他换了，新项目经理上来之后只花了3天就上线了这个功能，整个项目还提前了5天交付，拿了当年的政府优秀信息化项目奖。

“我当时在家躺了三天，翻遍了市面上所有的项目管理书，没一本告诉我‘遇到这种情况该怎么办’，”李明弹了弹烟灰，笑着说，“后来我才想明白，所有的框架、流程、规则，都是别人总结出来的‘通用经验’，不是‘绝对真理’。你那个瀑布项目不是死在瀑布上，是死在你把瀑布当成了‘走流程的挡箭牌’，根本没把需求调研做实；你推Scrum也不是死在Scrum上，是死在你把Scrum当成了‘完成KPI的工具’，根本没考虑团队和 stakeholder 能不能接受。”

他指了指张磊手里的复盘报告：“你之前写的问题里，说‘需求调研不充分’，但你有没有算过，你当时花在需求调研上的时间有多少？10天？5天？还是只开了两次立项会，拍了个脑袋就完事了？你后来推Scrum的时候，有没有跟团队聊过，他们之前都是做瀑布的，能不能接受每天开站会、每两周改一次方向？老板说‘敏捷就是快速响应变化’，他知不知道快速响应变化的前提是团队有足够的能力， stakeholder 愿意给试错的空间？”

张磊翻了一下自己的复盘笔记，里面密密麻麻写了几千字的问题，但确实没提过这些细节。他当时带瀑布项目的时候，是直接套的网上的项目