跨产品团队协同要解决的是产品之间相互依赖却各自排期的问题。可行的做法是先划清产品边界与共性能力归属，再建立依赖的提出、评估、承诺和跟踪流程，明确产品负责人、协同接口人与共性能力负责人的职责，最后用固定例会和依赖台账维持节奏。推进时建议从一条真实的跨产品依赖链开始试点，跑通后再扩展。
要点总览（TL;DR）
- 跨产品团队协同按四步推进：先划清产品边界与共性能力归属，再建立依赖的提出、评估、承诺与跟踪流程，然后明确各角色职责与交付物，最后用协同例会和依赖台账维持节奏。
- 边界清单至少包含产品范围、目标用户、核心能力和对外接口四项；账号、支付、消息、权限这类共性能力按调用方数量、演进节奏和维护人力判定归属，争议由产品线负责人裁决并记录。
- 依赖单要写清提出方、承接方、依赖内容、期望时间、承诺时间和影响范围；承诺时间变更须说明原因并经提出方确认，内容变更视为新依赖重新走流程。
- 协同例会建议每两周一次，依赖台账状态统一为待评估、已承诺、进行中、已交付待验收、已关闭、已逾期六类，逾期由产品线负责人决定调整排期或调配资源。
- 落地时从一条真实的跨产品依赖链试点，跑通后再扩展；用边界清单、依赖流程、角色分工、台账节奏四类检查项核对机制是否真正运转。
跨产品协同先解决哪几件事
跨产品协同机制由四个基本构件组成：边界划分、依赖流程、角色分工、节奏校验。它们的先后关系不能颠倒，因为后一项的输入依赖前一项的产出。
先划边界，是因为依赖流程需要知道“谁向谁提依赖”。如果两个产品在目标用户和核心能力上高度重叠，依赖单会变成责任推诿的载体，评估环节也无法判断某项能力应由哪一方承接。边界清晰之后，共性能力有明确归属，依赖关系才能被准确描述和承诺。
四步推进路线可以概括为：
- 划边界：产出产品边界与共性能力归属清单，明确每个产品的范围、接口和共性能力承接方。
- 建流程：产出依赖单字段与流转规则，让依赖从口头协调变成有记录、有承诺的正式事项。
- 定角色：产出角色职责与交付物对照表，让每个环节有人负责、有人交接。
- 保节奏：产出依赖台账与协同例会议程，让依赖状态持续可见，逾期和阻塞有升级路径。
四步不必等全部设计完再启动。更稳妥的方式是选一条当前真实存在的跨产品依赖链，按上述顺序把四个构件在这条链上跑一遍：先确认双方边界，再补一张依赖单，指定接口人，开一次协同例会并建台账。这条链跑通后，再把字段、角色和议程复制到其他产品组合。试点链的价值在于暴露边界争议和承诺口径问题，这些问题在小范围内修正的成本远低于全面铺开之后。
第一步：划清产品边界与共性能力归属
边界划分的产物是一份可查阅、可更新的清单，而不是一次会议上的口头共识。清单至少要覆盖四类字段，每个产品一行，由产品负责人填写并经产品线负责人确认。
| 字段 | 填写内容 | 用途 |
|---|---|---|
| 产品范围 | 该产品负责的业务场景与功能边界，明确包含什么、不包含什么 | 判断新需求应落在哪个产品 |
| 目标用户 | 主要服务的用户群体与使用场景 | 识别用户重叠与体验冲突 |
| 核心能力 | 该产品自主建设并对外提供的能力清单 | 识别能力重复建设 |
| 对外接口 | 向其他产品提供的接口、数据或服务，以及调用方式 | 作为依赖提出的依据 |
共性能力的归属判定，建议按三条规则依次判断：第一，看该能力是否被两个以上产品共同调用，若是则倾向集中到一个承接方；第二，看该能力是否需要独立的技术演进节奏和安全合规要求，账号、支付、权限这类能力通常符合；第三，看承接方是否具备相应的维护人力。三条规则冲突时，以“调用方数量多且演进节奏独立”为优先。消息、账号、支付、权限这类能力集中归属后，应在清单中标注承接方、接口形式和服务级别约定，避免调用方各自猜测。
边界争议不可避免，关键是有裁决角色和记录方式。建议由产品线负责人担任裁决人，争议双方各自提交书面说明，裁决结论写入边界清单的变更记录，注明日期、争议点和结论。记录的作用是让同类争议有先例可循，减少重复讨论。裁决周期建议控制在一周内，超期未决的争议先按现状执行并标记为待定，避免阻塞依赖流程。
第二步：建立跨产品依赖的提出与承诺流程
依赖流程的目标是让每一次跨产品协作都有明确的提出方、承接方、交付内容和时间承诺。流程分四个环节，每个环节有输入、动作、输出和完成标志。
| 环节 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提出 | 提出方的需求说明与期望时间 | 提出方填写依赖单，注明提出方、承接方、依赖内容、期望时间、影响范围 | 依赖单 | 承接方确认收到并指定评估人 |
| 评估 | 依赖单 | 承接方评估技术可行性、工作量与排期影响，给出可承诺时间或替代方案 | 评估结论 | 承接方在依赖单上填写评估意见与承诺时间 |
| 承诺 | 评估结论 | 双方确认交付内容、时间与验收标准，纳入各自排期 | 已承诺的依赖单 | 双方负责人确认，依赖单状态变为“已承诺” |
| 跟踪 | 已承诺的依赖单 | 按协同例会节奏更新状态，交付后由提出方验收 | 状态记录与验收结论 | 提出方确认验收通过，依赖单关闭 |
依赖单的字段设计要能支撑后续跟踪，建议至少包含：提出方与提出人、承接方与承接人、依赖内容描述、期望时间、承诺时间、影响范围（涉及哪些产品版本或客户）、当前状态、验收标准。影响范围一栏常被忽略，但它决定了依赖变更时需要通知谁。
依赖变更与取消需要明确规则，否则承诺会失去约束力。建议约定：承诺时间变更须由承接方在依赖单上说明原因和新时间，经提出方确认后生效；依赖内容变更视为新依赖，原依赖单关闭并重新走提出流程；提出方取消依赖须书面说明，承接方已投入的工作量记录在案，作为后续排期参考。变更记录保留在依赖单的历史中，例会复盘时可直接引用。
第三步：定角色、定交付物
跨产品协同中常见的失效情形是“每件事都有人参与，但没有人对结果负责”。解决办法是把角色和交付物绑定，每个角色在协同流程中都有明确的输入和输出。
| 角色 | 主要职责 | 输入 | 输出交付物 |
|---|---|---|---|
| 产品负责人 | 对本产品的范围、排期和对外承诺负责 | 业务目标、依赖单、边界清单 | 产品范围说明、依赖承诺、验收结论 |
| 协同接口人 | 作为本产品对外协同的统一入口，负责依赖单的收集、转达与状态同步 | 依赖单、例会纪要 | 依赖台账更新、跨产品沟通记录 |
| 共性能力负责人 | 对集中承接的共性能力的建设、接口稳定性和服务约定负责 | 各产品的能力需求、接口调用情况 | 能力接口说明、服务级别约定、版本发布计划 |
| 产品线负责人 | 裁决边界争议，审视跨产品依赖的整体健康度 | 边界争议说明、依赖台账、例会升级事项 | 裁决结论、资源调整决定 |
接口人机制是这套角色设计的关键。接口人不承担决策职责，但承担信息汇聚和状态同步职责，避免每个产品负责人都直接对接所有其他产品，导致沟通路径爆炸。接口人应由熟悉本产品排期和依赖情况的人担任，产品经理或技术负责人均可。
团队人数较少时，接口人机制可以简化：由产品负责人兼任接口人，依赖单仍统一登记，但评估和承诺环节合并为一次会议完成。简化的是沟通层级，依赖单和台账不能省，否则依赖状态会重新退回到口头协调。
依赖台账和状态跟踪如果放在文档或表格里维护，容易出现版本分散、状态不同步的问题。ONES 的工作项与文档协作能力可以承载这一环节：依赖单作为工作项记录提出方、承接方、承诺时间和状态，相关边界清单与接口说明放在文档中与工作项关联，各产品成员在同一处查看和更新，减少台账多份并存的情况。具体字段和流程仍按本文设计配置。
第四步：用协同例会和依赖台账保持节奏
流程和角色建立后，需要固定节奏让依赖持续可见。协同例会和依赖台账是配套的两个工具：台账负责记录状态，例会负责推动状态变化。
协同例会的建议频率是每两周一次，跨产品依赖密集时可调整为每周一次。参与角色包括各产品负责人、协同接口人、共性能力负责人，产品线负责人按需参加。议程建议固定为四项：上周承诺依赖的完成情况、本周新增依赖的评估结论、逾期与阻塞事项的处理决定、边界争议的裁决请求。每项议程限定时间，会议产出以台账更新和待办事项为准，不追求讨论充分。
依赖台账的字段设计应支持状态判断和责任追溯，建议包含：依赖编号、提出方、承接方、依赖内容、承诺时间、当前状态、阻塞原因、责任人、最近更新时间。状态取值建议统一为“待评估、已承诺、进行中、已交付待验收、已关闭、已逾期”六类，避免各产品自造状态导致口径不一。更新责任归属承接方接口人，提出方在验收后更新为已关闭。
逾期与阻塞需要升级路径。建议规则：承诺时间前一周状态仍为“进行中”且无明确进展的，由接口人在例会上标记风险；超过承诺时间未交付的，状态自动转为“已逾期”，由产品线负责人在下一次例会上决定调整排期还是调配资源；阻塞原因涉及第三方或外部条件的，升级至产品线负责人协调。升级路径写进流程说明，避免每次临时商量。
示例：一条跨产品依赖链怎么跑通
以下为演示情景，用于说明流程如何运转，不代表特定组织的真实案例。
情景：产品A面向外部客户提供业务办理功能，需要产品B提供统一的消息通知能力，用于向客户发送办理进度提醒。产品B已承接公司级消息能力，属于共性能力。
第一步，产品A的产品负责人在边界清单中确认消息能力归属产品B，接口形式为产品B提供的消息发送接口。第二步，产品A接口人填写依赖单：提出方产品A，承接方产品B，依赖内容为接入消息发送接口并支持办理进度模板，期望时间为下个版本发布前，影响范围为产品A的两个客户项目。第三步，产品B接口人指定评估人，评估后确认接口已具备、模板配置需两天工作量，承诺时间比期望时间晚一周，并在依赖单上注明原因。第四步，双方负责人在协同例会上确认承诺时间与验收标准，依赖单状态变为“已承诺”，纳入各自排期。
执行期间，产品B接口人每周更新状态。模板配置完成前，状态为“进行中”；配置完成并通知产品A联调后，状态为“已交付待验收”；产品A完成联调并确认提醒正常发送后，状态更新为“已关闭”。若产品B因其他任务延迟，状态转为“已逾期”，由产品线负责人在例会上决定是否调整产品A的版本范围。
这条依赖链体现的可迁移规律有三点：依赖单在提出时就写清影响范围，使变更时能快速判断通知对象；承诺时间与期望时间的差异在评估环节显性化，避免后期才发现排期冲突；验收由提出方完成，承接方不能自行关闭依赖。适用边界在于，该示例假设共性能力已有明确承接方；若消息能力尚未集中，需先完成边界划分再走依赖流程。
完成检查：协同机制是否真的运转起来
机制是否落地，可以用四类检查项逐项核对。每类检查项都要求有可查证的证据，而不是负责人口头确认。
| 检查类别 | 检查项 | 通过标准与证据 |
|---|---|---|
| 边界清单 | 每个产品是否有范围、目标用户、核心能力、对外接口四项内容；共性能力是否标注承接方 | 清单可查阅，最近三个月内有更新记录；抽查一项共性能力，能指出承接方和接口说明 |
| 依赖流程 | 近期跨产品依赖是否都有依赖单；评估与承诺是否有记录；变更是否留痕 | 抽查三条依赖，均能查到提出方、承接方、承诺时间和状态变更历史 |
| 角色分工 | 每个产品是否指定接口人；共性能力是否有负责人；争议是否有裁决记录 | 角色名单可查；抽查一次边界争议，有裁决结论和记录日期 |
| 台账节奏 | 协同例会是否按频率召开；台账状态是否及时更新；逾期是否有升级处理 | 近三次例会均有议程和台账更新记录；抽查一条逾期依赖，有升级处理结论 |
需要立即阻断并返工的情况有三类：依赖单长期缺失，跨产品协作仍靠口头协调，说明流程未真正启用；台账状态与实际交付长期不一致，说明更新责任未落实，台账失去参考价值；边界争议反复出现且无裁决记录，说明裁决角色缺位，依赖流程会在评估环节反复卡住。出现上述情况时，应暂停扩展新的产品组合，先回到对应步骤补齐产出，再继续推进。
常见问题
产品线负责人不在场时，边界争议和依赖逾期怎么处理？
建议在流程说明中预先约定代理规则：产品线负责人可指定一名代理裁决人，代理人在授权范围内作出结论，并在下次例会向产品线负责人报备。依赖逾期在无人裁决时，先按现状执行并标记为待定，同时把事项列入下一次例会的第一项议程，避免因等待裁决而阻塞交付。代理规则和授权范围应写入边界清单的变更记录，便于后续追溯。
两个产品都认为自己应该承接同一项共性能力，怎么判定？
按三条规则依次判断：该能力是否被两个以上产品共同调用；是否需要独立的技术演进节奏和安全合规要求；候选承接方是否具备维护人力。三条规则冲突时，以“调用方数量多且演进节奏独立”为优先。若仍无法达成一致，由产品线负责人裁决，双方各自提交书面说明，结论写入边界清单变更记录并注明日期、争议点和结论，作为同类争议的先例。
团队规模小，接口人机制可以省掉吗？
可以简化，但不宜完全取消。人数较少时由产品负责人兼任接口人，评估和承诺环节合并为一次会议完成，减少沟通层级。依赖单和台账仍需保留，否则依赖状态会退回到口头协调，逾期和变更无从追溯。随着产品数量增加，再逐步把接口人职责分离出来。
依赖已经承诺，但承接方中途要延期，提出方应该怎么应对？
承接方须在依赖单上说明延期原因和新时间，经提出方确认后生效，变更记录保留在依赖单历史中。提出方可以据此判断影响范围：若涉及已承诺的客户版本，需评估是否调整自身版本范围，或由产品线负责人在例会上决定资源调配。若延期导致状态转为已逾期，按升级路径处理，避免双方私下协商后台账失真。
协同机制运行一段时间后，怎么判断它是否在起作用？
看四类证据：边界清单可查阅且近三个月有更新；抽查三条近期依赖均能查到提出方、承接方、承诺时间和状态变更历史；每个产品有指定接口人，边界争议有裁决记录；近三次例会均有议程和台账更新，逾期依赖有升级处理结论。若跨产品协作仍主要靠口头协调、台账状态与实际交付长期不一致，说明机制未真正启用，应暂停扩展新的产品组合，先补齐对应产出。
