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