衡量敏捷组织协同，建议把问题拆成三组可复算的指标：协同效率看跨团队协作响应与对齐耗时，依赖解决看依赖从提出到关闭的周期与积压，跨团队交付看多团队共同交付项的完成率、周期与返工。每个指标都要写清分子、分母、时间窗、单位和缺失值处理，再结合依赖记录、评审结论等定性证据解释结果。本文给出一套可直接套用的口径与计算步骤，适用于季度复盘和转型阶段检查。
要点总览（TL;DR）
- 协同评估建议拆成三类指标：协同效率看跨团队评审与协作请求的响应耗时，依赖解决看依赖关闭周期、积压量与按期解决率，跨团队交付看共同交付项完成率、交付周期与返工率。
- 每个指标都要写清分子、分母、统计粒度、时间窗和单位；时长统一按工作日计，比例保留一位小数，分母为零时记为“不适用”而不是 0。
- 计算流程为取数清洗、按团队对聚合、按交付项聚合、定量与定性结合判定、建立自身基线做趋势对比，不套用外部通用达标线。
- 指标反映协作现象，不直接证明改善原因；样本过少、团队规模差异大时先标注不可比，单指标不宜作为团队绩效的全部依据。
- ONES 可承载依赖与交付项的工作项记录，并基于系统内流转数据形成效能分析指标，具体内置指标以产品实际提供为准。
评估目标：协同效果要回答哪几个问题
协同评估先定决策问题，再选指标。敏捷组织在规模化之后，团队各自的迭代执行通常已有基本节奏，真正影响交付的是团队之间的衔接：一个团队等另一个团队的接口、一次跨团队评审拖了两周、多个团队共同负责的交付项在临近截止时才暴露缺口。这些问题无法从单团队的迭代完成情况中看出来，需要单独建立观测口径。
建议把评估目标归为三类问题，每类对应不同的决策用途：
| 评估问题 | 关注对象 | 典型决策用途 |
|---|---|---|
| 团队间协作是否顺畅 | 跨团队评审、对齐会议、协作请求的响应与耗时 | 判断协作机制（评审节奏、接口人设置、沟通渠道）是否需要调整 |
| 依赖是否被及时识别和解决 | 依赖从提出到关闭的周期、未关闭依赖的积压 | 判断依赖管理流程、跨团队排期协调是否有效 |
| 多团队共同交付是否达成 | 共同交付项的完成率、交付周期、返工情况 | 判断跨团队交付计划的可信度与协作成本 |
评估对象是团队之间的协作行为与共同交付结果，单团队内部的迭代执行效率不在本文范围内。评估周期建议与组织的复盘节奏对齐：季度复盘使用完整季度数据观察趋势；转型阶段检查可以按月或按双周观察，重点看依赖积压和共同交付项完成率是否朝预期方向变化。评估结果用于改进协作机制，不宜直接换算成团队或个人绩效得分。
指标与范围：三类指标的定义与边界
三类指标各自衡量不同的对象，混在一起计算会失去解释力。下表给出建议的指标清单与衡量对象，组织可按自身协作形态增减，但同一指标在不同周期之间应保持定义稳定，否则趋势对比不成立。
| 类别 | 指标名 | 衡量对象 |
|---|---|---|
| 协同效率 | 跨团队评审平均耗时 | 一次跨团队评审从发起到形成结论的时长 |
| 协同效率 | 协作请求响应时长 | 一个团队向另一团队提出协作请求到获得首次有效响应的时长 |
| 协同效率 | 对齐会议占比 | 跨团队对齐会议时长占团队总会议时长的比例 |
| 依赖解决 | 依赖关闭周期 | 依赖从记录提出到标记关闭的时长 |
| 依赖解决 | 依赖积压量 | 统计时点仍未关闭的依赖数量 |
| 依赖解决 | 依赖按期解决率 | 在约定解决日期前关闭的依赖占比 |
| 跨团队交付 | 共同交付项完成率 | 计划内由两个及以上团队共同完成的交付项中按期完成的比例 |
| 跨团队交付 | 跨团队交付周期 | 共同交付项从启动到完成的总时长 |
| 跨团队交付 | 跨团队返工率 | 共同交付项完成后因协作问题被退回或重做的比例 |
范围边界需要提前说明。单团队迭代执行层面的度量，例如单个团队的迭代速率、故事点完成情况，属于团队内部管理，不作为本文的协同指标。项目集日常依赖的排期协调、依赖双方的对接会议组织，属于日常运作动作，本文只度量其结果，不展开协调操作本身。工具的价格、版本与认证信息不在本文讨论范围。
数据口径：分子分母、时间窗与缺失值处理
指标可复算的前提是口径写死。下表逐项给出公式、分子、分母、统计粒度与时间窗。所有时长类指标统一以“工作日”为单位，避免周末和假期造成失真；比例类指标以百分比表示，保留一位小数。
| 指标 | 公式 | 分子 | 分母 | 统计粒度与时间窗 |
|---|---|---|---|---|
| 跨团队评审平均耗时 | 评审总耗时 ÷ 评审次数 | 时间窗内各次跨团队评审从发起到形成结论的工作日数之和 | 时间窗内完成的跨团队评审次数 | 按评审事件统计，季度窗口 |
| 协作请求响应时长 | 响应总时长 ÷ 请求数 | 各请求从提出到首次有效响应的工作日数之和 | 时间窗内提出的协作请求数 | 按团队对统计，季度窗口 |
| 对齐会议占比 | 对齐会议时长 ÷ 总会议时长 | 跨团队对齐会议时长 | 同期团队全部会议时长 | 按团队统计，月度或季度窗口 |
| 依赖关闭周期 | 关闭依赖的周期之和 ÷ 关闭依赖数 | 时间窗内关闭的各依赖从提出到关闭的工作日数之和 | 时间窗内关闭的依赖数 | 按依赖记录统计，季度窗口 |
| 依赖积压量 | 未关闭依赖计数 | 统计时点状态为未关闭的依赖数 | 不适用（计数指标） | 按统计时点，月末或季末 |
| 依赖按期解决率 | 按期关闭依赖数 ÷ 关闭依赖总数 | 在约定解决日期前关闭的依赖数 | 时间窗内关闭的依赖总数 | 按依赖记录统计，季度窗口 |
| 共同交付项完成率 | 按期完成交付项数 ÷ 计划交付项数 | 计划完成日期在时间窗内且按期完成的共同交付项数 | 计划完成日期在时间窗内的共同交付项总数 | 按交付项统计，季度窗口 |
| 跨团队交付周期 | 交付项周期之和 ÷ 完成交付项数 | 各共同交付项从启动到完成的工作日数之和 | 时间窗内完成的共同交付项数 | 按交付项统计，季度窗口 |
| 跨团队返工率 | 返工交付项数 ÷ 完成交付项数 | 完成后因协作问题被退回或重做的共同交付项数 | 时间窗内完成的共同交付项总数 | 按交付项统计，季度窗口 |
缺失值与分母为零的处理规则需要统一：分母为零时该指标记为“不适用”，不填 0，也不参与趋势对比；单个记录缺少关键时间字段（如依赖未记录提出时间）时，该记录从对应指标中剔除，同时记录剔除数量，剔除比例超过 20% 时应在结论中标注数据完整性不足。依赖积压量是时点计数，不做平均，直接报告月末或季末数值。
数据来源要求可追溯：依赖类指标依赖依赖记录中的提出时间、约定解决日期与关闭时间；协同效率类指标依赖评审记录与协作请求记录中的发起和响应时间；跨团队交付类指标依赖交付项状态变更记录与计划完成日期。记录字段缺失或状态回退不规范，会直接导致指标失真，因此取数前应先检查这几类记录的完整性。在 ONES 中，需求、任务、缺陷等工作项的状态流转会被系统记录，工作项滞留时间等过程数据可自动统计，依赖与交付项也可以作为工作项承载，使提出时间、关闭时间和状态变更形成可回溯的记录链；ONES 效能管理则基于系统内日常流转数据形成分析指标，并提供面向管理人员、项目经理等角色的仪表盘模板。具体指标是否内置，以产品实际提供为准。
计算与评估步骤：从取数到结论
计算流程分为五步，每步都有明确的产物，便于复核。
- 取数与清洗。按时间窗导出依赖记录、评审记录、协作请求记录和共同交付项清单。检查关键时间字段是否齐全，剔除字段缺失的记录并统计剔除数量。统一时间单位为工作日，统一状态口径，例如“关闭”只认最终关闭状态，中间状态不计入。
- 按团队对聚合。协作请求响应时长按“提出方团队—响应方团队”的团队对聚合，得到每个团队对的平均响应时长。团队对样本少于 5 条时标注“样本不足”，不单独下结论。
- 按交付项聚合。共同交付项完成率、交付周期与返工率以交付项为统计单元，先逐项计算是否按期、周期天数、是否返工，再汇总为比例或平均值。跨团队交付周期可以按参与团队数量分组呈现，观察团队越多周期是否明显拉长。
- 定量与定性结合判定。对每个异常指标，调取对应记录做解释：依赖关闭周期变长，是识别晚、协调慢还是对方排期已满；共同交付项未按期完成，是依赖未解决还是范围变更。定性证据来自依赖记录的处理备注、评审结论和交付项状态变更历史，结论应写明“指标变化 + 记录证据”两层依据。
- 建立基线与趋势对比。用组织自身前几个季度的数据建立基线，观察指标的变化方向和幅度。不套用外部通用达标线；跨团队比较时，团队规模差异较大应按团队对或交付项归一化，或只做同规模团队之间的对比。
判定规则建议事先约定：某项指标连续两个周期朝不利方向变化，且定性记录能对应到具体协作环节，才列为改进项；单周期波动且无记录支撑的，先观察不行动。这样能避免把正常波动误判为协同恶化。
示例：一个季度的协同指标计算
以下为演示情景，数据为虚构，仅用于说明公式与解读方式。
某季度，组织内三个团队（A、B、C）共记录依赖 40 条，其中 32 条在本季度关闭，8 条季末仍未关闭；关闭的 32 条依赖中，从提出到关闭的工作日数合计 384 个工作日，其中 24 条在约定解决日期前关闭。跨团队评审共 20 次，总耗时 90 个工作日。计划本季度完成的共同交付项 25 个，实际按期完成 18 个；完成的 20 个交付项周期合计 300 个工作日，其中 4 个因协作问题返工。
按公式逐步计算：
- 依赖关闭周期 = 384 ÷ 32 = 12.0 个工作日。
- 依赖积压量 = 8 条（季末时点）。
- 依赖按期解决率 = 24 ÷ 32 = 75.0%。
- 跨团队评审平均耗时 = 90 ÷ 20 = 4.5 个工作日。
- 共同交付项完成率 = 18 ÷ 25 = 72.0%。
- 跨团队交付周期 = 300 ÷ 20 = 15.0 个工作日。
- 跨团队返工率 = 4 ÷ 20 = 20.0%。
结果解读：可以成立的结论是，本季度依赖按期解决率为 75%，季末仍有 8 条依赖未关闭，共同交付项完成率 72%，说明跨团队交付计划存在缺口，依赖解决是值得优先检查的环节。不能直接推出的结论包括：不能仅凭返工率 20% 断定协作质量差，因为返工可能来自需求变更；不能把依赖关闭周期 12 个工作日与外部团队比较，因为统计口径和依赖复杂度不同；也不能用这组数据判断某个团队绩效不佳，因为依赖积压可能集中在少数跨团队接口上。下一步应调取 8 条未关闭依赖的记录，确认是识别晚还是协调受阻，再决定是否调整依赖评审节奏。
解读与限制：指标能说明什么、不能说明什么
指标反映的是协作现象，不直接证明协同改善的原因。依赖关闭周期缩短，可能来自依赖管理流程改进，也可能来自本季度依赖本身变简单；共同交付项完成率上升，可能来自协作顺畅，也可能来自计划口径放宽。因此每次解读都应回到记录层面，用依赖处理备注、评审结论和状态变更历史说明变化来源，再决定是否把改进归因于某项机制调整。
以下情形需要特别处理，避免得出错误结论：
- 分母为零或样本过少。某季度没有跨团队评审时，评审平均耗时记为“不适用”；团队对样本少于 5 条时只做参考，不单独排名或下结论。
- 团队规模差异。大团队参与的交付项天然周期更长、依赖更多，跨团队比较前应按团队对或交付项归一化，或限定在同规模团队之间比较。
- 单指标不作绩效依据。任何一个指标都可以被局部优化，例如压缩评审次数会降低评审总耗时但可能增加返工。协同评估应以三类指标的组合变化为准，并与定性证据交叉验证。
- 异常需要解释而非直接处置。指标异常时先查记录，区分是流程问题、数据记录问题还是业务本身变化，再决定改进动作。
把三类指标的口径固定下来、按季度复算并保留记录证据，组织就能在转型过程中持续观察跨团队协作的真实变化，而不是依赖印象或单次汇报做判断。
常见问题
季度内跨团队评审次数很少，评审平均耗时还能用吗？
可以用，但要标注样本条件。评审次数少时，平均耗时容易被一两次长评审拉偏，建议同时报告评审次数和耗时分布，而不是只给一个平均值。若某季度完全没有跨团队评审，该指标记为“不适用”，不填 0，也不参与趋势对比。样本过少时更适合回到评审记录逐条查看，判断耗时集中在哪个环节。
依赖积压量下降，是否说明依赖管理变好了？
不一定。积压量是时点计数，下降可能来自依赖被及时关闭，也可能来自依赖提出变少、记录不规范或统计时点选择不同。建议把积压量与依赖关闭周期、按期解决率放在一起看，并调取季末未关闭依赖的记录，确认是识别晚、协调慢还是排期冲突。只有指标变化与记录证据能对应上，才适合归因到某项机制调整。
多个团队共同交付的项目，完成率按什么口径统计才可比？
建议以共同交付项为统计单元，分母取计划完成日期落在时间窗内的共同交付项总数，分子取其中按期完成的项数。跨周期对比时保持同一口径，不中途改变“按期”的判定标准。参与团队数量差异较大时，可以按参与团队数分组呈现完成率，观察团队越多完成率是否明显下降，避免直接拿不同复杂度的交付项互相比较。
指标数据从哪里取，记录不完整怎么办？
依赖类指标取依赖记录的提出时间、约定解决日期与关闭时间；协同效率类取评审记录和协作请求记录的发起与响应时间；跨团队交付类取交付项状态变更记录与计划完成日期。单个记录缺关键时间字段时，从对应指标中剔除并统计剔除数量，剔除比例超过 20% 应在结论中标注数据完整性不足。在 ONES 中，需求、任务、缺陷等工作项的状态流转会被系统记录，工作项滞留时间等过程数据可自动统计，便于形成可回溯的记录链；ONES 效能管理基于系统内日常流转数据形成分析指标，并提供面向管理人员、项目经理等角色的仪表盘模板，具体指标是否内置以产品实际提供为准。
这套指标可以直接用于团队绩效考核吗？
不建议直接挂钩。协同指标衡量的是团队之间的衔接与共同交付结果，单个指标容易被局部优化，例如压缩评审次数会降低评审总耗时，却可能推高返工率。更稳妥的做法是把三类指标的组合变化作为改进线索，配合依赖记录、评审结论等定性证据定位问题环节，绩效评价另行设计并考虑团队规模、依赖复杂度等差异。
