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