职场工具箱之项目铁三角：范围、时间、成本——你最多只能锁住两个

简短大纲

1. 扎心场景：全都要，全都烂

Sprint 规划会上，产品经理拿着 PRD 说："这个迭代就三个功能，不多。"

你看了看，确实不多。评估了一下，两周能搞定。你点了点头。

然后——

第 3 天，产品说："对了，这个列表页能不能加个筛选？很简单的。"

你想了想，确实不复杂，加吧——反正"就一个小需求"。

第 5 天，领导在群里转了一条客户反馈："这个导出功能能不能支持 Excel？客户说 CSV 不好用。"

你叹了口气，改吧。

第 8 天，产品又来了："老板说竞品有个批量操作，咱们也加上吧，不然演示的时候不好看。"

你心里已经在骂了，但嘴上说："行，我看看。"

第 14 天，上线日。

你加了 5 天班，功能从 3 个变成了 8 个。测试覆盖不全，有两个 bug 被漏到线上。产品不满意："怎么这么多 bug？"领导不满意："怎么还是延期了？"客户不满意："这个导出格式不对啊。"

你最不满意——明明是他们一个一个加进来的，最后挨骂的是你。

小白提示：Sprint 是敏捷开发中的一个迭代周期，通常 1-2 周。PRD 是产品需求文档(Product Requirements Document)。

这个故事的名字叫 Scope Creep——范围蔓延。它不是一次性爆炸，而是温水煮青蛙。每一个"顺手加一个"都不大，但加在一起，就是一场灾难。

我见过太多项目，不是死在技术难度上，而是死在"范围失控"上。代码写得再漂亮，架构设计得再优雅，如果你连"到底要做什么"都管不住，最后就是一锅粥。

但范围蔓延只是表象。更根本的问题是：整个团队都以为范围可以无限膨胀，而时间、人力和质量不受影响。

这违反了项目管理里最基本的一条物理定律——铁三角。

2. What：项目铁三角

2.1 三条边，一个中心

铁三角(Iron Triangle)，也叫项目管理三角形(Project Management Triangle)，是 1969 年 Martin Barnes 博士提出的经典模型。道理不复杂，复杂的是你敢不敢认账：

三条边：

• 范围(Scope)：做多少东西——功能数量、完成度、交付范围
• 时间(Time)：花多长时间——工期、里程碑、截止日期
• 成本(Cost)：花多少钱——人力、硬件、外包、加班费

中心：

• 质量(Quality)：做到什么水平——代码质量、测试覆盖、用户体验、系统稳定性

铁三角的核心定律：

三条边互相制约。你可以锁住其中两条，但第三条必须当变量。如果你强行锁死三条边，崩塌的就是中心——质量。

用程序员的话说：这是一个三变量方程，你有两个自由度。想同时固定三个变量？那你的方程无解——或者说，解就是"一团糟"。

这里的"锁死"我多解释一句，很多人第一次看到会懵。

锁死，就是你提前拍板说"这条边不许动"，并且后面真的不允许它动：

• 锁死范围：功能清单定了, 不能砍、不能降级、不能拆两期
• 锁死时间：上线日期定了, 不能延期
• 锁死成本：人就这么多, 不能加人、不能加班、不能外包(本质都是加成本)

你最多只能锁两条边, 第三条必须当变量。否则变量会以一种更隐蔽的方式出现——从质量里扣。

给你 3 个很具体的例子:

1. 锁死时间 + 成本, 那范围就得动
2. 时间锁死：两周必须上线
3. 成本锁死：3 个人, 不能加人不能加班

4. 这时产品说"再加 5 个功能", 你只有两条路:

   • 砍范围：只做 3 个核心功能, 剩下下个迭代
   • 或者不砍范围 → 质量被迫下降：单测不写、灰度不做、review 走过场, 最后 bug 满天飞

5. 锁死范围 + 时间, 那成本就得动

6. 范围锁死：这 10 个功能必须全做
7. 时间锁死：下月发布不能动
8. 那你就得承认：成本要上去(加人/外包/加班/买工具)

9. 如果你还要锁死成本, 那就是把质量当成"隐形变量"

10. 锁死范围 + 成本, 那时间就得动

11. 范围锁死：功能必须全做
12. 成本锁死：就这 3 个人
13. 那就只能 延期，或者拆两期(本质也是时间在动)
14. 如果你不让延期, 还说"必须按时上", 质量照样塌

2.2 四个旋钮的关系

