第 2 章 · 预计阅读 15 分钟
范围基线、估算与合同
为什么一份功能列表不足以支撑固定总价合同？
团队要把范围、质量、依赖、交付物、里程碑和变更方式共同写进 SOW。
先放回整门生意
先知道这一章为什么存在
先把“范围基线、估算与合同”理解成一段有触发、有负责人、有记录、也有完成标准的业务，而不是一组部门名词。
上一章“商机发现与业务澄清”应先形成：功能只有放进用户、流程、数据和约束中，才能判断真正问题与项目价值。
本章把“团队要把范围、质量、依赖、交付物、里程碑和变更方式共同写进 SOW。”从一句目标变成可执行、可交接、可核验的工作。
结果将交给下一章“架构、开发与系统集成”：端到端业务依赖数据、权限、接口和多个组件在同一版本中协同。
- 收入怎么受影响
- 陆桥数智通过定制开发项目费、系统集成费、需求变更工时费和上线后运维费收费。本章形成的“可执行项目基线”要和“工作分解和估算表”和“签署的 SOW”一起核对，才能继续判断验收、结算或后续经营；现金时点按以下规则判断：签约收 20%，需求基线、上线试运行和终验分别收 30%、30% 和 20%；已批准变更随下一里程碑结算。
- 风险在哪里出现
- 全程要警惕“范围蔓延、估算偏差、交付延期与关键人员依赖”。本章至少要用“工作分解和估算表”和“签署的 SOW”留下可追溯证据。
读完这一章，你应该能自己解释
- 能用自己的话解释“为什么一份功能列表不足以支撑固定总价合同？”，并说出它为什么会影响客户价值或经营结果。
- 能按依赖顺序还原2个业务步骤，并指出每一步的负责人、记录和交接物。
- 能区分业务流、钱流、信息流和责任流，不把“做过动作”误当成“完成交付”。
- 遇到相似情境时，能用“产出是否形成、证据能否核对、风险是否受控”作出判断。
先建立业务直觉
价格建立在可解释假设上
项目估算包含工作量、技能、风险和等待成本；边界越模糊，报价要么失真，要么靠后续争议补偿。
把它放进陆桥数智的经营现场：本章只聚焦“范围基线、估算与合同”这一环，追踪它怎样承接已有输入，并把“团队要把范围、质量、依赖、交付物、里程碑和变更方式共同写进 SOW”变成可以执行和复核的工作。
本章从“拆解并估算”开始，依次经过“拆解并估算”和“确认 SOW 与基线”，最后得到“可执行项目基线”。判断是否完成，要把动作、产出、业务记录和下一位接手者放在一起核对。
至少同时满足三件事：产出“可执行项目基线”；关键记录“工作分解和估算表”和“签署的 SOW”可以相互核对；相关负责人清楚下一步由谁接手。
完整案例推演
跟着陆桥数智，把“范围基线、估算与合同”完整跑一遍
现在把镜头放到陆桥数智的“范围基线、估算与合同”：为什么一份功能列表不足以支撑固定总价合同？ 先读下面的经营底账，后续每一步都会复用这些数字与约束。
贯穿全课的虚构案例
陆桥数智
一家 32 人的软件交付公司，为汽配厂建设生产计划、仓储和质量追溯系统；合同已经签署，但客户新增扫码和设备联网需求，项目经理必须先判断它属于原范围还是变更。
- 项目合同额
- ¥860,000合同总价对应已确认的范围和验收条件，并不自动覆盖后续提出的所有需求。
- 交付周期
- 6 个月、4 个付款里程碑需求确认、联调、试运行和终验分别产生交付证据与回款条件。
- 系统接口
- 12 个，已联通 8 个开发完成的页面不等于系统可用，上下游接口状态会直接阻塞完整业务测试。
- 验收状态
- 132 条用例通过 109 条、阻塞 8 条通过率要连同阻塞原因和责任方解释，不能用一个百分比代替问题清单。
客户为什么付钱
定制开发项目费、系统集成费、需求变更工时费、上线后运维费
钱在什么时候进来
签约收 20%，需求基线、上线试运行和终验分别收 30%、30% 和 20%；已批准变更随下一里程碑结算。
利润最容易被什么吃掉
研发和项目管理工时、外部接口与软硬件采购、驻场差旅、返工与延期占用
这笔业务怎样一步一步形成可交付结果
- 01拆解并估算估算与资源计划
- 02确认 SOW 与基线可执行项目基线
拆解并估算
在陆桥数智，团队先面对一条共同事实：“项目合同额”为¥860,000。合同总价对应已确认的范围和验收条件，并不自动覆盖后续提出的所有需求。
按功能、接口、数据、测试和部署拆分工作，评估人员产能与风险缓冲。
这一步真正要判断：梳理流程、角色和规则；拆解计划和管理产能
如果本步没有形成“估算与资源计划”，下一步“确认 SOW 与基线”就没有可靠输入。
- 谁在参与
- 业务分析师、交付负责人
- 关键记录
- 工作分解和估算表
- 形成产出
- 估算与资源计划
- 交给下一步
- 把“估算与资源计划”交给业务分析师和客户业务负责人，继续处理“确认 SOW 与基线”。
如果没做好：如果业务分析师没有梳理流程、角色和规则，或者没有留下“工作分解和估算表”，即使动作已经做过，下一步也无法确认“估算与资源计划”是否可靠。
确认 SOW 与基线
上一步已经形成“估算与资源计划”。与此同时，案例里的“交付周期”为6 个月、4 个付款里程碑，需求确认、联调、试运行和终验分别产生交付证据与回款条件。
共同确认交付物、排除项、责任、里程碑、付款和变更审批人。
这一步真正要判断：梳理流程、角色和规则；提供决策和业务资源
这是本章最后一项可核验产出，用来判断团队是否真的完成了“范围基线、估算与合同”。
- 谁在参与
- 业务分析师、客户业务负责人
- 关键记录
- 签署的 SOW
- 形成产出
- 可执行项目基线
- 交给下一步
- 把“可执行项目基线”作为本章完成证据，交给下一章节继续使用。
如果没做好：如果业务分析师没有梳理流程、角色和规则，或者没有留下“签署的 SOW”，即使动作已经做过，下一步也无法确认“可执行项目基线”是否可靠。
案例结束时，不是因为所有人都完成了自己的动作就算成功，而是因为“可执行项目基线”已经形成、证据可以追溯，并且业务分析师和客户业务负责人能够解释结果怎样产生、风险怎样被控制。团队要把范围、质量、依赖、交付物、里程碑和变更方式共同写进 SOW。
换一个视角再看
同一笔业务，同时跑着四条线
业务流说明事情怎样发生，钱流解释收入、成本与现金，信息流留下共同事实，责任流决定谁执行、谁确认、谁承担后果。点击切换，观察同一章节怎样变化。
围绕“为什么一份功能列表不足以支撑固定总价合同？”，业务必须按依赖关系推进，不能把一串并行任务误当成已经交付。
- 01
拆解并估算 → 估算与资源计划
- 02
确认 SOW 与基线 → 可执行项目基线
出现这个信号要警惕：如果业务分析师没有梳理流程、角色和规则，或者没有留下“工作分解和估算表”，即使动作已经做过，下一步也无法确认“估算与资源计划”是否可靠。
岗位、记录与业务语言
一家公司靠什么把多人协作变成同一个结果
岗位不是孤立的名称，记录也不是多余的表格。前者分配判断与责任，后者让不同人能够核对同一件事是否真的发生。
谁负责什么，结果交给谁
| 角色 | 本章负责 | 最关心 | 交给谁 |
|---|---|---|---|
| 业务职能商机、方案与范围合同 | 提供本章所需的约束、输入或审批 | 把客户问题转换成边界、估算、里程碑和商业条件；重点关注：组织需求发现和方案评估 | 下一章节或业务结果的接收方 |
| 业务职能设计、开发与质量交付 | 提供本章所需的约束、输入或审批 | 按基线构建系统、集成接口并证明它满足要求；重点关注：完成架构、开发、集成和测试 | 下一章节或业务结果的接收方 |
| 外部参与者客户业务负责人 | 确认 SOW 与基线 | 代表客户确定优先级、业务规则和验收结论；重点关注：提供决策和业务资源 | 下一章节或业务结果的接收方 |
| 外部参与者第三方系统或供应商 | 提供本章所需的约束、输入或审批 | 提供项目所依赖的接口、产品或外部能力；重点关注：按约提供接口环境和文档 | 下一章节或业务结果的接收方 |
| 代表岗位业务分析师 | 拆解并估算、确认 SOW 与基线 | 把业务语言转成团队可理解、客户可确认的需求；重点关注：梳理流程、角色和规则 | 客户业务负责人 |
| 代表岗位交付负责人 | 拆解并估算 | 协调开发、测试和依赖方，持续交付可验证版本；重点关注：拆解计划和管理产能 | 业务分析师、客户业务负责人 |
哪些记录能证明业务真的发生了
| 业务记录 | 在哪产生 | 谁形成 | 证明什么 | 下一步怎么用 |
|---|---|---|---|---|
| 工作分解和估算表 | 拆解并估算 | 业务分析师和交付负责人 | 估算与资源计划 | 确认 SOW 与基线 |
| 签署的 SOW | 确认 SOW 与基线 | 业务分析师和客户业务负责人 | 可执行项目基线 | 判断本章是否完成并进入下一章节 |
本章术语：先用白话理解，再回到正式定义
- SOW工作说明书 SOW
- 白话：这次到底做什么、不做什么、怎样算完成。
- 正式定义：描述项目范围、交付物、责任、计划、假设和验收条件的合同文件。
- 放进业务里：SOW 约定交付三个业务模块和两条外部接口。
- 业务术语需求基线
- 白话：大家先认同的需求底稿，之后新增要说明代价。
- 正式定义：经各方确认、作为设计开发和变更比较依据的一组需求版本。
- 放进业务里：评审签字后的 1.0 需求成为首期开发基线。
- 业务术语里程碑
- 白话：不是到了某一天，而是到那天必须拿出什么结果。
- 正式定义：项目中具有明确成果和确认条件的重要节点。
- 放进业务里：完成接口联调并通过测试后触发里程碑付款。
- 业务术语人员利用率
- 白话：团队时间有多少真正投入可交付工作。
- 正式定义：可收费或项目投入工时占可用工时的比例。
- 放进业务里：等待客户接口导致开发人员连续两周低利用率。
- CR变更请求
- 白话：新想法不是不能做，但要先算清影响再决定。
- 正式定义：对已确认范围、计划、费用或交付方式提出并经评估批准的修改。
- 放进业务里：新增移动端审批需提交 CR 并顺延两周。
新手最容易误解的地方
描述越宽泛，项目越容易无争议验收
为什么不对：缺少可检查边界会让范围、成本和验收同时失去共同依据。
应该继续追问：如果改成“双方会用不同标准判断是否完成和该不该付款”，需要谁确认、留下什么证据？
“拆解并估算”只要动作做完，就可以直接进入下一步。
为什么不对：如果业务分析师没有梳理流程、角色和规则，或者没有留下“工作分解和估算表”，即使动作已经做过，下一步也无法确认“估算与资源计划”是否可靠。
应该继续追问：是否已经形成“估算与资源计划”，并留下“工作分解和估算表”供下一步核对？
“确认 SOW 与基线”只要动作做完，就可以直接进入下一步。
为什么不对：如果业务分析师没有梳理流程、角色和规则，或者没有留下“签署的 SOW”，即使动作已经做过，下一步也无法确认“可执行项目基线”是否可靠。
应该继续追问：是否已经形成“可执行项目基线”，并留下“签署的 SOW”供下一步核对？
先复盘，再做判断
现在，试着不用页面原话把这一章讲出来
- 为什么本章必须先做“拆解并估算”，如果跳过会影响哪一步？
- 在“确认 SOW 与基线”中，谁执行、谁提供约束，应该留下什么记录？
- 本章怎样影响定制开发项目费、系统集成费、需求变更工时费和上线后运维费？结合“签约收 20%，需求基线、上线试运行和终验分别收 30%、30% 和 20%；已批准变更随下一里程碑结算。”判断它何时才会形成收入或现金。
- 如果只看到“可执行项目基线”的口头结论，你还会要求核对哪些业务记录？
合同只写‘完成数字化升级’，没有交付物和验收条件，最大风险是什么？
双方对项目都有很高期待。