甲乙双方：谁决定目标、权限与结果

项目合作顺利时，人们容易把“双方共同负责”当成充分的安排。等到客户要求开放更多数据、供应商产品拒绝临时修改，或者主管突然换人，大家才发现：共同负责并没有说明谁能作决定。

这章仍用设备维修企业的一项教学试点。报修材料分散在邮件、设备记录和工单中，系统整理建议，由维修主管决定如何派单；范围暂限一种设备、一个服务区域。问题不是再画一张汇报关系图，而是让一个具体决定能够找到承担者。

先把决定找到人

如果你正在组队，可以将讨论从“要几名 FDE”改成五个更具体的问题。谁和使用者一起确定要改变哪项工作？谁把问题做成可运行的系统？谁有权接受上线后的业务结果？谁维护通用产品？谁在项目结束后继续承担运行责任？同一个人可以兼任其中几项，但每项都要找到真正能作出决定的人。

这里尤其容易漏掉客户一侧。供应商派来了优秀工程师，并不意味着客户已经有人能批准数据访问、协调排班、修改作业流程或决定停止旧系统。如果这些决定仍要逐层临时寻找负责人，增加工程师只会使更多人一起等待。

业务负责人要说清楚“改善”是什么。是减少找资料的时间，降低错派率，还是更早发现可能停机的设备？如果三个目标发生冲突，他必须参与取舍。例如，多提示风险可能减少漏检，也可能增加主管复核负担。这项选择不能默默落到调提示词的工程师头上。

一线代表需要提供真实材料，并实际试用改变后的步骤。他不能只参加项目启动会。如果建议呈现的位置打断了原本顺手的工作，或者推荐缺少一个主管每天都看的字段，这些问题要在还改得动的时候被看见。一线代表的时间是项目投入，不是下班之后的友情协助。

FDE 承担跨系统的工程推进：确认数据怎样到达、把业务规则翻译成可以检查的处理步骤、定位错误，并把用户反应变成下一次修改。他不必亲手完成所有连接器——让不同系统交换资料的软件——却要能追踪一条报修信息经过哪些环节，知道问题在哪里停住。

客户的数据与系统负责人管理访问、字段定义和既有系统的变更。当设备编号含义改变时，不能指望 FDE 通过一张越来越复杂的映射表永久消化。有人必须在源头修订规则，并说明其他应用是否会受到影响。

最后还要有运行负责人。他参与的不应只是交接培训，而是从试点开始就理解如何发现异常、如何退回原流程、如何升级求助。否则系统上线的那一天，也可能是组织第一次意识到“谁值班”尚未决定的那一天。

这张表是责任讨论的工具，不是固定编制。共同工作不妨碍每项决定有明确归属；有人提供建议，也不等于他已经获得作决定的权限。

英国政府项目交付标准要求在管理安排中明确角色承担的活动、交付物或结果，以及向谁负责。¹ 这里借鉴的是责任能够追踪的原则，不照搬政府职位。企业可以使用自己的职称，但不能让客户方、平台方、实施伙伴和现场工程师各留一段无人负责的空白。

项目负责人不是所有决定的代办人

跨职能工作需要一个能把事情往前推的人。但“推动”不意味着可以替别人决定。技术负责人可以判断接口设计是否可靠，不能替客户决定某类资料是否应被使用；业务负责人可以选择试点范围，也不能要求工程师把已知会重复派单的故障带进生产。

团队最好把三类决定分开。第一类是可逆的日常工程选择，例如日志展示方式、内部模块划分，直接由承担者处理。第二类改变交付承诺，例如增加设备类别、延长保留时间、接入另一套核心系统，需要把影响带回业务和技术负责人共同判断。第三类涉及重大后果或制度要求，需要相应权限的人作决定。

分开并不是增加会议，而是减少临时争论。若所有选择都交委员会，小修改也走不动；若全部交给现场个人，团队又会用敏捷的名义积累未经讨论的承诺。好的边界让多数日常工作能自主进行，让少数重要选择被及时看见。

可以用一页短记录承接这些选择：发生了什么变化，有哪些可选办法，影响谁，谁决定，何时复看。它比每天给所有人抄送长进度报告更接近管理需要。记录的目的，是下一位接手者能理解当时为何这样做，而不是证明团队开过多少次会。

假如维修主管要求系统直接自动派单，团队可以这样处理这个教学冲突。FDE 先写明新动作影响哪些工单、什么情况下会重复派单，以及能否撤回；客户系统负责人确认写入权限和恢复条件。两人负责说明技术条件，不替主管接受误派造成的业务损失。