把铁三角想象成四个可以调节的旋钮：

关键：这四个"旋钮"不是各拧各的，它们是联动的。你把一个拧死不动，另外两个就得出来补位；你把三个都拧死，最后只能拿质量来买单。

• 想在固定时间和成本下做更多(范围↑)？→ 质量必然下降
• 想在固定范围和质量下更快交付(时间↓)？→ 成本必须上升(加人/加班)
• 想在固定时间和范围下省钱(成本↓)？→ 质量必然下降

没有例外。

2.3 质量不是"第四条边"，是"地板"

很多人把质量画成铁三角的第四个维度，好像它跟范围、时间、成本是平级的。

我不同意。质量不是一个可以主动"选择调低"的旋钮，它是前三个旋钮拧过头之后率先崩塌的那面墙。

你不会在项目计划里写"本迭代质量目标：60 分"。但你会在不知不觉中制造出 60 分的质量——当你同时说"范围不能砍"、"工期不能延"、"人不能加"的时候，质量就是那个被默默牺牲的变量。

它的崩塌不是立刻的，而是延迟的：

• 代码没写单测 → 现在省了 2 天，三个月后每次改动都心惊胆战
• 上线没做灰度 → 现在快了 1 小时，出事时全量用户一起遭殃
• 文档没更新 → 现在省了半天，新人来了花一周才能上手

质量债务和技术债务一样：借的时候很爽，还的时候连本带利。

2.4 范围的两个敌人：Scope Creep 和 Gold Plating

在铁三角里，"范围"这条边是最容易被偷偷拉长的。拉长它的有两个力量：

说白了：Scope Creep 是别人塞给你的，Gold Plating 是你自己加戏的。 两个都在偷偷拉长铁三角的范围边，但后者更隐蔽——因为你觉得自己在"做好事"。

小白提示：Gold Plating(镀金) 是项目管理术语，指开发人员主动添加客户没要求的功能或优化。就像你给客户订了个蛋糕，客户说要巧克力味的，你非要加个金箔——好看是好看，但人家没要，你还多花了钱和时间。

2.5 Scope Baseline(范围基线)：铁三角的"锚点"

铁三角要管用，你得先有一个参照物——范围基线(Scope Baseline)。

范围基线就是一份"我们说好要做什么"的书面记录。它不需要多正式，但必须满足三个条件：

1. 写下来了(不是口头说的)
2. 双方确认了(不是你单方面理解的)
3. 有版本号(改过几次、每次改了什么，有迹可查)

你可以把它理解成代码里的 git tag：这是 v1.0，这是我们约定的交付物。后面要改，可以，但得走变更流程，不能直接 force push。

没有基线，你就没法说"这个是新加的"；没有基线，铁三角的三条边就是空的——你连"范围到底多大"都说不清楚，怎么评估时间和成本的影响？

3. Why：为什么"全都要"注定失败？

3.1 项目管理的"能量守恒"

如果你学过物理，你知道能量守恒定律：能量不会凭空产生或消失，只会从一种形式转化为另一种。

项目管理有类似的守恒：总工作量 ≈ 范围 × 质量标准 / (人力 × 效率)。时间是另一个硬约束。

当老板说"范围不能砍、工期不能延、人不能加"的时候，他不是在做决策，他是在否认物理定律。结果只有一个：团队会自发地找到一个"可以压缩"的变量——通常是质量。

代码不写测试了。Code Review 走过场了。灰度直接跳过了。文档"下个迭代再补"(永远不会补)。这些不是团队不负责，是团队在"全都要"的不可能条件下做的求生反应。

3.2 "加人就能加速"的幻觉

面对铁三角的挑战，最常见的反应是"加人"。

Frederick Brooks 在 1975 年就把这个幻觉拆穿了——《人月神话》的核心观点：

往一个延期的项目里加人，只会让它更延期。

为什么？

1. 沟通成本：n 个人的沟通路径是 n×(n-1)/2。3 个人有 3 条路径，6 个人有 15 条，10 个人有 45 条。人越多，花在对齐上的时间越多。
2. 上手成本：新人需要时间了解项目。在他产出之前，老人要花时间带他，产出反而下降。
3. 分工粒度：不是所有工作都能并行。"一个女人怀孕要九个月，九个女人怀孕不能一个月。"

加人在某些条件下有用(任务高度可并行、接口清晰、新人有经验)，但它远不是万能的。"加人"不是免费午餐，它本身就是一个需要评估的取舍。

