如何用第一性原理破项目“延期”的局

一、什么是“第一性原理”

“第一性原理”这个概念最早由亚里士多德提出，后来被埃隆·马斯克带火。简单来说，它是一种“透过表象，看透本质，然后从本质出发重新思考”的思维方式。

2002年，马斯克想去火星。他去俄罗斯买火箭，结果一问火箭太贵了，一枚要6500万美元。

这时候，如果用“类比思维”，大部分人会这么想：

• “火箭这东西本来就很贵。”
• “这是高科技，那是国家举国之力造的，贵是合理的。”
• “既然买不起，那就算了吧，或者我想办法去筹更多的钱。”

大部分人的思路逻辑：在现有的框架下找最优解。

但马斯克用“第一性原理”，他没有看火箭的报价，而是问了一个本质问题：
“一枚火箭到底是由什么组成的？”

他把火箭拆解到了物理学的基本层面：

• 它是航空级铝合金、钛、铜和碳纤维。
• 它需要燃料、密封件、电子芯片。

然后他去查了金属交易所的原材料价格。
结果让他震惊：这些原材料的成本，仅仅是火箭成品售价的2%！

那剩下的98%去哪了？
去了繁冗的供应链、层层外包的利润、由于技术陈旧导致的低效、以及“它本来就该这么贵”的惯性思维里。

于是马斯克得出了结论：只要我自己买原材料，自己研发，不外包，我就能把火箭价格降下来。

后来的故事大家都知道了，SpaceX把火箭发射成本降低了近10倍，甚至做出了可回收火箭，彻底改变了航天史。

这就是第一性原理的魔力：它不相信“一直如此”，它只相信“原本应该”。

二、PMO如何用“第一性原理”破局延期

在PMO和项目经理的日常中，最经常听到的一句话就是研发说：“这个需求太复杂，这个迭代肯定做不完，至少要两个礼拜。”

通常此时，你有四个选择：

1. 求研发：“哥，加加班吧，老板盯着呢。”（配套买奶茶走人情路线）
2. 找老板加人：“老板，这需求评估交付时间太久，帮忙加个人来支持下吧”（加人加的是成本，老用这招老板也不爽）
3. 砍需求：“那把这个功能砍了吧。”（业务和产品要和你掰扯）
4. 延期：“那我跟老板申请延期。”（显得你很无能）

这就是典型的“类比思维”——遇到问题，只在时间、范围、资源这三个显性维度上做加减法。

今天，我们用第一性原理把这个问题像剥洋葱一样剥开。当你不再把“需求”看作一个不可分割的整体，你会发现，所谓的“做不完”，往往是个伪命题。

什么是这个问题的“第一性原理”？

当研发说“排期很久”时，我们在物理层面上到底面对着什么？
回归交付时间的本质：

如果交付时间被锁死，分母（生产率）很难短期改变（加人也没用，还要磨合），那核心矛盾就在分子（工作量）上。

很多PMO的误区在于：认为“需求 = 工作量”。
第一性原理的真相是：需求是“用户的目标”，而工作量是“实现目标的路径”。 路径有无数条，研发往往默认选了最宽、最平、但也最远的那一条（完美技术方案）。

我们要做的，不是砍“目标”，而是换“路径”。

第一步：拆解原子，用MVP思维做减法

MVP（最小可行性产品）不是砍功能，而是降低技术实现的复杂度颗粒度。

很多时候，研发评估的“来不及”，是因为他们把“造一辆法拉利”的时间算进去了，而业务其实只需要“一块滑板”就能验证闭环。

比如产品说：“我要一个积分兑换系统。”研发评估：“要建积分表、商品表、兑换记录表，要做并发锁，要做库存回滚，至少10天。”

第一性原理思考：这个需求的最小价值单元是什么？
在这个业务刚起步阶段，用户是真的需要一个“高并发、自动回滚的积分系统”吗？不，用户只是想“用积分换个礼品”。

这时候你可能会发现，如果不考虑高并发，不考虑自动化退款，只需要一个简单的数据库写入，排期从10天变成了1天。

PMO动作：

利用MoSCoW法则（Must have, Should have, Could have, Won't have），要求产品经理对需求进行进一步拆解和分级。

• Must have（必须有）： 砍掉它，流程就不通，系统就报错。这是生死线。
• Should have（应该有）： 没有它体验不好，但能用。
• Could have（可以有）： 锦上添花的功能。

“我知道这些都很重要，但如果两周后必须上线，我们只能带上这3个核心功能。剩下的作为二期迭代。你是要推迟一个月全上，还是两周后先让用户跑起来？”

项目的本质是什么？不是“按时上线所有功能”，而是“在约束条件下，最大化交付商业价值”。

