多团队协作运行一段时间后，评估重点应放在团队之间的依赖、交接与共同交付上。建议从交付流动、依赖与协同、质量与返工、协作行为四类指标入手，每项固定分子分母、时间窗和取数来源，再与协作机制运行前的基线对比。ONES可承载工作项状态流转与过程数据记录，作为部分指标的取数载体。
要点总览（TL;DR）
- 多团队协作评估的对象是团队之间的依赖、交接与共同交付，建议从交付流动、依赖与协同、质量与返工、协作行为四类指标组合观察。
- 每项指标固定分子、分母、单位、时间窗和取数来源，形成可复算的评估表；分母为零或样本过少时标注样本量，不直接给出比率。
- 评估前先对齐各团队的工作项状态定义与完成标准，口径不一致的团队数据单独标注，避免前置时间和按期交付率系统性失真。
- 计算按基线对比、分组对比、异常回溯、结论标注证据强度的顺序推进，单指标改善不能直接当作协作机制改进的因果结论。
- 示例演示中依赖解除时长从30小时降到20小时、按期交付率从75%升到84%，需结合依赖数量变化和回溯事件一并解读。
评估目标：多团队协作成效要回答什么
多团队协作评估的对象是团队之间的协作机制，包括需求在团队间的流转、依赖的提出与解除、交接环节的等待，以及多个团队共同完成一次交付的过程。单个团队内部的迭代执行效率属于另一层问题，放在团队自身的复盘里更合适。把评估对象定在跨团队层面，指标才有明确的归属，改进动作也才能落到机制上。
评估周期通常与协作机制的调整节奏对齐。常见做法是协作机制运行一个季度后做首次评估，之后按季度或按发布周期滚动观察。基线选择有两种：一是协作机制运行前的历史数据，适合有连续数据记录的组织；二是机制运行初期的一个完整周期，适合历史数据口径不一致的情况。基线一旦确定，后续评估应沿用同一口径，否则趋势对比失去意义。
评估结果主要服务于三类决策：判断哪些协作机制需要调整，例如同步会议的频率与形式；识别依赖治理的重点，例如哪类依赖反复出现、卡在哪个环节；校准同步节奏，例如联合评审是否过密或过疏。评估结论应指向具体机制和具体团队组合，避免停留在“协作变好或变差”的整体判断上。
指标与范围：四类协作指标及适用边界
四类指标分别观察协作的不同侧面，单看一类容易得出片面结论，组合使用才能形成较完整的判断。下表列出各类指标及其衡量侧面。
| 类别 | 指标 | 衡量的协作侧面 |
|---|---|---|
| 交付流动 | 跨团队需求前置时间、依赖等待时长、按期交付率 | 需求在多个团队之间流转的速度与可预期程度 |
| 依赖与协同 | 跨团队依赖数量与解除时长、阻塞升级响应时长 | 依赖的产生密度、解除效率与阻塞处理机制是否有效 |
| 质量与返工 | 跨团队联调缺陷密度、返工占比、发布回滚次数 | 交接与集成环节的质量成本 |
| 协作行为 | 联合评审与同步频次、决策形成时长、跨团队协作满意度 | 协作活动的实际发生情况与参与方感受 |
交付流动类指标回答“跨团队交付是否更快、更可预期”；依赖与协同类指标回答“依赖是否被及时识别和解除”；质量与返工类指标回答“交接和集成是否带来额外返工”；协作行为类指标回答“协作活动是否真实发生、决策是否顺畅”。前三类以系统记录为主，第四类部分依赖人工记录和问卷。
本文不覆盖单迭代执行效率，例如单个团队的迭代速率、迭代内任务完成情况；也不覆盖项目集日常依赖排期与协同调度，这类工作属于运行管理，评估的是排期执行情况而非协作机制成效。工具的价格、版本与认证对比同样不在讨论范围内。
数据口径：分子分母、时间窗与取数来源
指标要可复算，每项都必须固定分子、分母、单位和统计时间窗。下表给出建议口径，组织可在此基础上按自身状态定义微调，但调整后应保持稳定。
| 指标 | 计算口径 | 单位 | 时间窗 | 取数来源 |
|---|---|---|---|---|
| 跨团队需求前置时间 | 需求从进入首个团队受理状态到最终交付状态的中位时长；分子为各需求时长之和，分母为完成交付的需求数 | 天 | 评估周期内完成交付的需求 | 工作项状态流转记录 |
| 依赖等待时长 | 依赖从提出到被响应之间的时长；分子为各依赖等待时长之和，分母为已响应的依赖数 | 小时或天 | 评估周期内提出的依赖 | 依赖记录及状态变更 |
| 按期交付率 | 按承诺日期完成交付的需求数除以承诺交付的需求总数 | 百分比 | 评估周期内到期且已承诺的需求 | 工作项计划日期与实际完成日期 |
| 依赖解除时长 | 依赖从提出到关闭的时长；分子为各依赖解除时长之和，分母为已关闭依赖数 | 小时或天 | 评估周期内关闭的依赖 | 依赖记录 |
| 阻塞升级响应时长 | 阻塞从标记升级到首次有效响应之间的时长；分母为已升级的阻塞数 | 小时 | 评估周期内升级的阻塞 | 工作项阻塞标记与评论记录 |
| 联调缺陷密度 | 联调阶段发现的缺陷数除以对应交付的需求数或故事点数 | 个/需求或个/点 | 评估周期内完成联调的交付 | 缺陷记录与关联工作项 |
| 返工占比 | 因交接或集成问题重新打开或退回的工作项数除以完成的工作项总数 | 百分比 | 评估周期内完成的工作项 | 工作项状态回退记录 |
| 发布回滚次数 | 评估周期内发生的回滚次数，按发布批次统计 | 次 | 评估周期内所有发布 | 发布记录 |
| 联合评审与同步频次 | 评估周期内跨团队联合评审与同步会议的实际召开次数，可按团队组合拆分 | 次 | 评估周期 | 会议记录或评审记录 |
| 决策形成时长 | 跨团队议题从提出到形成明确结论的时长；分母为已形成结论的议题数 | 天 | 评估周期内提出并结案的议题 | 议题记录或评审纪要 |
| 跨团队协作满意度 | 问卷各题项得分的均值，按参与团队分别统计并标注样本量 | 分（量表） | 评估周期末一次采集 | 问卷 |
分母为零或样本过少时，不直接给出比率，改为标注样本量并说明“样本不足，暂不计算比率”。例如评估周期内没有发生发布回滚，回滚次数记为0次是有效数据；而按期交付率的分母若只有两三个需求，比率波动会很大，应同时列出需求数，供读者判断可信度。
跨团队数据可比的前提是统一状态定义与完成标准。各团队对“完成”“已交付”“已关闭”的理解不一致时，前置时间和按期交付率会系统性失真。评估前应先对齐工作项状态机，明确交付完成的判定条件，并检查各团队的历史数据是否按同一标准记录。口径不一致的团队，其数据应单独标注，不直接并入整体计算。
在取数载体上，ONES可自动记录和统计资源投入、缺陷分布、工作项滞留时间等研发过程数据，工作项状态流转记录可作为前置时间、返工占比等指标的取数基础；其敏捷研发管理方案连接需求提出方、产品经理、研发、测试等角色，支持多团队并行开发，便于在同一套工作项体系下对齐状态定义。依赖记录、阻塞升级和评审纪要的具体统计方式，需结合组织实际配置核验后再确定口径。
计算与评估步骤：从取数到结论
第一步，确定基线与对照周期。选定协作机制运行前的一个完整周期作为基线，或采用机制运行初期的首个周期。基线周期与评估周期应长度相近，避免季节性因素干扰，例如季度末集中发布带来的交付波动。
第二步，按口径逐项计算并记录样本量。每项指标同时输出数值、分子、分母和时间窗，形成一张可复算的评估表。样本量低于约定阈值的指标标注“参考”，不参与结论排序。
第三步，按团队规模或依赖强度分组对比。依赖强度可按评估周期内跨团队依赖数量划分，例如高依赖组与低依赖组；团队规模可按参与人数或团队数量划分。分组对比能区分“整体变化”与“某类团队组合的变化”，避免平均值掩盖局部问题。
第四步，对异常值回溯具体协作事件。前置时间明显偏长的需求、解除时长异常高的依赖、反复回滚的发布，都应回到具体工作项，查看交接节点、评审记录和阻塞处理过程，确认是偶发事件还是机制性卡点。
第五步，形成结论并标注证据强度。结论应写明指标变化方向、变化幅度、样本量和回溯到的事件；证据强度可分为“有系统记录支撑”“有记录但样本少”“仅有主观反馈”三档，供决策者判断可信程度。
示例：一个季度的跨团队协作评估
以下为演示情景，数据仅用于说明口径代入方式，不代表任何真实组织的实测结果。
某组织三个团队共同交付一条业务线，协作机制运行一个季度后做首次评估。基线为机制运行前的一个季度。评估周期内共提出跨团队依赖40个，其中已关闭36个，依赖解除总时长为720小时，则依赖解除时长均值为720÷36＝20小时；基线周期同类数据为已关闭30个、总时长900小时，均值30小时。解除时长均值从30小时降到20小时，同时依赖数量从30个增至40个，说明依赖密度上升但解除效率提高，需结合依赖来源进一步判断。
评估周期内承诺交付的需求为50个，按期完成42个，按期交付率42÷50＝84%；基线周期承诺40个、按期完成30个，按期交付率75%。按期交付率提高9个百分点，但需注意评估周期需求数更多，交付压力更大，这一改善的含金量高于单纯数字对比。
回溯异常值时发现，未按期交付的8个需求中有5个涉及同一对团队之间的接口联调，联调阶段缺陷密度为每需求1.8个，明显高于其他团队组合的0.9个。进一步查看评审记录，该组合的联合评审在评估周期内只召开2次，而其他组合平均5次。这一线索指向联调前的接口约定不充分，可作为下一周期依赖治理和评审节奏调整的输入，但尚不能据此断定评审频次是唯一原因。
解读与限制：指标能说明什么、不能说明什么
单指标适合描述现象，组合指标才适合支撑判断。依赖解除时长缩短，可能来自协作机制改进，也可能来自依赖数量减少或依赖类型变简单；按期交付率提高，可能来自协作顺畅，也可能来自承诺日期放宽。把交付流动、依赖协同、质量返工和协作行为四类指标放在一起看，并核对样本量和分组差异，结论才相对可靠。
指标改善与协作机制改进之间存在因果不确定性。评估周期内可能同时发生了人员调整、需求结构变化、发布节奏改变等因素，这些都会影响指标。建议在结论中写明“与某机制调整同期发生”，而非“由某机制导致”，并对关键结论做一次交叉验证。
数据不可比和样本偏差是常见限制。跨团队状态定义不一致会让前置时间和按期交付率失真；评估周期过短会让比率波动放大；自评问卷受近期事件和团队关系影响，得分高低不完全反映协作质量。问卷结果宜与系统记录对照使用，例如满意度下降的团队组合，其依赖解除时长是否也同步变长。
交叉验证可采用三种方式：一是同一指标用两个来源核对，例如前置时间同时用状态流转记录和评审纪要抽查；二是定量指标与回溯到的事件对照，确认数字变化有具体事件支撑；三是把评估结论交给参与协作的团队复核，请他们指出与体感不符的指标，再回到数据查找原因。经过交叉验证仍无法解释的指标，应标注为待观察项，留到下一周期继续跟踪。
常见问题
协作机制运行不满一个季度，可以先做评估吗？
可以，但结论应标注为阶段性观察。周期过短时，比率类指标波动会被放大，例如按期交付率的分母只有少量需求时，一两个需求延期就会带来明显变化。建议在短周期评估中优先看依赖解除时长、阻塞升级响应时长这类以事件为单位的指标，并同时列出样本量；比率类指标留到积累一个完整周期后再与基线对比。
各团队的工作项状态定义不一致，历史数据还能用吗？
可以分两步处理。先对齐当前的状态机与交付完成判定条件，确保评估周期内的数据按同一标准记录；再检查基线周期的历史数据是否可换算到新口径。无法换算的团队数据单独标注，不并入整体计算，只作为分组参考。若历史数据整体口径差异过大，可改用机制运行初期的首个完整周期作为基线，并在结论中说明基线选择的原因。
满意度问卷得分下降，是否说明协作变差了？
不能直接下这个结论。问卷得分受近期事件、团队关系和填写时点影响，宜与系统记录对照使用。例如某团队组合满意度下降，可核对其依赖解除时长、返工占比是否同步变差；若系统记录没有对应变化，更可能是主观感受波动或问卷样本偏差。问卷结果建议按团队组合分别统计并标注样本量，避免用整体均值掩盖局部差异。
依赖数量增加，是协作变差还是业务变化？
两种可能都存在，需要结合解除效率和依赖来源判断。依赖数量增加可能来自业务拆分更细、交付范围扩大，也可能来自接口约定不清导致反复提依赖。建议同时看依赖解除时长和依赖来源分布：解除时长缩短、依赖集中在少数团队组合且类型相似，更可能是业务结构变化；解除时长拉长、同类依赖反复出现，则指向协作机制问题。示例中依赖从30个增至40个而解除时长从30小时降到20小时，就属于需要进一步回溯来源的情形。
评估结果要交给谁复核，复核重点是什么？
建议交给参与协作的各团队负责人和一线成员复核。复核重点是找出与体感明显不符的指标，例如数据显示按期交付率提高，但团队普遍反映交付压力更大，就需要回到承诺日期设定和需求范围变化中查找原因。复核后仍无法解释的指标标注为待观察项，留到下一周期继续跟踪，不强行给出结论。