3.3 "加班就能搞定"的代价

另一个常见的"解法"是加班。

短期加班确实能换一些产出。但加班有三个隐性成本：

1. 效率衰减：加班能顶一两天，但顶不了一两周。人一累，返工就会越来越多。
2. 质量下降：困了累了之后写的代码，bug 率远高于正常状态。还记得文章开头的场景吗？加班赶出来的功能，测试覆盖不全，上线就出 bug。
3. 人员流失：持续加班是团队流失的第一驱动力。人走了之后的招聘、培训成本远超过加班节省的时间。

加班是对未来质量和团队稳定性的透支。 偶尔用一次可以，当成常规手段就是饮鸩止渴。

3.4 "顺手加一个"为什么杀伤力这么大？

回到开头的故事。铁三角和 Brooks 定律是理论，但日常里真正让你死的不是理论，是一个词——"顺手"。

产品经理说"顺手加一个筛选"，他的心理模型是：这不就是加个下拉框吗？

但你知道，一个筛选意味着：

• 后端要加查询参数和索引
• 前端要加 UI 组件和状态管理
• 测试要加用例覆盖
• 如果筛选条件组合多了，还要考虑性能

"顺手"这两个字，是需求蔓延的头号伪装。它的杀伤力在于：每一个单独看都不大，但它们会叠加。 就像你背包里每次多塞一本书，单本不重，走到第五公里你就走不动了。

而你之所以全接了，是因为说"不"的成本太高。很多团队有一种隐性文化：说"不"等于不配合，等于态度有问题。 于是你学会了一个万能回答："行，我看看。"

"我看看"翻译成铁三角语言就是：我把范围这条边拉长了，但没有调整时间和成本，也没有告诉任何人质量会下降。

用程序员的话说：你的 Sprint 就像一个固定大小的数组，capacity 就那么大。你往里面 push 新元素，要么先 pop 一个出来，要么接受 overflow。没有第三种可能。

4. How：四种取舍策略

铁三角不是一个"限制"，它是一个"决策框架"。它告诉你：既然不可能全要，那就主动选择牺牲哪个。

4.1 策略一：固定时间和成本，调整范围

什么时候用：上线日期不能动(比如合同约定、市场窗口)，人力也没法加。

怎么做：砍需求。把 Must-have 和 Nice-to-have 分清楚，只做 Must-have。

举个例子：

老板："下周五必须上线演示版，不能加人。"

❌ 全都要版："好的，我加班搞。"→ 赶出来 8 个功能，3 个有 bug，演示翻车。

✅ 铁三角版："收到。时间和人力锁死，我来调范围。8 个需求里，演示核心路径只需要 3 个：用户列表、详情页、导出。其他 5 个砍到下个迭代。这 3 个功能我保证测试覆盖、演示流畅。"

这就是 MoSCoW 优先级排序发挥作用的地方——先把需求分成 Must / Should / Could / Won't，时间紧的时候只做 Must。

4.2 策略二：固定范围和质量，调整时间

什么时候用：功能必须完整、质量不能妥协(比如金融、医疗、安全相关)，但截止日期可以谈。

怎么做：延长工期。给出现实的时间评估，而不是"拍一个老板想听的数字"。

举个例子：

产品："用户权限系统必须做完整，不能半吊子。"

❌ 全都要版："两周能搞定！"→ 两周后只做了 70%，权限漏洞被测试打回，实际花了四周。

✅ 铁三角版："完整的权限系统包括角色管理、资源授权、审计日志、越权检测。按照质量标准(单测覆盖 80%+、安全扫描通过)，现实评估需要四周。如果只要核心的角色管理 + 资源授权，两周可以，但审计日志和越权检测要放到第二阶段。"

关键点：给出诚实的评估，比给出"老板想听的数字"再反复延期靠谱得多。 一次性讲清楚需要四周，比说两周然后延期三次好。

4.3 策略三：固定范围和时间，调整成本

什么时候用：功能必须做完、时间不能动，但可以投入更多资源。

怎么做：加人、加钱、外包——但要评估沟通成本和上手时间。

举个例子：

领导："下月发布必须包含国际化，这是战略方向。"

❌ 全都要版："现有 3 个人做国际化够呛……算了，加班吧。"→ 加班两周，团队怨声载道，上线后翻译漏了一堆。

