4.3 我怎样把使用过程说到没有歧义
第一版演示时，工程师选中一位客户，点了一下“生成交接单”，屏幕很快出现了一份完整材料。
销售觉得不错，项目经理却问：“我什么时候会收到它？收到以后，什么才算我已经正式接手？”
会议室安静了下来。我们做出了一个功能，却还没有设计它怎样进入工作。
我跟着销售小林重新走了一遍
我没有继续讨论页面，而是坐到小林旁边，看他处理一笔真实商机。
客户开完需求会后，小林先整理会议纪要，再请售前判断能否满足。方案几次修改后，客户才确认范围。销售随后申请价格、走合同审批。签约完成，项目经理和财务才进入。
过去大家把这一长段都叫“售前阶段”，系统里只有“跟进中”和“已签约”两个状态。可每次交接需要的事实完全不同。
我开始记录六个问题：
- 谁正在处理；
- 什么事件让这一步开始；
- 他拿到什么资料；
- 当前这笔生意处于什么事实状态；
- 什么条件满足后才能交给下一位；
- 不能继续时由谁接住。
使用者不是一个模糊的“业务人员”
销售、售前、项目经理都属于业务人员，但他们关心的事情不同。
销售确认客户目标、预算和决定人；售前确认标准能力与额外要求；项目经理确认客户条件、资源和验收办法；财务确认开票与付款节点。
如果任务书只写“业务人员可以确认”，系统就不知道谁有权确认什么。最后通常会变成谁先点按钮谁负责。
我为每个重要动作指定角色，而不是指定某个固定姓名。姓名会变，责任必须留在岗位上。
触发器要来自真实事件
“用户打开页面”不是业务触发器。
销售完成第一次有效需求沟通、客户要求提交正式方案、非标准要求被发现、合同完成审批，这些才是会改变下一步工作的事件。
我把触发器写成过去式，因为它必须是一件已经发生、可以核对的事。例如：
- 客户目标和初步范围已经由销售确认；
- 售前已经标出非标准要求；
- 有权负责人已经批准额外承诺；
- 合同已经由双方完成确认。
如果一句触发条件里出现“差不多”“基本完成”，就还不能交给系统执行。
状态必须表示业务事实
工程师最初使用“未处理、处理中、已完成”。这些状态适合任务列表，却不能说明一笔订单发生了什么。
我们改成了更接近经营事实的状态：
| 状态 | 说明 | 谁能让它进入下一步 |
|---|---|---|
| 客户目标待确认 | 知道客户有兴趣，但结果和决定人不完整 | 销售 |
| 方案能力待核对 | 目标已知，正在比较标准与非标准要求 | 售前 |
| 额外承诺待决定 | 存在范围、价格或交付例外 | 指定负责人 |
| 合同条件已确认 | 范围、客户条件、验收和付款节点明确 | 销售与审批岗位 |
| 交接待接收 | 材料已准备，项目和财务尚未确认 | 项目经理、财务 |
| 可以启动 | 启动所需条件已经满足 | 项目负责人 |
状态不是给页面上色。它决定谁可以做什么，也决定 AI 能不能继续。
“完成”需要一组条件，不是一次点击
项目交接不能因为销售点击“提交”就完成。
我和项目、财务一起写下完成条件：客户目标有来源，合同范围已确认，非标准承诺有批准人，客户需提供的条件明确，验收与付款节点存在，项目和财务都确认接收。
只要其中一项缺失，系统可以生成待办，但不能显示“已完成”。
这会让流程看起来慢一点，却避免用一个绿色状态掩盖后面必然发生的返工。
等待也必须成为一种看得见的状态
很多企业流程不是卡在工作本身，而是卡在等待。
等待客户提供接口资料、等待负责人批准额外开发、等待法务确认合同，这些过去散落在聊天里。系统只显示“处理中”，没人知道已经等了多久、应该催谁。
我为等待写清对象、开始时间、承诺时间和升级人。AI 可以提醒和整理上下文，但不能因为等待太久就替负责人批准。
当等待超过约定时间，系统不是自动跳过，而是把完整情况送给能够决定的人。
异常路径要和正常路径一起写
正常路径通常很容易说明，真正决定系统能不能用的是异常。
我们选择了四种情况追问：
- 客户在合同前临时增加需求；
- 销售和合同里的客户名称不一致；
- 售前无法判断某项能力是否存在；
- 项目经理拒绝接收，因为客户条件没有确认。
每种异常都要写清当前状态是否保持、谁收到问题、需要补什么证据、多久没人处理就升级、处理后从哪里继续。
如果异常只能靠员工另开群解决，系统还没有真正覆盖这项工作。
我怎样让工程师和业务一起确认
我把状态表贴在会议室里，请每个角色用一笔真实订单讲自己的部分。工程师则逐项复述系统需要记录什么、允许谁改变状态。
只要有人说“实际工作不是这样”，我们就回到订单证据，而不是争论哪种流程更标准。
最后我让一位没参加设计的项目经理只看状态表，讲出这笔订单怎样进入他的工作。如果他讲不出来，说明表仍然只对设计者有意义。
执行包最终只保留六个交付状态
| 状态 | 进入条件 | 允许下一动作 | 不能继续时 | 责任岗位 |
|---|---|---|---|---|
| 客户目标待确认 | 商机进入有效沟通 | 补充来源，由销售确认目标和角色 | 保持状态并显示缺失 | 销售 |
| 方案能力待核对 | 客户目标已确认 | 对照标准能力，识别非标准要求 | 送售前或产品负责人 | 售前 |
| 额外承诺待决定 | 出现接口、迁移、服务或特殊条件 | 接受、拒绝、加价或改变计划 | 未决定不得形成已确认承诺 | 交付或产品负责人 |
| 合同条件待确认 | 方案与报价准备完成 | 确认范围、价格、责任、验收和付款 | 继续等待，不显示“可签署” | 销售、财务、法务 |
| 交接待接收 | 合同已经确认 | 项目与财务核对并接收 | 退回缺失项，保留原状态 | 项目经理、财务 |
| 可以启动 | 客户条件、资源和交接均已确认 | 进入项目原有启动流程 | 新变化重新进入对应决定 | 项目负责人 |
第 3 卷目标蓝图有七个较完整的未来状态，执行包第一阶段只实现其中与签约前核对和共同交接直接相关的六个。验收与尾款继续被观察，但不在第一版重建项目和财务流程。
YS-P-001 的第三方授权缺失会停在“方案能力待核对”，18% 折扣会停在“合同条件待确认”，CRM 故障不会把任何状态自动改成完成。完整进入条件、决定规则和升级方式见 执行包第 6 节。
状态说明了工作走到哪里，却还不能说明“客户已同意”究竟来自会议、合同还是员工判断。下一节为每个重要事实指定来源、确认人、权限和系统不可用时的表现：我怎样把数据、系统和权限写进任务。