项目管理的本质：被管理出来的成果
核心概念
项目(Project) 是为创造独特产品、服务或成果而进行的临时性(Temporary)努力。两个不可省略的定语：
- 临时性：有明确的起点与终点，结束即解散团队；不是永续运转。
- 独特性：产出是前所未有的（即便同类项目，情境、人员、约束都不同）。
这正好区分了项目 vs 运营(Operations)：运营是重复、持续、维持现状（如客服、月结）；项目是一次性、创造新事物。两者需要不同的肌肉——运营靠标准化，项目靠结构化推进。
三重约束(Iron Triangle)：范围(Scope)、进度(Schedule)、成本(Cost)构成三角形。经典铁三角的洞见是——任何一边的变动都会牵动另外两边。要更快，要么加钱，要么砍范围；要加范围，要么延期，要么加钱。现代框架把质量、风险也纳入约束网，但铁三角仍是第一性原理。
五大过程组(PMBOK 全生命周期)：启动→规划→执行→监控→收尾。监控贯穿始终，不是独立阶段。
项目不是按计划进行的，是被管理出来的。 计划只是对现实的假设；执行一碰现实，假设就破。管理的本质，是持续把「实际」拉回「目标」——靠里程碑、度量与变更控制，而不是靠一份写完后就落灰的 plan。
实务直觉
第一原则：先管边界，再管内容。 范围一旦不清，进度和成本就失去锚点。九成项目死在 README 里那三件事——范围蔓延、进度拖延、预算失控——根子都在「边界没守住」。
- 估算会系统性偏乐观。 霍夫施塔特定律：「做事花的时间总是比你想的长，即便你考虑了霍夫施塔特定律」。叠加「学生综合征」(拖到最后一刻才开工) 与「帕金森定律」(工作会自动膨胀填满所给时间)，原始估算几乎必然低估。对策：用三点估算+缓冲，而非单一乐观值。
- 看得见进度 ≠ 真进度。 「完成 80%」在软件项目里可以维持三周。没有客观度量（见 0006 挣值），进度汇报就是心理安慰。
- 把模糊目标翻译成可交付物(Deliverable)。 「做个好系统」无法管理；「6 月 1 日前上线用户注册+登录两模块、通过 50 并发压测」才能管理。交付物是项目管理的原子单位。
跨学科应用
系统论：项目是带边界的开放系统
项目有明确边界(范围)、接口(对运营/外部的衔接)、与反馈环(监控)。忽视接口——比如上线前没和运维对齐部署——是项目「技术成功、业务失败」的常见原因。系统思维提醒：项目不是孤岛，边界外的事照样能拖垮你。
统计：不确定性随任务数累积
总工期不是各活动工期之和的确定值，而是分布。关键路径上的活动数越多，整体准时概率越低(乘性衰减)。这就是为什么大项目要留缓冲、做敏感性分析。
经济学：沉没成本陷阱
项目走到收尾，最难的往往是「砍掉已投入巨大但注定失败的部分」。沉没成本不是决策依据，但人天生亏不起。理性做法：每个阶段门(Stage Gate)只评估「未来增量收益 vs 未来增量成本」。
博弈论：多委托人目标冲突
项目常服务于多个干系人(老板要快、客户要好、财务要省)，目标彼此打架。不主动管理这种冲突，团队就会被撕扯。这直接引出 0009 干系人管理。
练习题
单选题
下列哪句话最准确地刻画「项目」与「运营」的区别？
单选题
关于「三重约束（铁三角）」，正确的是？
判断题
「项目是按计划进行的」——只要计划写得够细，执行就会严格遵循计划。
案例题
某创业团队说「我们要做一个改变行业的 App」，给你 3 个月和 5 个人。作为项目经理，你的第一步最该做什么？
参考答案：把「改变行业的 App」这个模糊目标，翻译成可交付物与边界——首版到底含哪些功能(范围)、哪些不做(边界)、6 月底交付到什么程度(里程碑)、5 人月预算怎么分配(成本)。不先钉死边界就去写代码，几乎必然范围蔓延、进度失控。先管边界，再管内容。