✅ 铁三角版："国际化涉及前端文案提取、后端多语言配置、翻译管理、测试矩阵扩大。以现有 3 人在 4 周内完成，质量有风险。建议： A) 加 2 个外包做前端文案提取(最可并行的部分)，成本约 X 万 B) 翻译走专业翻译公司而不是自己翻，成本约 Y 万 这样核心团队专注后端逻辑和测试，4 周可以保质完成。"

注意：加成本不只是"加人"。找外包、买工具、用云服务、请顾问，都是"用钱换时间"的方式。关键是看哪种资源投入的 ROI 最高。

4.4 策略四：有意识地调整质量层级

什么时候用：所有人都知道这是一个"先上线再迭代"的 MVP 阶段。

怎么做：明确降低质量标准，但要让所有人知道"这是临时策略"，并记录技术债务。

举个例子：

创业公司 CTO："我们就三个月跑道，必须在下个月拿出 demo 给投资人看。"

✅ 铁三角版："明白。以下是我的建议—— demo 阶段的质量标准下调： - 不做自动化测试，手动冒烟覆盖核心路径 - 只支持 Chrome，不做跨浏览器兼容 - 数据库用 SQLite，不搞高可用 - 前端直接 hardcode 部分数据

但我会把所有降级项记录到技术债清单里，融资成功后第一个迭代专门还债。

⚠️ 风险：如果 demo 后直接上线运营而不还债，三个月内必出生产事故。"

这个策略能用，但有一个铁律："降级质量"必须是显性决策，不能是默认操作。 所有人——产品、领导、开发——都要知道质量被降级了，以及欠了什么债。否则 demo 版就变成了"正式版"，没有人会给你时间还债。

4.5 四种策略速查表

5. 实战：三个场景的铁三角分析

场景一：产品加需求——"这个筛选很简单，顺手加一下"

❌ 全都要版(范围↑，其他不动 → 质量崩)

产品："列表页加个按状态筛选？很简单的。" 你："行。"

第二天——"多选也加上？" 你："行。" 第四天——"客户还要按时间范围筛。" 你："……行。"

结果：原本 2 天的功能变成 5 天，测试覆盖不全，上线后筛选组合有 bug。

✅ 铁三角版(范围↑ → 明确调整时间或砍其他)

产品："列表页能加个按状态筛选吗？"

你："可以。我评估一下铁三角的影响。"

30 分钟后——

你："评估结果： - 单选筛选：+1 人天 - 多选 + 时间范围：+3 人天，还要加索引

目前迭代 buffer 只有 1 人天。选项： A) 只做单选筛选(+1天)，不影响上线 — 砍范围 B) 做完整筛选(+3天)，砍掉功能 C 以保住上线日期 — 交换范围 C) 做完整筛选(+3天)，上线延期 2 天 — 延时间 D) 放到下个迭代 — 砍范围

我建议 A，先上能用的版本。你觉得呢？"

关键：你不是在说"不"，你是在展示铁三角的约束，让产品做选择。

场景二：领导临时插入——"老板说这个必须有，下周演示"

❌ 全都要版(范围↑ + 时间锁死 + 成本不变 → 质量崩 + 人崩)

领导："批量操作功能必须有，下周演示。" 你："好的，我加班搞。"

结果：连续加班 4 天，批量操作勉强能跑，原来的核心功能测试被压缩，上线后两个 P1 bug。

✅ 铁三角版(接受范围↑ → 主动选择调哪条边)

领导："批量操作功能必须有，下周演示。"

你："收到，这个优先级很高。铁三角分析：

时间：锁死(下周演示) 范围：要加批量操作(+5 人天)

那我只能调成本或范围内部交换：

A) 做'演示版'批量删除(2 人天)，功能 C 测试压缩但核心用例保住 — 降质量标准(局部) B) 做完整版(5 人天)，功能 B 和 C 延期 — 交换范围 C) 从其他团队借 1 个人帮忙，3 天完成可演示版本 — 加资源

建议 A。风险可控，功能 C 测试压缩我会优先跑高风险用例。"

关键：把"我加班搞"替换成"这是铁三角分析，你选哪条边让步"。

场景三：客户改需求——"我们要的不是 CSV 是 Excel"

❌ 全都要版(范围变了，其他不调 → 延期 + 返工)

客户："导出要 Excel，不是 CSV。" 你(心里)：PRD 写的明明是 CSV…… 你(嘴上)："好的，我改。"

结果：改 Excel 花了 2 天(样式、合并单元格、大数据量内存)，排期挤压。

✅ 铁三角版(范围变更 → 明确代价)

