研发度量框架应用方案要能落地，通常需要四张表：度量目标与问题表、指标分层与口径表、数据来源与采集责任表、评审节奏与改进闭环表。它们按“为什么度量—度量什么—数据从哪来—结果怎么用”的顺序填写，每张表都保留负责人、状态和复核时间。本文直接给出可复制的空白表、逐字段说明、必填与选填规则、一套完整填写示例，以及后续维护方法。度量结果最终要在工作项和文档中承载，ONES 可作为承载与展示的一环。
要点总览（TL;DR）
- 研发度量框架应用方案可拆成四张表：度量目标与问题表、指标分层与口径表、数据来源与采集责任表、评审节奏与改进闭环表，按“为什么度量—度量什么—数据从哪来—结果怎么用”的顺序填写。
- 每张表都保留负责人、状态和复核时间，后一张表只引用前一张表已确认的编号，避免指标与目标脱节。
- 最小可用填写集覆盖目标编号、业务目标、待验证问题、指标编号、口径说明、数据来源系统、取数方式、评审周期与改进动作等必填字段，缺失必填字段的行不进入评审。
- 填写示例演示了从缩短需求交付周期到评审改进的完整链路，每个指标可追溯到目标，每条数据来源对应一个指标编号。
- 模板需按季度、月度复核并记录版本变更，字段增删以是否有明确填写动作和责任人为判断依据，修改字段时同步更新说明与示例。
可复制空白模板：四张表组成一套应用方案
四张表之间存在明确的引用关系：目标表的问题编号被指标表引用，指标表的指标编号被数据来源表引用，评审表再引用指标编号和问题编号。填写时按顺序推进，后一张表只引用前一张表已确认的编号，避免指标与目标脱节。复制到文档或表格工具时，建议每张表单独占一个工作表或一个章节，编号列设为文本格式，保留“状态”和“复核时间”两列用于跟踪。
表一：度量目标与问题表
| 目标编号 | 业务目标 | 待验证问题 | 度量对象 | 预期用途 | 负责人 | 状态 | 复核时间 |
|---|---|---|---|---|---|---|---|
表二：指标分层与口径表
| 指标编号 | 关联目标编号 | 指标名称 | 层级（结果/过程/能力） | 口径说明 | 统计周期 | 数据粒度 | 负责人 | 状态 | 复核时间 |
|---|---|---|---|---|---|---|---|---|---|
表三：数据来源与采集责任表
| 指标编号 | 数据来源系统 | 取数方式（自动/手工） | 采集频率 | 数据责任人 | 校验方式 | 异常处理 | 状态 | 复核时间 |
|---|---|---|---|---|---|---|---|---|
表四：评审节奏与改进闭环表
| 评审编号 | 关联指标编号 | 关联目标编号 | 评审周期 | 参与角色 | 评审输入 | 改进动作 | 验证方式 | 负责人 | 状态 | 复核时间 |
|---|---|---|---|---|---|---|---|---|---|---|
字段说明：每个字段填什么、由谁提供
字段说明解决“怎么填”的问题。填写口径尽量写成可判断的句子，例如“统计周期”填“按迭代”或“按自然月”，避免只写“定期”。提供角色指对该字段内容负责的人，确认方式指该字段由谁复核后生效。
表一字段说明
| 字段名 | 含义 | 填写口径 | 提供角色 |
|---|---|---|---|
| 目标编号 | 目标的唯一标识 | 如 G-01，按顺序编号，不复用 | 研发效能负责人 |
| 业务目标 | 度量要支撑的业务结果 | 写清对象和期望变化，如“缩短需求交付周期” | 研发负责人 |
| 待验证问题 | 当前无法凭经验判断的问题 | 写成疑问句，一个问题对应一个目标 | 研发负责人与团队代表 |
| 度量对象 | 被度量的团队、项目或流程 | 写明范围，如“某产品线全部迭代” | 研发效能负责人 |
| 预期用途 | 结果用于哪类决策 | 如资源调整、流程改进、复盘参考 | 研发负责人 |
| 负责人 | 该目标推进的责任人 | 填具体人名或岗位 | 研发负责人指定 |
| 状态 | 目标当前进展 | 草稿/已确认/执行中/已关闭 | 负责人更新 |
| 复核时间 | 下次检查该目标的时间 | 填具体日期 | 负责人确认 |
表二字段说明
| 字段名 | 含义 | 填写口径 | 提供角色 |
|---|---|---|---|
| 指标编号 | 指标的唯一标识 | 如 M-01，与目标编号区分前缀 | 研发效能负责人 |
| 关联目标编号 | 该指标服务的目标 | 填表一中已确认的编号，可多对一 | 研发效能负责人 |
| 指标名称 | 指标的业务叫法 | 用团队通用名称，避免同义多写 | 研发效能负责人 |
| 层级 | 指标在框架中的位置 | 结果层看交付结果，过程层看流程环节，能力层看团队与工程质量 | 研发效能负责人 |
| 口径说明 | 指标如何计算与统计 | 写清分子分母、时间范围与排除条件；具体公式可另文维护 | 数据责任人 |
| 统计周期 | 指标更新频率 | 按迭代、按周或按自然月 | 数据责任人 |
| 数据粒度 | 统计到哪一级 | 团队级、项目级或工作项级 | 数据责任人 |
| 负责人 | 指标口径维护人 | 填具体人名或岗位 | 研发效能负责人指定 |
| 状态 | 指标当前状态 | 草稿/已确认/试运行/已停用 | 负责人更新 |
| 复核时间 | 下次检查口径的时间 | 填具体日期 | 负责人确认 |
表三字段说明
| 字段名 | 含义 | 填写口径 | 提供角色 |
|---|---|---|---|
| 指标编号 | 引用表二的指标 | 只填已确认状态的指标编号 | 数据责任人 |
| 数据来源系统 | 数据所在系统或台账 | 写系统名称或手工台账名称 | 数据责任人 |
| 取数方式 | 数据如何取得 | 自动同步或手工整理，手工需注明整理人 | 数据责任人 |
| 采集频率 | 数据多久采集一次 | 与表二统计周期保持一致或更细 | 数据责任人 |
| 数据责任人 | 对数据准确性负责的人 | 填具体人名或岗位 | 研发效能负责人指定 |
| 校验方式 | 如何确认数据可信 | 如抽样核对、与源系统总数比对 | 数据责任人 |
| 异常处理 | 数据缺失或异常时的动作 | 写清补数、标注或暂停使用的规则 | 数据责任人 |
| 状态 | 采集链路状态 | 待接入/已接入/异常/已停用 | 数据责任人更新 |
| 复核时间 | 下次检查采集链路的时间 | 填具体日期 | 数据责任人确认 |
表四字段说明
| 字段名 | 含义 | 填写口径 | 提供角色 |
|---|---|---|---|
| 评审编号 | 评审活动的唯一标识 | 如 R-01，按顺序编号 | 研发效能负责人 |
| 关联指标编号 | 本次评审关注的指标 | 引用表二编号，一次评审聚焦少量指标 | 研发效能负责人 |
| 关联目标编号 | 本次评审对应的目标 | 引用表一编号 | 研发效能负责人 |
| 评审周期 | 多久评审一次 | 按迭代、按月或按季度 | 研发负责人 |
| 参与角色 | 参加评审的角色 | 写明角色而非泛称“相关人员” | 研发负责人 |
| 评审输入 | 评审前需准备的材料 | 如指标报表、问题清单、上期改进项 | 数据责任人 |
| 改进动作 | 评审后要执行的动作 | 写清动作、对象和完成标志 | 研发负责人与团队 |
| 验证方式 | 如何确认改进有效 | 指明用哪个指标、在什么周期内观察 | 研发效能负责人 |
| 负责人 | 改进动作的责任人 | 填具体人名或岗位 | 研发负责人指定 |
| 状态 | 评审与改进进展 | 待评审/评审中/改进中/已验证/已关闭 | 负责人更新 |
| 复核时间 | 下次检查改进效果的时间 | 填具体日期 | 负责人确认 |
必填与选填：哪些字段缺失就不能进入评审
必填字段决定一张表能否进入评审。最小可用填写集是：目标表的目标编号、业务目标、待验证问题、负责人；指标表的指标编号、关联目标编号、指标名称、口径说明、负责人；数据来源表的指标编号、数据来源系统、取数方式、数据责任人；评审表的评审编号、关联指标编号、评审周期、参与角色、改进动作、负责人。缺少任一必填字段，该行不进入评审，先退回补充。
| 表 | 必填字段 | 选填字段及适用情形 | 缺失处理 |
|---|---|---|---|
| 度量目标与问题表 | 目标编号、业务目标、待验证问题、负责人 | 度量对象、预期用途、状态、复核时间：目标尚在讨论时可暂缺，进入评审前补齐 | 退回目标提出人补充，不进入指标设计 |
| 指标分层与口径表 | 指标编号、关联目标编号、指标名称、口径说明、负责人 | 层级、统计周期、数据粒度、状态、复核时间：试运行阶段可先填部分，正式发布前补齐 | 口径说明缺失的指标不得采集数据 |
| 数据来源与采集责任表 | 指标编号、数据来源系统、取数方式、数据责任人 | 采集频率、校验方式、异常处理、状态、复核时间：首次接入可先简填，稳定后补充 | 无数据责任人的指标不纳入报表 |
| 评审节奏与改进闭环表 | 评审编号、关联指标编号、评审周期、参与角色、改进动作、负责人 | 关联目标编号、评审输入、验证方式、状态、复核时间：首次评审可先填基本项 | 无改进动作的评审不记录为闭环 |
选填字段的取舍依据是当前阶段：目标尚在讨论时，预期用途可以后补；指标试运行时，统计周期可以先按现有数据能力填写；数据链路刚接入时，校验方式可以先用抽样核对占位。选填不等于可长期空缺，进入正式评审前应逐项确认。
填写示例：一个迭代度量方案如何填满四张表
以下为演示情景，用于说明四张表的填写结果，不代表真实客户案例。场景设定：某产品研发团队希望缩短需求从进入到交付的周期，并按迭代复盘改进效果。
示例表一：度量目标与问题表
| 目标编号 | 业务目标 | 待验证问题 | 度量对象 | 预期用途 | 负责人 | 状态 | 复核时间 |
|---|---|---|---|---|---|---|---|
| G-01 | 缩短需求交付周期 | 交付周期偏长主要卡在哪个环节？ | 该产品线全部迭代 | 流程改进与迭代复盘 | 研发负责人甲 | 已确认 | 2025-07-01 |
示例表二：指标分层与口径表
| 指标编号 | 关联目标编号 | 指标名称 | 层级 | 口径说明 | 统计周期 | 数据粒度 | 负责人 | 状态 | 复核时间 |
|---|---|---|---|---|---|---|---|---|---|
| M-01 | G-01 | 需求交付周期 | 结果层 | 需求进入开发到上线的自然日天数，按迭代统计中位数 | 按迭代 | 工作项级汇总到团队级 | 效能负责人乙 | 已确认 | 2025-07-01 |
| M-02 | G-01 | 评审等待时长 | 过程层 | 需求进入评审到评审通过的天数，排除撤回重提 | 按迭代 | 工作项级 | 效能负责人乙 | 试运行 | 2025-07-15 |
示例表三：数据来源与采集责任表
| 指标编号 | 数据来源系统 | 取数方式 | 采集频率 | 数据责任人 | 校验方式 | 异常处理 | 状态 | 复核时间 |
|---|---|---|---|---|---|---|---|---|
| M-01 | 项目管理工作项记录 | 自动同步 | 按迭代 | 数据管理员丙 | 与上线记录抽样比对 | 缺失时标注并暂停该迭代统计 | 已接入 | 2025-07-01 |
| M-02 | 评审流程记录 | 自动同步 | 按迭代 | 数据管理员丙 | 与评审单数量核对 | 撤回重提单独标注 | 待接入 | 2025-07-15 |
示例表四：评审节奏与改进闭环表
| 评审编号 | 关联指标编号 | 关联目标编号 | 评审周期 | 参与角色 | 评审输入 | 改进动作 | 验证方式 | 负责人 | 状态 | 复核时间 |
|---|---|---|---|---|---|---|---|---|---|---|
| R-01 | M-01、M-02 | G-01 | 按迭代 | 研发负责人、效能负责人、数据管理员、团队代表 | 迭代指标报表、上期改进项 | 针对评审等待环节，明确评审前置条件并在迭代启动时同步 | 观察 M-02 连续两个迭代的变化 | 研发负责人甲 | 改进中 | 2025-08-01 |
示例中每个指标都能追溯到目标，每条数据来源都对应一个指标编号，评审记录同时引用指标和目标，形成“量化—实施—分析—改进”的闭环。ONES 研发效能管理解决方案对交付效率、交付质量、进度情况、资源效率等效能数据进行直观展示，并支持选取数据集、自定义报表和图表展示；当工作项数据已在 ONES Project 中承载时，Performance 可实时同步业务数据，减少手工整理数据源的工作。这些能力对应的是表三的取数方式和表四的评审输入，模板本身仍按上述字段独立填写。
调整与维护方法：框架随团队变化如何更新
模板需要随团队规模、流程和工具变化更新。字段增删的判断依据是：新增字段能否对应一个明确的填写动作和责任人；删除字段是否已连续两个评审周期无人使用且不影响追溯。指标口径变化时，保留旧口径记录并新增版本，避免历史数据无法解释。
版本与变更记录
| 版本号 | 变更日期 | 变更内容 | 变更原因 | 影响范围 | 确认人 |
|---|---|---|---|---|---|
| V1.0 | 四张表首次发布 | ||||
| V1.1 |
定期复核节奏
- 每季度复核一次目标表：确认目标是否仍有效，关闭已完成或已失效的目标。
- 每季度复核指标表：检查口径是否仍与数据实际一致，停用长期无数据的指标。
- 每月检查数据来源表：确认采集链路状态，处理异常和待接入项。
- 每次评审后更新评审表：记录改进动作状态，未闭环项带入下期。
复核责任人为研发效能负责人，数据责任人配合确认数据链路，研发负责人确认目标与改进动作。模板文件建议放在团队共用的知识库中，保留版本号和变更记录；在 ONES 中，度量方案文档与工作项可以放在同一协作空间，指标报表通过数据集和自定义报表生成，评审结论回写到工作项或文档，便于下次复核时直接对照。模板的字段、说明和示例保持同一版本，修改字段时同步更新字段说明表和填写示例，避免不同角色按不同口径填写。
常见问题
团队刚开始做研发度量，四张表可以只填其中一两张吗？
可以分阶段推进，但建议至少先填表一和表二。表一确定度量要回答的问题，表二把问题转成可统计的指标；缺少这两张表，后续数据采集和评审容易变成无目标的数字汇总。表三和表四可以在指标口径确认后逐步补齐，例如先手工整理数据来源，再接入自动同步，评审节奏也可以从每月一次开始。
需要留意的是，表三中无数据责任人的指标不纳入报表，表四中无改进动作的评审不记录为闭环，这两条在分阶段推进时同样适用。
指标口径在评审后需要调整，历史数据怎么处理？
建议保留旧口径记录并新增版本，不直接覆盖原字段。具体做法是在表二的口径说明中标注版本号，在表五的变更记录中写明变更日期、变更原因和影响范围，历史报表按当时口径解释。这样在跨周期对比时，能区分数据变化和口径变化带来的差异。
如果口径调整影响多个指标，先确认关联目标是否仍然成立，再统一更新表二和表三，避免数据来源与口径说明不一致。
评审会上发现某个指标长期没有数据，应该停用还是继续保留？
先判断原因再决定。如果是采集链路未接入或数据责任人缺位，按表三的异常处理规则补数或标注，暂不进入正式报表；如果是该指标已连续两个评审周期无人使用且不影响追溯，可以在表二中把状态改为已停用，并在变更记录中说明原因。
停用不等于删除，保留编号和口径说明有助于后续复盘时理解当时的度量范围。重新启用时沿用原编号或新开编号，需在变更记录中写清。
模板放在文档工具里，和放在工作项管理工具里有什么区别？
放在文档工具里便于多人同时编辑字段说明、填写示例和变更记录，适合方案设计和评审前的准备阶段；放在工作项管理工具里便于把改进动作直接变成可跟踪的任务，适合评审后的执行阶段。两种方式可以配合使用：方案文档承载四张表和字段说明，改进动作回写到工作项，评审时对照工作项状态检查闭环。
ONES 的文档与工作项可以在同一协作空间中使用，指标报表通过数据集和自定义报表生成，评审结论回写到工作项或文档，便于下次复核时直接对照。具体配置方式以团队实际使用的工具为准。
四张表的字段可以按团队情况增减吗？
可以，但要有判断依据。新增字段前先确认它对应一个明确的填写动作和责任人，否则容易变成无人维护的空列；删除字段前确认它已连续两个评审周期无人使用且不影响追溯。必填字段的增减影响最大，调整后要同步更新字段说明表、必填选填对照表和填写示例，保持三者一致。
字段调整后建议记录版本号和变更原因，并在下一次评审时向参与角色说明变化，避免不同角色按不同口径填写。
