AI时代新型项目管理应如何构建？

用AI写了两个月代码，项目反而延期了。不是AI写得慢，恰恰相反，写得太快了。快到每周产出的代码，下一周要推翻一半重写。 这不是个例。我带团队转型AI下来，观察到一个很反直觉的现象：AI把代码生产成本打到了地板，项目管理成本反而涨了。涨得不是一点半点，是量级上的差异。 原因说起来也简单：传统项目管理管的是"能不能按时做完"，AI项目管理管的是"做的东西到底对不对"。这两件事需要完全不同的管理工具，但大部分团队还在用老办法管新问题。 变更管理，永恒的难题 在展开之前，得先说一个事实：AI时代项目管理面临的核心难题，并不新鲜。变更管理一直是项目管理的最大难点之一，变更是导致项目失败的主要原因。这句话不是我说的，是项目管理教材里写的，是几十年的行业经验总结。 传统项目是怎么对付变更的？靠摩擦力。 传统方式的变更管理九步骤：提出变更要书面记录、找客户签字确认、分析对范围进度成本的影响、沟通变更影响看能不能取消、审批人签字批准、开变更控制会议、执行后跟踪状态。每一步都在人为增加变更的摩擦系数。 这个设计的本质很聪明：让变更变得困难，客观上就降低了变更的频率。以前改一个功能，要跟开发沟通、评估工作量、排期、等开发有空，一两周过去了。沟通成本、等待成本、协调成本，这些就是摩擦力。大部分变更在摩擦力面前就自然消亡了，因为不值得。 AI把这个摩擦力打没了。 跟AI说一声，下午就能改出来。没有沟通成本，没有等待成本，没有协调成本。代价越低，改动越频繁，方向漂移就越严重。 这个判断是反直觉的：AI降低了改代码的成本，但提高了改对的成本。每次改动都可能偏离原始意图，偏离的积累速度远超想象。极简项目管理里有一句话放到现在依然成立：如果你允许变更随意发生，那么它变化的速度将超过你的想象。 我们团队经历过一个极端案例：一个后台管理模块，两周内被改了15次。不是因为需求不清楚，恰恰因为太清楚了，每天都能想到新的优化点。AI让"改一下试试"的成本几乎为零，团队就陷入了一种改动惯性，看到能改就改，没人停下来想"到底该不该改"。 问题回到了原点：摩擦力没了，怎么管变更？答案不是恢复摩擦力（那是开倒车），而是换一种方式锚定方向。 但这里有个容易被忽略的另一面。摩擦力消失不只是风险，也是机会。 需求变更不再是需要抵抗的事，而是竞争优势的来源。前提是你的需求文档是结构化的。业务说"审批规则改了，超过2天就要总监审批"，你打开判定矩阵，改一个数字，相关的流程图、状态机、测试用例全都更新一遍，半天搞定。竞争对手改一个需求要20天，你2天。客户下次找谁？找你。 所以AI时代的变更管理不是"怎么挡变更"，而是"怎么在快速响应变更的同时不丢方向"。这两个目标看起来矛盾，其实可以兼顾：靠结构化文档解决响应速度，靠场景剧本解决方向锚定。 从PRD到场景剧本 我试过很多办法控制方向漂移，目前最有效的一个是把PRD改成场景剧本。 区别在哪？PRD描述"系统应该做什么"，场景剧本描述"用户怎么用"。 举个具体例子。传统PRD会写"支持微信一键登录"，场景剧本会写"小明在地铁上打开APP想查昨晚的订单，从微信登录一键授权后直接进订单列表页，3秒内完成"。差别在于：PRD给的是功能点，场景剧本给的是一段有上下文的完整故事。 上下文才是关键。AI生成代码的能力很强，理解意图的能力并不强。你给"支持微信登录"和"地铁上3秒内完成登录"两个描述，AI产出的代码质量天差地别。前者给你一个标准OAuth流程，后者会考虑网络不稳定下的降级策略、加载状态、超时重试。 场景剧本还有另一个价值：它天然就是变更管理的锚点。传统变更管理靠流程摩擦来卡变更，场景驱动靠场景本身来判断变更。当有人提出一个新需求时，不需要走九步流程审批，只需要问一个问题：这个变更偏离了已有场景吗？偏离了就走变更流程，没偏离就是场景内的自然迭代。 但这里有个实操层面的心得。项目管理里有一条原则到AI时代依然好用：决不让步，除非交换。客户提变更，你同意了，那就得让他也在别的地方让步。不是为了为难客户，是为了让客户意识到变更是有成本的，哪怕技术成本几乎为零，它也有时间成本、测试成本、方向成本。客户越清楚这一点，提变更时就越谨慎。另外一条也值得记住：忠告不如警告。跟客户说"这个变更可能影响进度"，客户会觉得你在推诿。说"这个变更上线后如果出了问题，影响面是XX"，客户就会认真想了。 但这里有个trade-off必须说清楚。场景驱动开发能管住方向，代价是前期投入显著增加。写一个场景剧本比写功能列表费时得多，它要求PO不只想着"做什么"，还要想清楚"用户在什么情况下用、期望什么结果、异常时怎么办"。这对PO的能力要求高了一个量级。 选场景驱动意味着放弃快速试错的可能，选敏捷迭代意味着接受方向漂移的风险。