客户："导出要 Excel，不是 CSV。"

你："理解。当时评审记录里定的是 CSV(附截图)。Excel 确实体验更好，但实现成本不一样。

铁三角影响： - 范围变更：CSV → Excel(+2 人天) - 时间选项：延期 2 天 或 砍另一个功能 - 成本选项：不变

推荐方案 B：本迭代先上 CSV(已开发完成)，下迭代补 Excel。理由——CSV 先解决'能不能导'，Excel 解决'导得好不好'，分两步走风险最小。"

关键：拿出范围基线(当时的评审记录)，证明这是变更而不是你搞错了，然后明确铁三角的代价。

6. 模板：让铁三角分析变成肌肉记忆

6.1 范围基线模板

在项目启动或 Sprint 规划时，用这个模板锁定铁三角的范围边：

【范围基线 v1.0】
项目/迭代：<名称>
周期：<起止日期>
目标：<一句话说清楚这个迭代要达成什么>

交付物清单：
1. <功能 A>：<简要描述> | 优先级：Must | 预估：<X 人天>
2. <功能 B>：<简要描述> | 优先级：Must | 预估：<Y 人天>
3. <功能 C>：<简要描述> | 优先级：Should | 预估：<Z 人天>

不做清单(Explicitly Out of Scope):
- <功能 D>：本迭代不做，原因：<xxx>
- <功能 E>：下个迭代再评估

确认人：<产品> / <技术> / <测试>
确认日期：<yyyy-mm-dd>

这里有两个关键：

第一，"不做清单"比"要做清单"更重要。 很多范围蔓延的根源是"没说不做"。你没写"不做批量操作"，产品就觉得"你应该做"。把"不做"写出来，是最好的防火墙。

第二，每个功能都要有预估工时。 没有工时，就没有成本感。产品说"加个筛选"，你说"要 2 人天"，他就会开始权衡。你什么都不说，他就觉得是免费的。

小白提示：Out of Scope(范围之外) 明确写出"不做什么"，比写"做什么"更能防止扯皮。就像租房合同里写"不含物业费"，比不写要清楚得多。

6.2 取舍决策模板

每次遇到"全都要"的压力时，在脑子里(或纸上)跑一遍这个模板：

【铁三角取舍分析】

当前状态：
- 范围：<要做的功能清单>
- 时间：<截止日期>
- 成本：<可用人力/资源>
- 质量标准：<测试覆盖 / 性能指标 / 文档要求>

变更/冲突：
- <新增需求 / 工期提前 / 人员减少 / ...>

铁三角影响：
- 如果保范围保时间 → 成本需要 +X(加人/加班/外包)
- 如果保时间保成本 → 范围需要砍掉 <Y 功能>
- 如果保范围保成本 → 时间需要延期 <Z 天>
- 如果三个都不动 → 质量将降级为 <...>(←不推荐，但要让决策者知道)

推荐方案：<X>
理由：<...>
风险：<...>

6.3 变更评估单

当新需求来了，不要直接说"行"或"不行"，先走评估：

【变更评估单】
变更编号：CR-<序号>
提出人：<谁>  |  日期：<yyyy-mm-dd>

变更内容：<一句话描述>

铁三角影响：
- 时间：+<X> 人天(原计划 <Y> 天 → 变更后 <Y+X> 天)
- 成本：需要 <额外资源> / 不需要
- 范围：影响 <哪些模块>
- 质量风险：<如果硬塞进来会牺牲什么>

选项：
A) 接受变更，延期 <X> 天
B) 接受变更，砍掉 <功能 Z> 保住上线日期
C) 接受变更，加 <资源> 保住日期和范围
D) 拒绝变更，放入下个迭代
E) 降级质量标准，接受变更不调其他(⚠️ 需要所有人确认风险)

建议：<X>，原因：<...>
审批人：<产品 / 项目经理 / 领导>

核心思想：不是不让改，是让每次改动都"明码标价"。

你去餐厅吃饭，菜单上写着价格，你点了三个菜。服务员端上第四个菜说"厨师觉得你应该尝尝这个"——你会问："这个谁买单？" 范围变更也是一样。

7. 进阶心法

7.1 "可以，但是"比"不行"好用一万倍

技术人最容易犯的错误是直接说"做不了"。

产品听到"做不了"，脑子里的翻译是："这个人不配合。"

换一种说法："可以做，需要 3 天，会影响 X，你看怎么取舍？"

产品听到的是："这个人很专业，帮我算清楚了。"

