研发平台试点的验收标准，要能把“平台好不好用”转成可复核的结论。建议围绕试点目标拆成三类条件：关键业务场景在平台上跑通并留痕、数据质量达到事先约定的阈值、目标角色的使用与协作行为按流程发生。每条标准都写明指标定义、分子分母、统计时间窗、数据来源和通过线，通过线在试点启动时依据基线与业务目标确定并冻结，验收时逐项计算、汇总判定。
要点总览（TL;DR）
- 验收标准围绕三类可核验条件展开：关键业务场景在平台上跑通并留痕、数据质量达到约定阈值、目标角色的使用与协作行为按流程发生。
- 每条标准都要写清指标定义、分子分母、统计时间窗、数据来源和通过线；统计范围在试点启动时冻结，验收时不再增补团队或工作项类型。
- 通过线用试点前基线加目标增量，或按业务底线设定，并在启动会上确认后冻结，避免事后调整口径。
- 判定按逐项判定、汇总结论、处置未达标项三步走，结论区分全部达标、核心项达标但次要项未达标、核心项未达标三种情形。
- 验收指标反映试点期内的使用与流程状态，不能直接等同于研发效能提升；通过验收不等于全面推广，未通过也不等于平台不可用。
试点验收要回答什么问题
验收不是给平台打一个总体印象分，而是回答三个可以分别取证的问题：试点团队的关键流程是否真的在平台上完成，数据是否足以支撑后续管理和决策，目标角色是否形成了稳定的使用与协作行为。三个问题对应三类判定对象，任何一类缺失，验收结论都不完整。
第一类是场景跑通。选取试点范围内有代表性的业务流程，例如需求从提出到进入迭代、缺陷从发现到关闭、版本从评审到发布，确认这些流程在平台上走完，并留下可追溯的记录。判定依据是流程实例和状态流转记录，而非培训签到或口头反馈。
第二类是数据可信。平台上的工作项字段、状态、工时、关联关系是否按约定填写，关键字段的完整率和口径一致性是否达到阈值。数据不可信时，即使流程跑通，后续的报表和度量也无法使用。
第三类是行为形成。目标角色是否实际登录并操作，评审、交接、状态更新是否按约定节奏发生。行为类指标要限定在试点团队名单和试点周期内统计，避免把试点外的偶发使用计入。
验收结论通常有两种用途：一是判断是否具备扩大推广的条件，二是明确扩大推广前需要补齐哪些条件。因此判定结果应逐项给出，未达标项要写清差距和补救动作，而不是只给一个“通过”或“不通过”。验收范围严格限定在试点团队、试点场景和试点周期内，结论不外推到未参与试点的团队。
验收指标与统计范围怎么划
指标宜少而可算，按四层组织：流程完成类、数据质量类、使用行为类、稳定性类。每层选两到四个指标即可，指标过多会稀释判定重点，也增加取数和复核成本。指标清单应形成一张表，逐行写明定义、分子、分母、时间窗和数据来源。
| 指标 | 定义 | 分子 | 分母 | 时间窗 | 数据来源 |
|---|---|---|---|---|---|
| 流程按时完成率 | 纳入范围的工作项在约定时限内完成流转的比例 | 按时完成流转的工作项数 | 应完成流转的工作项数 | 试点周期内 | 工作项状态流转记录 |
| 关键字段完整率 | 关键字段已填写的工作项占比 | 关键字段均非空的工作项数 | 纳入统计的工作项总数 | 试点周期末快照 | 工作项字段导出 |
| 活跃角色覆盖率 | 目标角色中在试点期内有有效操作的比例 | 有有效操作的目标角色人数 | 试点团队目标角色总人数 | 试点周期内 | 操作记录或登录与操作日志 |
| 评审留痕率 | 应评审事项中留下评审记录的比例 | 有评审记录的事项数 | 应评审事项数 | 试点周期内 | 评审记录、文档关联记录 |
统计范围要在试点启动时写死三件事：试点团队名单，按人员或组织单元列明；纳入的工作项类型，例如需求、任务、缺陷分别是否计入；时间窗起止，精确到日期，并说明截止时点取当日结束还是固定时刻快照。范围一旦冻结，验收时不再增补团队或工作项类型。
分母口径是验收争议的高发点，需要提前约定。按应发生数计算，分母是“按流程本应发生流转或评审的工作项数”，能反映流程执行的完整性；按实际发生数计算，分母只统计实际进入流程的工作项，适合流程入口尚不稳定的阶段。两种口径不能混用，同一指标在试点期内保持一种口径。缺失值的处理也要写明：关键字段为空的工作项计入分母但不计入分子；无法判断是否按时的记录标记为“不可判定”，单独列出数量，不默认算作达标或未达标。
数据从哪里取、证据怎么留
验收数据优先取自平台内的客观记录，访谈和抽样作为补充。平台报表适合取汇总值，工作项字段导出适合复算明细，操作记录用于判断行为是否发生。访谈用于解释异常原因，不单独作为达标依据。每项指标都要指定一个主数据源和一个复核方式，避免同一指标出现两个互相矛盾的数字。
| 指标类型 | 主数据源 | 证据形式 | 复核方式 |
|---|---|---|---|
| 流程完成类 | 工作项状态流转记录、报表 | 导出明细表、状态时间截图 | 抽取若干工作项逐条核对状态时间 |
| 数据质量类 | 工作项字段导出 | 导出表、字段完整率计算表 | 按固定随机种子抽取样本重算 |
| 使用行为类 | 操作记录、登录记录 | 按角色汇总的操作清单 | 与团队名单比对，确认人员范围 |
| 稳定性类 | 故障与工单记录 | 事件清单、影响时长记录 | 与使用方确认事件是否影响试点场景 |
证据留存要满足“他人可复算”：导出表保留原始字段和导出时间，抽样清单写明抽样规则和样本编号，评审记录保留事项、参与人和结论。截图只作为辅助，关键结论以可导出的明细为准。若平台报表支持自定义数据范围和维度，应在试点启动时把验收所需的报表配置好并固定下来，避免验收时临时调整统计口径。ONES Project 提供多种报表并支持自定义数据范围和维度，工作项也可配置状态与属性，可作为承载流程记录和字段统计的基础；具体报表能否按验收所需的时间窗和团队范围导出明细，需在试点配置阶段确认。
数据不可比时要有处理规则。试点中途变更了字段定义、状态含义或统计范围，应记录变更日期和影响范围，变更前后的数据分段统计或注明不可直接比较；因重复录入、测试数据等原因需要剔除的记录，写明剔除规则和剔除数量，保留剔除前的原始数据。所有口径调整都应在验收报告中留痕，不能只保留调整后的结果。
验收怎么算、怎么判
计算前先固定公式，再逐项代入。以下三个公式覆盖最常见的验收场景，单位均为百分比，保留一位小数，四舍五入规则在试点启动时约定。
- 关键字段完整率 = 关键字段均非空的工作项数 ÷ 纳入统计的工作项总数 × 100%。
- 流程按时完成率 = 在约定时限内完成流转的工作项数 ÷ 应完成流转的工作项数 × 100%。
- 活跃角色覆盖率 = 试点期内有有效操作的目标角色人数 ÷ 试点团队目标角色总人数 × 100%。
通过线有两种确定方法，可组合使用。第一种是基线加增量：试点前先测一次同口径基线，例如字段完整率基线为 62%，结合业务需要设定提升到 85%，则 85% 即为通过线。第二种是业务底线：某些指标有不可退让的下限，例如应评审事项必须全部留痕，则通过线为 100%。通过线应在试点启动会上确认并写入验收方案，试点期间不因中期数据好看或难看而调整。没有基线数据时，用业务底线或同类团队的历史数据作为参照，并在报告中注明通过线的来源。
判定按“逐项判定—汇总结论—处置未达标项”三步走。逐项判定时，每项指标给出实际值、通过线、是否达标和证据位置；汇总结论区分全部达标、核心项达标但次要项未达标、核心项未达标三种情形，核心项在试点启动时指定，通常包括场景跑通和数据质量各至少一项。未达标项要写明差距、可能原因和补救动作，例如字段完整率不足时，先确认是字段定义不清还是录入环节缺失，再决定补充培训、调整必填规则或延长观察期。判定由试点负责人、业务代表和平台管理员共同确认，避免单一角色既取数又下结论。
一个可复算的验收例子
以下为演示情景，数字用于说明计算过程，不代表任何真实项目。某研发团队选取一个 20 人的试点小组，试点周期为 8 周，纳入统计的工作项为需求与缺陷两类，共 400 个。试点启动时确定三项核心指标及通过线：关键字段完整率不低于 85%，流程按时完成率不低于 80%，活跃角色覆盖率不低于 90%。
第一项，关键字段完整率。400 个工作项中，关键字段均非空的为 332 个，完整率为 332 ÷ 400 × 100% = 83.0%，低于 85% 的通过线，未达标。抽查发现缺失集中在“验收标准”和“计划完成日期”两个字段，前者在缺陷类工作项中本不适用，说明字段适用范围需要按工作项类型区分。
第二项，流程按时完成率。应完成流转的工作项为 360 个，其中在约定时限内完成的为 295 个，按时完成率为 295 ÷ 360 × 100% = 81.9%，达到 80% 的通过线。另有 40 个工作项因流程入口尚未稳定未纳入分母，已在报告中单独列示。
第三项，活跃角色覆盖率。试点小组目标角色共 20 人，试点期内有有效操作的为 17 人，覆盖率为 17 ÷ 20 × 100% = 85.0%，低于 90% 的通过线，未达标。未覆盖的 3 人中，2 人为测试角色，其工作主要通过缺陷流转体现，需确认操作记录是否完整采集。
汇总结论可表述为：流程按时完成率达到通过线，关键字段完整率与活跃角色覆盖率未达标，试点整体判定为“有条件通过”，即在补齐字段适用范围定义、核实测试角色操作记录后进入复评。处置建议包括：按工作项类型配置字段必填规则，重新计算完整率；对测试角色补充操作培训并核对记录采集范围；复评时间窗与原试点周期保持一致口径，不重新起算。这一结论限定在该 20 人小组、需求与缺陷两类工作项和 8 周周期内，不外推到其他团队。
结果怎么解读、有哪些限制
验收指标反映的是试点期内的使用状态和流程执行状态，不能直接等同于研发效能提升。字段完整率提高说明数据更可用，按时完成率提高说明流程执行更稳定，这些是后续度量和改进的前提条件，但效能变化还需要更长的观察周期和更严格的对照设计。把验收指标写成效能结论，容易在推广阶段产生过度承诺。
几类情况会削弱结论的可靠性。分母为零时，例如试点期内没有应评审事项，该指标无法计算，应标注“不适用”而非“达标”；样本过小时，例如目标角色只有三五人，覆盖率每变动一人就是十几个百分点，结论应附人数而非只看百分比；试点期过短时，流程可能尚未走完一个完整周期，按时完成率会偏低或偏高，需要在报告中说明周期覆盖情况。数据采集不完整同样会影响判定，操作记录缺失时应先核实采集范围，再决定是否复评。
验收结论与推广决策是两件事。通过验收说明试点范围内的场景、数据和行为达到了事先约定的条件，可以进入扩大推广的评估，但推广范围、节奏和配套投入仍需单独决策；未通过验收说明存在明确的待补条件，应针对未达标项制定补救计划，平台本身是否可用要结合具体原因判断，例如字段定义不清属于配置问题，操作覆盖不足属于推行问题，二者都不直接说明平台能力不足。把验收结论写成“逐项条件加处置动作”，比给出单一总分更有利于后续决策。
常见问题
试点启动时没有基线数据，通过线怎么定？
没有基线时，可以用业务底线或同类团队的历史数据作为参照，并在验收报告中注明通过线的来源。业务底线适合有硬性要求的指标，例如应评审事项必须全部留痕，通过线直接设为 100%；同类团队历史数据适合流程类指标，取数时保持口径一致，并说明参照团队与试点团队的差异。无论采用哪种方式，通过线都应在试点启动会上确认并写入验收方案，试点期间不因中期数据变化而调整。
试点中途发现指标定义不合理，可以改口径吗？
可以调整，但必须留痕。建议记录变更日期、变更内容和影响范围，变更前后的数据分段统计，或注明不可直接比较。如果调整涉及统计范围或分母口径，应在验收报告中单独说明，并保留调整前的原始数据。更稳妥的做法是把口径调整放在复评阶段处理，原试点周期的判定仍按启动时冻结的口径执行，避免同一周期内出现两套标准。
验收数据用平台报表汇总值，还是导出明细自己算？
建议以可导出的明细为主、报表汇总值为辅。明细便于他人复算，也能定位到具体工作项；报表汇总值适合快速核对总量。两者出现差异时，以明细重算结果为准，并查明差异原因。ONES Project 提供多种报表并支持自定义数据范围和维度，工作项也可配置状态与属性，可作为承载流程记录和字段统计的基础；具体报表能否按验收所需的时间窗和团队范围导出明细，需在试点配置阶段确认。
试点期只有几周，按时完成率偏低能说明平台不好用吗？
不能直接这样判断。试点期过短时，部分工作项可能尚未走完一个完整流程周期，按时完成率会偏低或偏高，报告中应说明周期覆盖情况。同时要区分原因：如果是流程入口尚未稳定、时限约定不清，属于试点设计问题；如果是操作不熟练或状态更新不及时，属于推行问题。建议在结论中附上未纳入分母的工作项数量，并对未达标项给出补救动作，再决定是否延长观察期或复评。
验收通过后，推广范围怎么定？
验收通过说明试点范围内的场景、数据和行为达到了事先约定的条件，可以进入扩大推广的评估，但推广范围、节奏和配套投入仍需单独决策。建议按场景成熟度和团队准备度分批推广，先复制已验证的流程和字段配置，再逐步纳入新的工作项类型和团队。推广阶段可沿用试点期的指标口径做跟踪，便于对比试点与推广后的执行状态。