项目开始时就可以约定：普通范围变更在下一个工作日由业务负责人作出接受、缩小或放弃的决定；跨部门且无权决定的事项交给项目赞助人，也就是有资源调配权的客户负责人。这个时限是示例约定，重大事故仍按项目的紧急处置安排执行。在自动派单的撤回条件尚未满足时，技术负责人可以暂停该动作，现有的人工确认试点继续。业务负责人只能选择条件已满足的方案，不能通过签字把已知缺陷变成技术可行。

假如核心产品团队又拒绝临时增加撤回接口，项目赞助人最终要在增加投入、延后自动派单或保留人工确认之间选一个，并同步调整交付承诺。FDE 不需要让两边都满意后才能离开会议；他需要让决定、承担者和未完成条件都落在记录里。没有决定时，原有范围继续有效，新功能不会因等待太久而自动获准。

换了负责人，先核对什么

再给这个教学试点换一个条件：维修主管调岗，新负责人接任。原试点是否必须全部重批，自动派单能否顺势开放？先沿现有记录核对：原范围是否改变、由谁承接，谁确认下一阶段预算与人员时间，谁有权暂停或终止试点。

换人本身不使原有授权全部失效。范围授权、资源和紧急停用安排仍有效的人工确认试点可以继续；不能确认的条件影响哪项动作，就先暂停哪项，交由相应权限的人决定。自动派单仍须满足原来的技术与授权条件，接替手续不能补出缺失的撤回接口。

人员承接应同时通知另一方。旧负责人曾接受的技术限制、未批准的范围、待履行的条件，都应随记录交给继任者。历史决定保留原来的作出者，当前责任写明接任者，不能为方便联络把旧记录改成新负责人“当时已经同意”。

产品、伙伴和现场之间，也要有决定的出口

还是这次自动派单请求。FDE 应把可复现的重复派单问题、受影响的工单范围和已试过的办法交给一个明确的产品联系人。产品负责人安排评估，说明接口修改是否进入受维护版本，以及能在什么时间给出决定。日常沟通可以直接进行，涉及原承诺的取舍则回到前面约定的责任人。

如果请求暂不进入产品，项目也需要知道谁继续维护既有的人工确认方案。不能把“产品未接受”理解为现场永久兜底，更不能向客户承诺一个尚未排期的能力。产品负责人回答平台是否承担，项目负责人回答当前合同和资源能承担什么，客户负责人决定是否接受相应范围。

若还存在行业伙伴，边界要再往前走一步。伙伴可能能改连接器，却不能修改平台权限机制；平台工程师可以解释机制，却无权改变客户的数据用途。遇到跨界故障，要先保留请求、状态和证据，由双方指定的技术负责人确认下一位处理者；不能只把工单互相转发，直到一线绕过系统。

谁主导协调，可以按合同与实际能力决定。但协调者应能召集相关人员，提出可选方案，并把超出权限的取舍交给有权决定的人。他不能靠承担所有工作来掩盖别人没有响应。

有人提交可判断的问题，有人明确回复，有人对暂时保留的做法负责。《每个客户都不同，产品怎样成长》再讨论哪些能力值得成为公共产品；本章先保证产品拒绝或推迟一个请求时，项目仍然有可以执行的决定。

不要把技术通过、业务接受和下一阶段批准写成一件事

继续看维修试点。工程检查可以给出系统在所测条件下是否重复执行的证据；一线试用才可能说明主管是否更容易找到依据；业务负责人还要判断复核负担和错派代价是否值得。三者互相需要，但不能由其中一个替代另外两个。

同样，一期验收并不天然批准接入下一个区域。要核对新区域的数据范围、当地使用者、资源和运行时间；若只是原有范围内的日常维护，也不必每次回到立项层级。把“继续已批准工作”和“扩大承诺”分开，团队才能兼顾速度与边界。

一份可用的决定记录可以很短。对自动派单请求，记录当前仍采用人工确认；自动动作因撤回条件不足暂停；客户系统负责人确认写入和恢复条件，产品负责人决定接口方案，业务负责人在可行选项内选择下一范围；同时写明再议需要的证据。它不是进度汇报的缩写，而是给下一位行动者的依据。

甲乙双方最需要约定的，不是永远不发生分歧，而是分歧出现时，技术条件由谁说明、业务代价由谁接受、资源由谁提供。缺少这些决定，现场工程师再优秀，也只能不断替组织垫付等待。