研发平台落地效果评估要回答的核心问题是：平台是否真正进入研发流程并产生可核验的结果。建议围绕“使用覆盖—流程运行—数据质量—协作时效—业务结果”五层建立指标，并按POC、业务试点、正式推广、首次上线培训四个阶段调整权重与通过标准。每个指标需写清公式、分子分母、统计时间窗和单位，结论以多指标组合加定性证据为准。
要点总览（TL;DR）
- 落地效果评估按“使用覆盖—流程运行—数据质量—协作时效—业务结果”五层组织，每层选2至4个核心指标，避免指标堆砌导致取数成本过高。
- 每个指标写清公式、分子、分母、时间窗和单位，例如活跃用户占比=统计期内有操作的去重用户数÷应纳入统计的授权用户数，分母需明确排除离职、外包、试用账号。
- POC、业务试点、正式推广、首次上线培训四个阶段的评估重点不同，通过标准由组织结合基线和业务目标设定，不套用统一达标线。
- 分母为零或样本过小时标注“不适用”或“样本不足”，跨团队数据不可比时按团队分层比较，不做简单汇总。
- 结论以多指标组合加定性证据相互印证，单指标上升不能直接归因为平台落地成功。
评估目标：落地效果要回答哪几个问题
评估对象是研发平台在组织内的整体落地情况，包括账号开通、流程承载、数据沉淀和协作方式改变，单一功能是否好用只是其中一个侧面。把评估对象限定为“平台整体”，可以避免用某个报表是否美观、某个页面是否流畅来代替落地判断。
落地效果可以拆成四个递进层次来提问。第一层是平台可用：功能是否满足关键场景、性能与权限是否达到使用条件。第二层是被使用：目标团队和角色是否在平台内完成日常工作，而不是开通后闲置。第三层是流程跑通：需求、任务、缺陷、评审等对象是否在平台内形成完整流转，状态和责任人清晰。第四层是产生业务结果：交付周期、返工率、缺陷逃逸等结果指标是否出现可解释的变化。四个层次依次递进，前一层不成立时，后一层的数据很难作为落地证据。
评估服务于阶段决策，不同阶段回答的问题不同。POC阶段判断“能不能用、关键流程能否跑通”；业务试点判断“目标团队是否愿意用、流程完成率是否稳定”；正式推广判断“跨团队数据是否一致、协作时效是否改善”；首次上线培训判断“操作是否正确、支持成本是否可控”。同一套指标在不同阶段的权重和通过标准应有差异，评估前先明确当前处于哪个阶段，再决定看哪些指标。
指标体系与统计范围
五层指标每层选2至4个核心指标即可，指标过多会显著增加取数成本，也会让评估结论失焦。下表给出常用指标清单及其统计对象和时间窗，团队可在此基础上增减。
| 层级 | 指标 | 统计对象 | 建议时间窗 |
|---|---|---|---|
| 使用覆盖 | 活跃用户占比 | 应纳入统计的授权用户 | 周或月 |
| 使用覆盖 | 团队开通率 | 目标团队清单 | 月 |
| 流程运行 | 需求流转完成率 | 统计期内创建的需求 | 迭代或月 |
| 流程运行 | 缺陷闭环率 | 统计期内关闭的缺陷 | 月 |
| 流程运行 | 任务按时完成率 | 统计期内到期任务 | 迭代 |
| 数据质量 | 关键字段完整率 | 需求、任务、缺陷记录 | 周或月 |
| 数据质量 | 状态及时更新率 | 发生状态变更的工作项 | 周 |
| 协作时效 | 评审平均周期 | 统计期内完成的评审 | 月 |
| 协作时效 | 交接平均等待时长 | 跨角色交接的工作项 | 月 |
| 业务结果 | 需求交付周期 | 统计期内交付的需求 | 迭代或季度 |
| 业务结果 | 返工率 | 统计期内被退回或重开的工作项 | 月或季度 |
使用覆盖类指标回答“谁在用”，统计对象应是明确的目标用户清单，而不是全部注册账号。流程运行类指标回答“流程是否在平台内走完”，统计对象是平台内创建并应完成流转的工作项。数据质量类指标回答“记录是否可信”，统计对象是进入统计范围的工作项字段。协作时效类指标回答“跨角色配合是否变快”，统计对象是包含评审或交接环节的工作项。业务结果类指标回答“是否带来业务变化”，统计对象是交付物本身，统计周期通常更长。
时间窗需要统一。使用覆盖和数据质量适合按周或按月统计，流程运行适合按迭代或按月统计，业务结果适合按迭代或按季度统计。同一指标在不同报告中应使用相同时间窗，跨期比较时注明起止日期，避免用不同口径的数据直接对比。
数据口径：公式、分母与缺失值处理
指标可复算的前提是公式、分子、分母和排除项都写清楚。以下给出典型口径，团队应结合自身账号体系和流程定义调整，调整后固定下来并在评估报告中附口径说明。
| 指标 | 公式 | 分母说明 | 时间窗与单位 | 缺失值规则 |
|---|---|---|---|---|
| 活跃用户占比 | 统计期内有操作的去重用户数 ÷ 应纳入统计的授权用户数 | 排除离职、外包、试用账号，按评估前确认的名单 | 月，百分比 | 分母为零时标注“不适用” |
| 团队开通率 | 已完成开通并产生至少一次有效操作的团队数 ÷ 目标团队总数 | 目标团队清单在评估前锁定 | 月，百分比 | 新纳入团队单独标注，不并入当期 |
| 需求流转完成率 | 统计期内走完规定状态流的需求数 ÷ 统计期内应完成流转的需求数 | 排除评估期内取消且已标注原因的需求 | 迭代或月，百分比 | 状态缺失的记录单列，不计入分子 |
| 关键字段完整率 | 关键字段均非空的工作项数 ÷ 统计范围内工作项总数 | 关键字段清单在评估前定义 | 周或月，百分比 | 字段未启用时标注“不适用” |
| 评审平均周期 | 评审完成时间减提交时间之和 ÷ 完成评审数 | 仅统计统计期内完成的评审 | 月，小时或天 | 样本少于约定数量时标注“样本不足” |
| 返工率 | 被退回或重开的工作项数 ÷ 统计期内完成的工作项数 | 排除因需求变更主动重开的记录，或单独统计 | 月或季度，百分比 | 重开原因未记录时单列说明 |
分母为零或样本过小时，应标注“不适用”或“样本不足”，不要记为0。把无数据的团队记为0会拉低整体均值，也会掩盖真实问题。跨团队数据不可比时按团队分层比较，例如不同业务线的需求粒度、评审习惯差异较大，直接汇总会失真；分层后再看整体趋势，并在报告中说明分层依据。
排除项要在评估前确定并留档。离职、外包、试用账号是否计入活跃用户，取决于评估想回答的问题：看组织真实使用情况时排除试用账号，看推广覆盖面时可单独统计试用转正情况。口径一旦确定，同一轮评估内不再调整，跨轮比较时注明口径变化。
计算与评估步骤
从取数到形成结论，可以按以下步骤执行，每一步都留下可复核的记录。
- 确定评估范围与基线期。明确评估覆盖哪些团队、哪些流程对象，选定推广前的基线时间段，基线期数据用于对比而非直接作为达标线。
- 按口径取数并清洗。从平台报表、工作项记录和账号清单中取数，核对重复记录、测试数据和异常状态，清洗规则写入评估说明。
- 计算各层指标并与基线对比。按统一时间窗计算，输出指标值、样本量和变化方向，样本不足的指标单独标注。
- 设定分阶段通过标准。定量指标给出目标区间或变化方向，定性指标列出证据类型和判定标准，例如POC阶段以关键流程演示记录和问题清单为证据，培训阶段以考核通过率和工单量为证据。
- 形成评估结论与改进项。结论按层次归纳，区分“已达到”“部分达到”“未达到”，每个未达到项对应具体改进动作和责任人。
分阶段通过标准可以按下表组织，具体阈值由组织根据基线和业务目标设定，不套用统一达标线。
| 阶段 | 评估重点 | 定量参考 | 定性证据 |
|---|---|---|---|
| POC | 可用性与关键流程跑通 | 关键流程完成率、阻塞问题数 | 流程演示记录、问题清单与关闭情况 |
| 业务试点 | 使用覆盖与流程完成率 | 活跃用户占比、需求流转完成率、字段完整率 | 试点团队访谈、周会记录 |
| 正式推广 | 跨团队数据一致性与协作时效 | 团队开通率、评审平均周期、状态及时更新率 | 跨团队评审记录、数据核对结果 |
| 首次上线培训 | 操作正确率与支持成本 | 培训考核通过率、支持工单量 | 考核记录、工单分类与关闭时长 |
取数与核对环节可以借助平台内已有记录减少人工采集误差。ONES Project 提供多种报表，以多种图表形态实时呈现项目表现，并支持自定义数据范围和维度；任务工时统计、看板与燃尽图可用于核对进度记录，缺陷状态分布统计可用于核对缺陷闭环情况。评估时把这些记录作为取数来源，仍需按前述口径清洗和复核，具体报表类型与字段配置以实际版本为准。
示例：一个业务试点的指标计算
以下为演示情景，数字仅用于说明计算过程。某业务试点覆盖3个团队，评估前确认应纳入统计的授权用户为120人，统计时间窗为一个月。平台记录显示，该月有操作的去重用户为78人；统计范围内工作项共600条，关键字段均非空的为510条；应完成流转的需求为150条，实际走完规定状态流的为126条。
- 活跃用户占比 = 78 ÷ 120 = 65.0%。说明约三分之二的授权用户在当月有实际操作，剩余用户需要结合角色判断是否属于应使用人群。
- 关键字段完整率 = 510 ÷ 600 = 85.0%。说明仍有15%的工作项存在字段缺失，需检查是录入习惯问题还是字段设置问题。
- 需求流转完成率 = 126 ÷ 150 = 84.0%。说明大部分需求在平台内走完流程，未完成的24条需按状态分布分析卡点位置。
解读时要把三个指标放在一起看。活跃用户占比达到预期但字段完整率偏低，可能说明用户在用平台但录入规范尚未建立；流转完成率较高但活跃用户占比偏低，可能说明少数用户承担了大部分流程操作。异常项要回到原始记录核对，例如确认未完成流转的需求是否集中在某个团队或某个状态。据此判断试点是否继续：若关键流程完成率和数据质量达到试点前设定的标准，且未完成项有明确改进计划，可以进入推广准备；若活跃用户占比持续偏低且访谈反馈集中在可用性问题，应先解决阻塞问题再扩大范围。
解读与限制：指标不能替代什么
单指标只反映一个侧面。活跃用户占比高不等于流程跑通，流转完成率高也不等于业务结果改善。评估结论应使用多指标组合，并说明各指标之间的关系，避免用某一个数字给落地效果下总体判断。
指标上升与业务改善之间需要证据支撑。交付周期缩短可能来自平台流程优化，也可能来自需求拆分方式变化或人员调整。要建立可解释的关联，需要结合变更记录、访谈和评审记录，说明平台改动与结果变化之间的时间关系和影响路径，不能把相关性直接当作因果保证。
数据采集本身可能改变行为。当团队知道活跃度和字段完整率被考核时，可能出现为达标而操作、集中补录字段的情况。评估时应保留原始记录，关注数据分布是否异常集中，并把定性证据与定量指标配合使用。常用证据包括：试点团队访谈记录、跨团队评审纪要、培训考核结果、支持工单分类与关闭时长。定量指标指出方向和幅度，定性证据解释原因和条件，两者相互印证后再形成评估结论。
常见问题
评估指标应该选多少个才合适？
建议每层选2至4个核心指标，五层合计控制在10至15个以内。指标过多会显著增加取数、清洗和核对的工作量，也会让评估结论失焦。选择时优先保留能直接回答当前阶段问题的指标：POC阶段重点看关键流程完成率和阻塞问题数，业务试点重点看活跃用户占比、流转完成率和字段完整率。其余指标可以作为观察项记录，不纳入当期结论判断。
基线期数据缺失，还能做落地效果评估吗？
可以评估，但结论的表述方式需要调整。没有基线期时，改用阶段目标值或同阶段团队之间的横向比较作为参照，并在报告中注明“无基线，采用目标值对比”。同时尽快补齐基线记录，例如从历史工单、会议纪要或旧系统导出数据中还原推广前的交付周期和返工情况。跨轮评估时注明基线口径的变化，避免把不同来源的数据直接相减。
定性证据具体收集哪些材料，怎么和定量指标对应？
常用材料包括试点团队访谈记录、跨团队评审纪要、培训考核记录、支持工单分类与关闭时长。对应方式是按指标逐项挂证据：活跃用户占比偏低时，用访谈记录说明是角色覆盖不足还是操作门槛问题；流转完成率未达标时，用状态分布和评审纪要定位卡点环节。证据材料注明收集时间、对象和数量，与指标使用同一统计时间窗，便于复核。
评估中发现数据异常集中，应该怎么处理？
先回到原始记录核对，确认是真实使用变化还是采集方式导致。常见情形包括考核前集中补录字段、少数用户代填大量记录、测试数据混入统计范围。处理方式是把异常记录单列说明，不直接删除；必要时按团队或按周拆分数据看分布，再判断是否需要调整口径。若异常来自考核压力引发的行为改变，应在结论中说明这一影响，并用访谈等定性证据补充解释。
评估结论为“部分达到”时，下一步怎么推进？
把未达到项逐条对应到具体改进动作、责任人和完成时间，区分是平台配置问题、流程设计问题还是使用习惯问题。平台配置类问题在下一轮评估前完成调整并复测；流程设计类问题需要与业务负责人共同确认状态流和字段要求；使用习惯类问题通过培训、模板和抽查逐步改善。改进完成后用同一口径复测，形成前后对比记录，再决定是否进入下一阶段。