同样的信息，不同的包装，效果天差地别。 铁三角就是帮你把"不行"翻译成"可以，但是"的框架。

7.2 范围管理不是一次性的，是持续的

很多人以为范围基线定了就完事了。不是。铁三角分析是一个持续的过程：

• Sprint 开始：锁定三条边的基线
• Sprint 中间：有变更就走评估流程，重新审视三条边
• Sprint 结束：复盘哪条边被动了、是主动选的还是被动崩的

就像你开车用导航：出发前设好目的地(基线)，路上遇到堵车要绕路(变更)，到了之后看看实际路线和计划差了多少(复盘)。

7.3 "下个迭代"是你最好的朋友

不是所有需求都要在这个迭代做完。"下个迭代"不是拒绝，而是"排队"。

你可以说："这个需求很好，但优先级不如当前的 A 和 B。我建议放到下个迭代，到时候优先排。"

产品能接受"排队"，但不能接受"拒绝"。这是人性。

7.4 所有变更留书面记录——你的"保险单"

口头答应的需求，出了问题谁都不认："我当时说的不是这个意思""你怎么没提醒我会延期？"

解决方案很简单：所有需求变更，发一条消息确认。 不需要多正式，一条 IM 消息就够：

@产品经理 确认一下：刚才讨论的变更——列表页加按状态筛选(单选)，
预估 1 人天，不影响上线日期。如果后续要加多选，需要额外评估。
你确认的话我就排进去了。

这条消息就是你的"保险单"。将来扯皮的时候，你有据可查。

7.5 一张对比表：无效应对 vs 铁三角管理

7.6 概念速查表

8. AI 能改变铁三角吗？

2025 年以来，AI 编程助手(Copilot、Cursor、Claude Code)和 AI Agent 已经在真实地改变开发效率。一个自然的问题是：AI 能打破铁三角的约束吗？

8.1 AI 确实在改变"成本"这条边

最直接的影响是：同样的人力，能做更多的事。

我是个老程序员了, 虽然号称前后端都会做, C++, Java, Python, Golang, JS 都会写, 其实前端我只会简单的 JS/CSS 和一点 vue.js, 后端语言里也主要是 C++/Java 比较熟悉, 说是样样精通, 其实是样样稀松, 可有了 AI 之后, 我这牛皮吹得越来越有底气了, 这几个语言的项目我拿起来就能做, 而且都是产品级的质量, 原因就在于 AI 的加持, 写得又好又快, 效率无疑是提升了很多. 不过 Erlang 和 Rust 我没搞过, 还是没敢直接做正式项目, 让 AI 写的东西现在不看一眼还是不放心.

以前得找一团队做的事, 一个大项目, 需要的前后端工程师, DBA, QA, 现在只要一两个人用 AI 就能干了.

• 编码效率：AI 补全 + 生成，样板代码的产出速度提升数倍
• 测试覆盖：AI 生成单测用例，过去需要半天的测试代码，现在可能半小时
• 文档和沟通：AI 辅助写 PRD、写变更评估、写发布说明，沟通成本降低
• 调试和排查：AI 辅助日志分析、根因定位，减少"大海捞针"的时间

这意味着：在铁三角里，成本(单位人力的产出)这条边被 AI 拉伸了。同样 3 个人、两周时间，能做的范围确实比以前大了。

8.2 但铁三角的物理定律没变

效率提升不等于约束消失。AI 时代的铁三角有三个新陷阱：

陷阱一：AI 加速了"做"，但没加速"想清楚"。

AI 能帮你一天写完原来三天的代码。但需求评审、架构决策、取舍判断——这些需要人类判断力的事，一分钟都没省。

结果就是：你"做"得更快了，但"做错"的速度也更快了。如果方向错了，AI 只会帮你更快地跑到错误的终点。

陷阱二：AI 降低了交付成本，也降低了"加需求"的心理门槛。

以前产品说"顺手加一个筛选"，你说"要 2 人天"，他会犹豫。

现在你说"用 AI 半天就搞定"——产品的反应是什么？"那再加三个吧。"

AI 让"顺手加一个"的成本感知更低了，Scope Creep 反而可能更严重。这就像高速公路修好了，车不是少了，而是更多了——杰文斯悖论。

陷阱三：AI 生成的代码质量有"天花板"。

AI 生成代码很快，但不代表代码质量高。没有人 review、没有架构把关的 AI 代码，可能引入更多隐性技术债。你以为省了成本，其实只是把质量这面墙变薄了。

