1. 课程导入与全景认知

软件项目失败的原因，很少是单一因素造成的。更常见的情形是：客户在开发中途提出新需求，项目经理口头答应“先做，后面再谈”，交付节点临近时功能没做完，验收被卡住，尾款迟迟不到账，双方翻出合同才发现——变更范围没有书面确认，验收标准写得含糊，付款条件与交付物也没有一一对应。需求变更、交付、合同治理这三件事，看似分属不同职能，实际上是一个互相牵制的三角。

本课程要建立的第一个认知是：需求变更不是“要不要接受”的问题，而是“以什么代价、走什么程序、由谁确认”的问题。合同不是签完就锁进抽屉的法律文件，而是贯穿项目全程的变更基准与交付依据。交付也不是“把系统部署上去”这一个动作，而是把合同约定的可验证成果，按约定节奏和证据链移交给客户的过程。

三角关系：三者如何互相牵制

把这三者放在一起看，会形成三条相互作用的边：

• 需求变更 → 合同：每一次范围变化，都会影响合同中的工作范围、工期、价款与验收标准。变更若不回写合同或补充协议，合同就与实际执行脱节，成为日后争议的隐患。
• 合同 → 交付：合同定义了交付物清单、验收标准、交付节点和付款条件。交付不是凭感觉“做完了”，而是逐条对照合同条款确认“是否满足”。
• 交付 → 需求变更：交付过程中暴露的问题（性能不达标、接口对不上、用户不认可）往往触发新一轮变更；而交付验收的结论，又反过来决定变更是否被最终接受。

这三条边构成一个闭环。任何一条边断裂，项目就会失控：只谈变更不谈合同，会无限蔓延；只谈合同不谈交付，会变成纸面合规；只谈交付不谈变更，会在验收时集中爆发冲突。

课程目标：从“救火”到“有章可循”

本课程不追求把每个人培养成律师或谈判专家，而是让项目参与者具备三种可操作的能力：

1. 识别能力：在需求变更刚冒头时，就能判断它属于哪一类（新增功能、修改逻辑、调整非功能指标、替换技术方案），并快速评估它对工期、成本、合同条款的影响量级。
2. 程序能力：知道变更该走什么流程——谁提出、谁评估、谁审批、以什么形式记录、如何同步到合同与交付计划。程序不是官僚，而是让每一次变更都有据可查。
3. 证据能力：交付和验收时，能拿出合同要求的证据链——需求确认单、变更记录、测试报告、验收签字、付款节点对应关系。没有证据的交付，等于没有交付。

学习路径：四个阶段递进

课程按“认知—工具—实战—复盘”四个阶段展开，共 30 章。前几章建立三角关系的全景认知和基本概念；中间部分深入变更控制流程、合同条款设计、交付物管理与验收方法；随后进入实战案例，覆盖政府项目、外包定制、SaaS 订阅、敏捷迭代等不同场景；最后做复盘与治理体系沉淀。

学习时建议带着一个真实或假设的项目贯穿全程。例如：一个预算 200 万、工期 6 个月的定制管理系统项目，客户在第三个月提出“增加移动端审批功能”。你可以用这个场景去套每一章的变更评估表、合同条款和交付清单，看它在不同阶段会触发什么动作、产生什么后果。

实战案例总览：三类典型冲突

课程中会反复出现三类典型冲突，它们分别对应三角关系中的不同边：

一个可立即使用的起点：三角检查表

在进入后续章节之前，你可以先用下面这张简表检查手头项目是否处于可控状态。每个问题只需回答“是/否/部分”，答“否”或“部分”的条目，就是后续章节要重点解决的对象。