我刚当上项目管理经理那会儿，接手了一个已经延期两个月的项目。 第一次站会，我问：“现在卡在哪里了？” 开发组长回了一句：“需求不明确，没法动。” 产品经理立刻反驳：“需求文档三个月前就确认了，你根本没看。” 我低头一看，Jira 上十几条 Story 都没人认领，Bug 页面堆了一百多个未分类的 issue。那一刻我突然意识到，，项目延期不是谁的错，而是一个系统的混乱。 五年后回想那个场景，我会跟…

我在过去几年里，帮助过一些团队从传统的瀑布模式转向敏捷，也见过一些团队在尝试 Scrum 后，又悄悄回到了按阶段推进的老路上。一个很深的感受是：这两种模式的好坏，不取决于方法论本身，而取决于你用它来解决什么问题。 去年有一家做汽车电子控制器的客户，他们的研发负责人说过一句话，我一直记得很清楚：“我们最怕的不是需求变了，而是变更单签完字以后，所有人都假装它没变过。”这很大程度上说出了困境的核心。如果…

资源从来都是不够的。这个认知，我们在那个季度开头就领教了。编辑团队因为家庭原因突然离职两人，社交媒体运营预算被砍掉40%，但流量目标反而上调了20%。老板说：“做减法，用更少资源拿到结果。” 这种场面，做过项目负责人的都懂。问题从来不在于“知不知道该做取舍”，而在于“你凭什么取舍”。 我们决定不再靠直觉拍板，而是用一场大型的内容实验，来回答这个致命问题。两个月内，我们并行测试了20种不同的内容策略…

资源从来都是不够的。这个认知，我们在那个季度开头就领教了。编辑团队因为家庭原因突然离职两人，社交媒体运营预算被砍掉40%，但流量目标反而上调了20%。老板说：“做减法，用更少资源拿到结果。” 这种场面，做过项目负责人的都懂。问题从来不在于“知不知道该做取舍”，而在于“你凭什么取舍”。 我们决定不再靠直觉拍板，而是用一场大型的内容实验，来回答这个致命问题。两个月内，我们并行测试了20种不同的内容策略…

一个做了八年交付的项目经理跟我说过一句反常识的话：“如果一个项目从来没着过火，要么是你只接风险极低的活，要么是你根本没看清哪里在冒烟。” 我当时觉得这话有点绝对，直到自己带项目踩了足够多的坑，才明白他说的不是“喜欢救火”，而是任何复杂到值得做的项目，必然存在无法在计划阶段穷尽的变量。“救火”不是例外，是常态。而老手和新兵的分水岭，就在于火着起来的那一刻，你的决策逻辑，，是凭本能猛扑上去，还是先识别…

去年秋天，我旁听了一场项目复盘会。一个投入超过八个月、横跨产品、研发、运营和市场四个核心部门的新功能上线项目，最终用户留存数据比预期低了将近40%。会议桌上，每个部门的代表都在复盘报告里找到了自己“做得不错”的部分，而把失败的主因归给了“跨部门沟通不畅”。这个说法听起来无比正确，也无比安全，，仿佛只要沟通没问题，项目就能成功。但真正让我警觉的是，所有部门都默契地避开了五个更深层的问题。不是他们没看…

去年秋天，我们产品团队差点因为项目管理工具的选择分裂成两个阵营。前端组坚持留在 Linear，后端组想退回 Jira，设计师和运营已经在 Notion 里自建了第三套看板，而老板听到每月花在工具上的 license 费超过 8000 块，丢下一句“你们统一一下”。于是我们做了件现在回想起来都觉得头铁的事：停掉所有项目，两周内集中试用市面 10 款工具，从轻量到重型，从研发到通用，最终选出一款让全员…

我们复盘了经手的50个项目，本想提炼一套“成功公式”，结果却只做了一件事：对着事故档案，把所有差点让项目死在半路的瞬间重新剖开。 最意外的发现是，导致严重延期、预算击穿、甚至最终无法交付的头号因素，不是技术难，不是需求变，也不是沟通问题，，这些早就在预期之内。真正把项目逼到墙角的，是三个当时所有人都没在意、直到灾祸成型才恍然大悟的风险。它们安静、隐蔽，而且几乎很难在传统的风险管理清单上出现。 接下…

“我们最后被迫在Sprint计划会上拿出了一份甘特图。”两年前，一个支付平台项目的技术负责人这样对我说。当时他的团队正在尝试完全拥抱Scrum，但业务方要求在需求冻结（freeze）之前拿到监管申报的关键里程碑承诺，而监管接口的联调又依赖于另一个银行的主机改造计划，，那是一份18个月前就排定的瀑布式版本地图。他意识到，如果不把这两套逻辑并轨，项目注定失控。后来他们的做法是：保留三个Scrum团队做…

我的项目管理生涯是从一场惨败开始的。那时我刚从开发转岗，踌躇满志地接手了一个内部CRM系统的重构项目。老板拍着我肩膀说：“这个小项目，给你练练手。”我心里想的也是：需求明确、团队熟悉、技术栈成熟，这能有啥难的？两个月后，项目延期了整整四周，交付的当晚，核心数据库因为一个数据迁移脚本的疏漏，把近三年的客户跟进记录全改成了乱码。整个销售团队第二天集体停工。我记得那天凌晨三点，我一个人坐在空荡荡的办公室…