8.3 AI 真正改变的是什么？

AI 没有打破铁三角，但它移动了瓶颈：

换句话说：AI 把瓶颈从"执行层"推到了"决策层"。 以前项目延期是因为代码写不完，现在项目出问题更多是因为——需求没想清楚、取舍没做对、质量把关缺位。

8.4 AI 时代的铁三角心法

既然 AI 改变了效率但没改变物理定律，我们该怎么用好它？

1. 用 AI 省下的时间，投入到"想清楚"上。 编码时间省了 50%？不要用来多做 50% 的需求，而是用来做更好的需求评审、更充分的影响评估、更完善的测试。

2. 越是 AI 加速，越需要铁三角纪律。 当"加一个功能"的成本变低时，范围管理反而更重要。否则你就会从"做 3 个功能做得漂亮"退化成"做 15 个功能都半吊子"。

3. 把 AI 当作铁三角的分析工具。 让 AI 帮你做变更评估：输入当前范围基线和新需求，让它分析工期影响、模块依赖、风险点。AI 不替你做决策，但能帮你算得更快更准。

4. 质量把关不能外包给 AI。 AI 生成的代码，人要 review。AI 写的测试，人要验证覆盖率。AI 加速了生产，但质量的最终责任人还是人。

一句话总结：AI 拉伸了铁三角的边，但没有消除铁三角的约束。效率越高，决策力和纪律性越重要。

9. 常见误区

9.1 不敢说影响——"英雄情结"在作祟

很多技术人有一种"英雄情结"：觉得说"这个会影响排期"是示弱，说"有代价"是计较。

不是。说清楚影响，是专业；闷头扛到最后炸了，才是不专业。

你去看医生，医生说"这个手术有 5% 的并发症风险"，你会觉得他不专业吗？你会觉得他很靠谱。你去 4S 店修车，师傅拿着工单说："当时说好换刹车片，现在加换轮胎，费用和工期都要调整，你确认一下。"你会觉得他计较吗？你会觉得他靠谱。

同理，你说"加这个功能需要 2 天，会影响功能 C 的测试覆盖"，产品不会觉得你在推活，他会觉得你在帮他做决策。

有据可查不是计较，是对双方的保护。

9.2 自己给自己加戏(Gold Plating)

这个坑我自己踩过。

需求说"实现一个配置页面"，你觉得"既然做了，不如做成动态的，加个版本管理，再来个回滚"。花了 3 天做了一个"完美"的配置系统。产品看了一眼："我只要一个能改参数的页面啊……"

镀金的本质是：你在用自己的审美替客户做铁三角决策。 你偷偷把范围调大了，时间和质量自然受影响。

怎么避免？动手前问自己："这个是需求要的，还是我想做的？" 如果是后者，写到 backlog 里，下个迭代评估。

9.3 "不可能三角"不代表"躺平三角"

有些人听了铁三角，结论是："反正不可能全都好，那就摆烂吧。"

不是。铁三角不是教你认命，是教你主动选择牺牲哪个，而不是被动让质量崩塌。

主动砍范围 vs 被动降质量——结果完全不同：

铁三角不是限制，是让你做出更好决策的框架。

9.4 让产品成为盟友，而不是对手

范围管理做得好，产品会感谢你。

你帮他算清楚了代价，让他在跟老板汇报时有据可依："不是我们不想做，是做了 A 就得砍 B，老板你选。"

你和产品不是对立的，你们是一起面对"资源有限但需求无限"这个现实的队友。

我以前也犯过一个错误：把铁三角当成"防御武器"，用来挡产品的需求。后来我发现，最好的铁三角分析是"共建"的——你和产品一起定基线，一起评估变更，一起做取舍。这样出了问题，不是"你没管好"或"他加太多"，而是"我们一起调整"。

10. 一句话金句

"可以，但是"比"不行"好用一万倍。不是不让改，是让每次改动都明码标价——范围、时间、成本，你选哪个让步？

11. 总结

铁三角的本质就一句话：天下没有免费的午餐，项目管理里尤其没有。

你不需要变成一个"什么都说不"的人。你需要变成一个"什么都算得清"的人。

需求来了，你不慌。你拿出铁三角分析，量化影响，给出选项，让该决策的人做决策。

行动清单(下个 Sprint 就能用)