策略：用MVP思维进行最小化价值单元拆解，聚焦核心价值。

第二步：质疑假设，寻找替代路径

研发评估时间长，往往是因为某个技术难点（瓶颈）卡住了。

例如，研发说：“这个功能需要重构老代码，否则后面维护很费劲，所以要很久。”
这听起来很合理，但这基于一个假设：我们现在的目标是交付完美的软件架构。

PMO动作：
深入技术细节，询问研发：“具体是哪个模块最耗时？”
如果是因为要重构老代码，或者要做一个酷炫的动效。

追问：

• “如果不重构，用硬编码或者临时方案顶上去，能不能先满足这次上线？”
• “这个实时数据报表太耗时，能不能先改成T+1的离线数据？”

策略：技术分期付款”，根据项目所处的阶段适当地欠债（临时方案），在验证价值后偿还（重构），这才符合商业逻辑的。

（以上前提是要和技术产品业务负责人沟通共识，如果要保上线时间，那就要接受当前的临时方案带来的其它问题，后期在逐步迭代优化）

第三步：优化关键路径

有时研发评估时间周期比较长，是因为他们是按照前置依赖工作就绪的串行时间来评估的。例如，等UI图、等接口文档、等环境资源。

PMO动作：
梳理项目的关键路径。
如果后端开发是瓶颈，那就看能不能让前端先用Mock数据并行开发？
如果测试是瓶颈，能不能引入自动化测试或者在此次迭代只做冒烟测试+核心用例回归？

策略：评估哪些事情可以并行执行，哪个是最长依赖路径，只有分析清楚上下游依赖和关键路径，才能更有效的优化路径。

第四步：回归目的

有时候，研发评估时间长，是因为需求本身的逻辑就很绕。
比如：“需要在用户下单后，根据地理位置、天气、库存、VIP等级四个维度计算运费。”研发一看头都大了：“这算法太复杂，要一周。”

第一性原理思考：
回到最原点：我们为什么要做这个功能？
是为了“精准计算运费”吗？不，是为了“不亏本”或者“提高转化率”。

往往你会发现，一个复杂的逻辑需求，最后可以用一个运营策略或人工配置来替代，开发工作量直接归零。

策略：用业务规则的简化，来换取技术实现的降维。

第五步：机制流程上是否有问题？

解决了一次延期只是“止痛药”，如果这个项目经常反馈需求来不及要延期，PMO要开始寻找造成这个问题的根本原因进行“开药方”。需求反问：

• 为什么排期不够？

  -> 因为需求评审通过太晚。

• 为什么评审太晚？

  -> 因为产品需求变来变去。

• 为什么变来变去？

  -> 因为业务方没想清楚。

• 为什么没想清楚就提需求？

  -> 这才是根因。

策略：优化长效机制，需求如果不清晰、原型不全、逻辑不自洽，研发有权拒绝进入排期。把压力传导回上游，而不是在下游通过挤压研发时间来解决。

有时候需求延期或许不是研发的问题，而是上游没有想清楚的问题，如果发现了这样的问题，要及时通过流程机制来确保到研发的需求是想清楚的、价值明确的需求。

结语

当研发抛出“需求交付要延期”时，不要惊慌，更不要愤怒，也不要只会在需求单上改时间。请用第一性原理，进行灵魂提问：

1. MVP拆解：

   这真的是最小单位吗？能不能先把壳子做出来，先最小化跑起来？

2. 路径重构：

   只有这一种技术实现方式吗？是否有其它路径？

3. 优化关键路径：

   哪个模块，哪个功能，具体哪里耗时比较久？最长路径是哪里，能否优化？

4. 价值回归：

   我们一定要通过写代码解决这个问题吗？调整策略规则行不行？

5. 机制约束：

   是不是前期业务、产品没有想清楚，需求来回变更导致研发时间不够？需求价值真的很大吗？投入和收益ROI评估过吗？

用第一性原理看透本质，用MVP思维聚焦价值，用柔性手段处理冲突。

作为PMO，在项目过程中遇到风险千万不要怕，困难越多、冲突越多、麻烦越多时，才是体现项目管理价值的时候，把这些困难当成职业生涯宝贵的案例库，在化解一次次的麻烦中，项目管理水平才能够得到锻炼和提升，在遇到各种复杂项目时才能游刃有余，从从容容。

按时交付很重要，但交付正确的东西更重要。世界上没有“做不完”的需求，只有“这个需求范围下、在这个时间点、用这种技术方案、按照这种顺序、满足这种质量标准、配套这种策略规则”做不完的需求。改变其中任何一个变量，或许路就通了。

（完）

关联阅读：

PMO项目管理十问