研发平台POC的验收标准，核心是把“平台好不好用”转成一组可判定的场景问题：围绕试点前冻结的业务场景，为每个场景设定少量关键验收项，并写明指标定义、数据来源、统计时间窗、通过阈值和判定人。定量项要给出公式与分母处理规则，定性项要给出证据清单和评审通过条件，整体结论按场景逐项判定。本文适用于已进入或即将进入POC阶段的研发团队，交付一套可复算、可评审的验收方法。
要点总览（TL;DR）
- 验收标准围绕试点前冻结的业务场景制定，每个场景拆成三到五个可观察的验收项，范围之外的功能表现不进入本次判定。
- 每项定量指标写成口径卡，写明分子、分母、统计对象、时间窗、单位和数据来源；定性项统一证据形式与评审通过条件。
- 判定按五步执行：基线采集、验收期采集、逐项计算比对、定性评审、整体汇总，结论分为通过、有条件通过、不通过。
- 阈值结合基线与场景目标确定，不套用通用达标线；分母为零、样本不足、数据缺失的处理规则事先写入口径卡。
- POC样本小、周期短，结论表述为特定试点条件下的场景达标情况，与全面推广决策分开评估。
POC验收要回答什么问题
POC验收的对象是试点范围内的业务场景与协作流程，范围之外的功能表现不进入本次判定。例如试点只覆盖需求流转、迭代跟踪和缺陷闭环三个场景，那么代码评审、制品管理等未纳入试点的环节，即使平台具备相关能力，也不作为本次验收依据。把验收对象限定在场景上，结论才能对应到团队真实要用的工作方式。
验收结论用于支持选型决策，建议区分三种结果：通过，即全部核心场景达到阈值且无一票否决项；有条件通过，即核心场景基本达标，但存在需要补充验证或配置调整的项，需写明条件与复验方式；不通过，即核心场景未达标或触发一票否决。三种结论都要附上逐项判定明细，避免只给一个总评。
验收启动前需要冻结三份清单：场景清单，写明每个场景的起止环节和参与角色；参与角色清单，写明试点团队、业务代表和平台管理员；判定人清单，写明每个验收项由谁判定、谁复核。冻结之后如需调整，走变更记录，说明调整原因和对结论的影响。这一步的价值在于防止验收期临时加项或换人，导致口径前后不一致。
场景清单框架可以按“场景名称—涉及角色—关键动作—期望产出—验收项编号”五列组织。每个场景拆成三到五个可观察的验收项，验收项描述动作和产出，不描述感受。例如“需求从提出到进入开发的平均等待时长”是可观察项，“需求管理体验流畅”则无法判定。
验收指标与范围怎么划
指标按场景设置，每个场景控制在少量关键项，通常三到五项。指标过多的直接后果是采集成本上升、判定争议增多，反而削弱结论的可信度。选取时优先考虑三类：能反映该场景核心价值的指标、数据在平台内可获取的指标、试点前后可对比的指标。
指标可分为四类，各自回答不同问题：
| 指标类别 | 回答的问题 | 示例 |
|---|---|---|
| 效率类 | 流程是否更快 | 需求平均流转时长、迭代内任务按时完成率 |
| 质量类 | 产出是否更可靠 | 缺陷回归通过率、缺陷平均修复时长 |
| 协作类 | 信息是否更顺畅 | 跨角色交接平均等待时长、评审一次通过率 |
| 可用性类 | 团队是否用得起来 | 试点成员周活跃比例、关键操作完成率 |
范围界定要同时写清纳入和不纳入两部分。纳入部分写明试点的功能模块、团队范围和周期；不纳入部分写明本次不验证的功能、不参与的团队以及原因。常见的不纳入项包括与试点场景无关的模块、需要长期数据积累才能评估的指标、依赖其他系统改造才能验证的集成点。把这些写在验收方案里，可以避免验收期被追问“为什么没测这个”。
范围蔓延的典型信号是验收中期新增场景或新增指标。处理方式是记录为“后续验证项”，不纳入本次判定，或经判定人一致同意后作为有条件通过的观察项，并明确复验时间。
数据口径与证据怎么定
每项定量指标都要写成口径卡，至少包含六个要素：指标名称、分子、分母、统计对象、时间窗、单位。分子分母要写到可以直接代入数据的程度。以“需求平均流转时长”为例，分子是统计期内每个需求从“提出”状态到“进入开发”状态的时间差之和，分母是统计期内完成该流转的需求数，统计对象是试点团队创建的需求，时间窗为验收期最后四周，单位为小时。
数据来源要写明具体获取方式：系统报表导出、操作日志、访谈记录或评审纪要。来源不同，可信度和复核方式也不同。系统导出数据应保留导出时间和筛选条件；访谈记录应注明访谈对象、时间和提纲；评审纪要应包含参与人、结论和异议记录。定性项的证据形式建议统一为“演示录屏或截图＋评审纪要＋问题清单”，留存方式与定量数据一致，便于复核。
缺失数据、样本不足和分母为零需要事先约定处理规则，并且规则要写在口径卡里，不能等到计算时临时决定。常见处理方式包括：
- 分母为零时，该项标注“不适用”，不计入通过率统计，同时说明原因；
- 样本量低于预设下限时，延长观察期或补充定性证据，不直接判定通过；
- 数据缺失比例超过约定上限时，该项判定为“证据不足”，按未通过处理或转入复验；
- 系统数据与人工记录不一致时，以系统导出为准，差异记入问题清单。
口径卡建议一页一项，验收方案定稿时由判定人签字确认。验收期内的口径调整需记录变更，并说明对已采集数据的影响。
验收怎么算、怎么判
执行顺序建议分五步。第一步，试点前采集基线，基线数据的时间窗、统计对象和口径与验收期保持一致，否则前后不可比。第二步，验收期按口径卡采集数据，采集时同步记录导出条件和异常情况。第三步，逐项计算并与阈值比对，每项给出计算过程、结果和判定。第四步，组织定性项评审，按证据清单逐条核对，形成评审结论。第五步，汇总整体结论，区分通过、有条件通过和不通过。
阈值设定结合基线与场景目标确定，不套用通用达标线。常见做法有两种：相对基线改善一定比例，或达到场景目标要求的绝对值。两种方式可以并用，例如效率类指标要求相对基线缩短不低于约定比例，同时绝对时长不超过业务可接受上限。阈值在试点前确定，验收期内不因结果不理想而下调。
定性项的评审流程包括：由场景负责人提交证据材料，判定人对照通过标准逐条核对，评审会记录结论与异议，未通过项写明差距和复验安排。通过标准要具体到可核对的程度，例如“关键操作演示无阻断性问题，遗留问题均有明确处理计划”。
整体汇总规则建议为：核心场景的全部关键项达标，且无一票否决项，判定通过；核心场景关键项多数达标，个别项证据不足或需配置调整，判定有条件通过，并写明条件与复验时间；核心场景关键项未达标或触发一票否决，判定不通过。一票否决项宜少设，通常包括关键场景流程无法跑通、验收所需数据无法导出、存在影响试点团队正常工作的阻断性缺陷。
验收过程中的场景清单、指标数据和评审记录需要有承载方式。ONES Project 支持任务工时统计与看板、燃尽图等进度工具，并提供多种报表呈现项目表现，可将验收项作为工作项跟踪、把采集到的指标数据与评审结论关联到对应场景；ONES Wiki 支持文档关联任务并插入工作项列表，适合存放口径卡、证据清单和评审纪要。报表维度与数据导出粒度需在POC中按实际配置核实，确保满足可复算要求。
一个可复算的验收示例
以下为演示情景，数值仅用于说明计算方法。试点场景为“需求流转”，验收项为“需求平均流转时长”。口径卡设定：分子为统计期内每个需求从“提出”到“进入开发”的时间差之和，分母为统计期内完成该流转的需求数，统计对象为试点团队创建的需求，时间窗为验收期最后四周，单位为小时。
基线期同口径采集结果为平均 96 小时。验收期四周内，完成流转的需求共 40 个，时间差合计 2,880 小时。计算：2,880 ÷ 40 = 72 小时。阈值设定为相对基线缩短不低于 20%，即不高于 76.8 小时。72 小时低于阈值，该项判定通过。
再看分母为零与缺失值的处理。同一场景下另一验收项为“跨角色交接平均等待时长”，验收期内该团队未发生跨角色交接，分母为零。按口径卡规则标注“不适用”，不计入通过率，改由评审会确认该场景是否存在交接环节缺失的问题，并记录为观察项。若某项指标因系统导出失败缺失两周数据，缺失比例超过约定上限，则判定为证据不足，转入复验，复验期补采同口径数据后重新计算。
示例结论：需求流转时长项通过，交接等待项不适用并转观察。该场景整体判定需结合其余验收项，若其余关键项均达标且无一票否决项，场景判定通过；若存在证据不足项，则场景判定为有条件通过，写明复验安排。
结果怎么解读、有哪些限制
POC样本小、周期短，结果的代表性有限。试点团队通常只有一两个，观察期只有数周，指标波动可能来自人员变动、需求结构变化或季节性因素。解读时应说明样本范围和观察期，避免把试点结论直接表述为全组织适用。
指标改善与平台能力之间的因果关系需要谨慎表述。流程时长缩短可能同时来自平台支持、试点期团队注意力集中、流程本身简化等因素。验收结论宜写成“在该试点条件下，该场景达到设定阈值”，而非“平台使效率提升若干”。如需更强的因果判断，需要更长的观察期和对照设计，这通常超出POC的范围。
阈值应结合基线与场景目标确定，不同团队、不同业务类型的合理阈值可能不同。把某个团队的达标线直接套用到其他团队，容易产生误判。验收方案中应写明阈值的设定依据，便于后续复用时调整。
验收结论用于支持选型决策，与全面推广决策是两件事。通过意味着试点场景达到预期，可以进入推广规划；推广还涉及部署方式、权限设计、历史数据迁移和培训安排等事项，需要另行评估。有条件通过的结论应附带明确的复验条件和时间，避免条件长期悬置。
常见问题
试点团队只有一两个，验收结论能代表整个研发组织吗？
不能直接代表。POC的样本范围和观察期有限，指标波动可能来自人员变动、需求结构变化或季节性因素。验收结论宜写成“在该试点条件下，该场景达到设定阈值”，并在报告中写明参与团队、观察期和场景范围。如果要把结论用于全组织推广，需要补充更多团队的同口径数据，或把推广作为独立阶段另行评估。
验收期发现某项指标的数据导不出来，应该怎么处理？
先按口径卡中约定的缺失处理规则执行：数据缺失比例超过约定上限时，该项判定为“证据不足”，转入复验，复验期补采同口径数据后重新计算。如果缺失原因是平台导出能力不满足验收要求，应把这一情况记入问题清单，作为有条件通过的观察项，并明确复验时间和所需配置。验收期内不宜临时更换数据来源，否则前后口径不可比。
有条件通过之后，复验要验到什么程度才算结束？
复验范围限定在未达标或证据不足的验收项，不必重跑全部场景。复验前写明三项内容：需要补充的数据或证据、复验的时间窗、判定人。复验结论仍按原口径卡计算和评审，达到阈值即转为通过；仍未达标的，记录差距并说明对推广决策的影响。条件长期悬置会让选型决策失去依据，建议在验收方案中约定复验的最晚时间。
一票否决项设多少合适，哪些情况适合放进去？
一票否决项宜少设，通常控制在两到三项，只覆盖会让试点无法继续的情形。常见的有：关键场景流程无法跑通、验收所需数据无法导出、存在影响试点团队正常工作的阻断性缺陷。把一般性的体验问题或个别指标未达标放进一票否决，会让整体结论过于刚性，失去有条件通过的调节空间。
验收过程中的场景清单、指标数据和评审记录放在哪里比较合适？
关键是让验收项、数据和结论能互相对应。可以用 ONES Project 把每个验收项作为工作项跟踪，用报表呈现进度与指标数据；用 ONES Wiki 存放口径卡、证据清单和评审纪要，并关联到对应任务。报表维度与数据导出粒度需要在POC中按实际配置核实，确认能满足可复算要求后再定稿口径卡。