• [ ] 在 Sprint 规划时，写一份范围基线(包含"不做清单")，锁定铁三角三条边
• [ ] 给每个功能标上预估工时——没有工时就没有成本感
• [ ] 新需求来了，先说"我评估一下铁三角影响"，而不是"行"
• [ ] 用变更评估单量化影响(工期 / 模块 / 风险)，给出至少 2 个选项 + 1 个建议
• [ ] 所有变更用 IM 消息确认，留书面"保险单"
• [ ] 动手前问自己："这是需求要的，还是我想做的？"——防止 Gold Plating
• [ ] 学会说"可以，但是"——不说"不行"，说"这是代价，你选"
• [ ] Sprint 结束时复盘：铁三角里哪条边被动了？是主动选的还是被动崩的？

思维导图

@startmindmap
<style>
mindmapDiagram {
  node { BackgroundColor #FAFAFA }
  :depth(0) { BackgroundColor #FFD700 }
  :depth(1) { BackgroundColor #E3F2FD }
  :depth(2) { BackgroundColor #F5F5F5 }
}
</style>
* 项目铁三角\n范围·时间·成本·质量
** What 是什么
*** 三条边
**** 范围 Scope: 做多少
**** 时间 Time: 花多久
**** 成本 Cost: 花多少
*** 质量不是第四条边\n是前三个拧过头后崩的墙
*** 范围的两个敌人
**** Scope Creep\n别人往碗里加菜
**** Gold Plating\n自己往碗里加菜
*** Scope Baseline\n范围基线 = git tag
** Why 不能全要
*** "能量守恒"
**** 总工作量 = 范围 × 质量 / 资源
*** 加人的幻觉
**** Brooks 定律\n沟通成本 n(n-1)/2
*** 加班的代价
**** 效率衰减 / 质量下降 / 人员流失
*** "顺手加一个"的冰山
**** 每个都不大\n加起来 overflow
** 四种取舍策略
*** 固定时间+成本 → 砍范围
**** MoSCoW 优先级排序
*** 固定范围+质量 → 延时间
**** 给出诚实评估
*** 固定范围+时间 → 加资源
**** 评估沟通成本和 ROI
*** MVP 阶段 → 降质量标准
**** 必须显性决策\n记录技术债
** 进阶心法
*** "可以，但是"\n比"不行"好一万倍
*** 持续管理\n出发 → 绕路 → 复盘
*** 下个迭代当缓冲区
*** IM 消息 = 保险单
** AI 与铁三角
*** AI 拉伸了"成本"边\n同样人力做更多事
*** 物理定律没变
**** 做错的速度也更快
**** 杰文斯悖论\n成本低了 Scope Creep 更凶
**** AI 代码质量需人把关
*** 瓶颈转移\n从执行层到决策层
*** 心法：省下的时间\n投入到"想清楚"上
** 常见误区
*** 英雄情结\n不敢说影响
*** Gold Plating\n自己给自己加戏
*** 把铁三角当摆烂借口
*** 把产品当对手\n应该共建
** 模板输出
*** 范围基线模板\n含"不做清单"
*** 铁三角取舍分析
*** 变更评估单
*** 行动 Checklist
@endmindmap

系列回顾

1. 4D 总结法
2. 黄金圈法则
3. TNB 表达模型
4. FAB 提案法
5. STAR 面试法
6. 同理心三方法
7. 5W1H + 8C1D
8. 艾森豪威尔矩阵
9. PDCA 循环
10. SMART 原则
11. 领导力
12. 逻辑树
13. 解决问题五步法
14. 5 个 Why
15. 沟通四要素 CARE
16. 金字塔原理
17. 三点法
18. DACI
19. 四线复盘法
20. RAPID
21. 5S 问题处理法
22. SWOT 自我定位
23. AARRR 漏斗
24. 第一性原理
25. RACI
26. 非暴力沟通
27. SCAMPER
28. MVP 思维
29. ABC 情绪理论
30. AI Agent 学职场英语
31. 向上管理
32. OODA 循环
33. OKR
34. MoSCoW 优先级
35. RICE / ICE 评分
36. 里程碑计划
37. 验收标准 DoD
38. 项目铁三角(本篇)

扩展阅读

• PMBOK Guide — Project Scope Management(PMI 官方范围管理知识域)
• Scope Creep(Wikipedia)
• Project Management Triangle(Wikipedia)
• Frederick Brooks, 《人月神话》(Brooks 定律：往延期项目里加人，只会让它更延期)
• Mike Cohn, Agile Estimating and Planning(敏捷估算与规划的实操圣经)

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。