工时系统试用要回答两个问题：分几段做、找谁来做。建议拆成准备与基线、小范围试点、扩面验证、结论评审四段，周期参考2周、4周、4周、1周，按团队规模和项目节奏调整。样本按角色、项目类型、填报粒度分层抽取，覆盖研发投入的主要场景。本文给出阶段计划表、样本分层表、数据采集表、角色职责矩阵和结论模板，适用于研发工时填报与审批场景；ONES可承接工时登记、审批与资源投入统计，具体配置以实际试用环境为准。
要点总览（TL;DR）
- 试用拆成准备与基线、小范围试点、扩面验证、结论评审四段，周期参考2周、4周、4周、1周，按团队规模、项目节奏和审批链长度调整。
- 样本按角色、项目类型、填报粒度三个维度分层抽取，保证开发、测试、项目负责人、职能支持四类角色和至少两种项目类型被覆盖。
- 过程数据按周采集填报完成率、补填率、审批时长和异常工时占比，体验反馈在阶段末用问卷、访谈和问题登记表收集，口径在启动前固定。
- 结论按通过、有条件通过、暂缓三档汇总，问题清单分级整改后关闭，推广范围、节奏和前置整改项写入决策建议表并留档复用。
- 试用设计提交前用检查清单逐项核对阶段边界、样本覆盖、周期资源、数据口径和结论输出，确认可执行再启动。
试用分几个阶段，每段的范围和周期怎么定
四阶段划分的价值在于把“试系统”变成“逐步验证假设”：第一段确认基础配置可用，第二段验证核心填报流程，第三段验证跨部门扩面后的稳定性，第四段形成推广判断。每段设进入条件和结束标志，避免上一阶段问题带入下一阶段。
| 阶段 | 进入条件 | 范围边界 | 周期参考 | 结束标志与输出物 |
|---|---|---|---|---|
| 准备与基线 | 试用目标、预算和决策人已明确 | 1个管理员团队；配置项目类型、工时字段、审批链；采集1个历史周期的基线数据 | 2周 | 配置清单、基线数据表、试用方案确认单 |
| 小范围试点 | 基础配置通过管理员自测 | 1–2个研发团队，覆盖开发、测试、项目负责人三类角色；填报粒度到任务或工作项 | 4周 | 试点周报、问题登记表、首轮体验反馈 |
| 扩面验证 | 试点阶段无阻断性问题，填报完成率达到约定值 | 扩展至3–5个团队，加入职能支持角色和第二种项目类型；验证跨项目工时归集 | 4周 | 扩面数据汇总、审批时长分析、样本覆盖检查表 |
| 结论评审 | 扩面数据完整，问题清单完成分级 | 不新增试用范围，只做数据核对与结论评审 | 1周 | 试用结论模板、推广决策建议表、留档材料 |
周期可调整的因素主要有三类：团队规模大、审批链超过两级时，试点和扩面各延长1–2周；项目节奏处于版本发布高峰期时，避开该窗口或缩短单周填报验证范围；填报粒度细到任务级时，填报耗时上升，需要留出更多观察周期。阶段范围一旦确定，试用期内不随意加入新部门，新增需求记入问题清单，留到扩面阶段评估。
试用样本怎么选：分层抽样与覆盖要求
样本的代表性决定试用结论能否外推。做法是先按三个维度分层，再在每层内抽取最小样本，最后检查覆盖是否完整。
| 分层维度 | 分层取值 | 最小样本建议 | 覆盖要求 |
|---|---|---|---|
| 角色 | 开发、测试、项目负责人、职能支持 | 每类角色不少于3人，项目负责人不少于2人 | 四类角色全部覆盖，项目负责人必须包含跨项目投入的成员 |
| 项目类型 | 迭代型研发项目、维护型项目、预研或创新型项目 | 每种类型至少1个项目 | 至少覆盖两种类型，主营业项目类型必须包含 |
| 填报粒度 | 按天填报、按任务或工作项填报 | 每种粒度至少1个团队 | 与正式推广拟采用的粒度一致 |
团队总数较少时，按“角色全覆盖、项目类型至少两种”执行，不强求每层最小人数。对照组或基线数据有两种设置方式：一是选取未参与试用的同类型团队，采集其同期工时统计方式作为对照；二是用试用前一个历史周期的填报或统计耗时作为基线。两种方式选其一即可，关键是口径与试用期指标一致。
常见样本偏差包括：只选配合度高的团队，导致填报完成率虚高；只选单一项目类型，无法验证跨项目工时归集；只选全职成员，遗漏兼职或多项目投入角色。规避方法是抽样名单由试用负责人和部门接口人共同确认，抽取后检查角色与项目类型分布，偏差超过一层缺失时补抽。触发样本调整的条件包括：某团队连续两周无法正常填报、关键角色人员离职或转岗、新增项目类型进入试用范围。调整需记录原因和替换名单。
每阶段要收集哪些数据与反馈
数据采集围绕两个目的：判断流程是否跑通、判断体验是否可接受。过程数据按周汇总，体验反馈在阶段末集中收集，两者使用同一份采集表。
| 指标 | 口径说明 | 采集频率 |
|---|---|---|
| 填报完成率 | 应填报人天中实际提交的比例，按周计算 | 每周 |
| 补填率 | 截止日后补填的工时记录占当期记录的比例 | 每周 |
| 审批时长 | 从提交到审批完成的平均时长，按审批链层级分别统计 | 每周 |
| 异常工时占比 | 单日工时超过约定上限、项目归属缺失、重复提交的记录占比 | 每周 |
| 填报耗时 | 单次填报从打开到提交的时长，抽样记录 | 阶段末 |
| 字段理解难度 | 问卷评分，标注具体字段 | 阶段末 |
反馈渠道分三类：结构化问卷用于量化体验评分和字段问题；访谈用于追问原因，每阶段选取3–5名不同角色成员；问题登记表用于记录试用中出现的配置、流程和体验问题，每条记录包含提出人、场景、影响范围和优先级。数据口径统一的原则是：指标定义、统计周期、分母范围在试用启动前写入采集表，阶段间不修改定义；同一成员同一时段的记录以系统导出数据为准，问卷和访谈中的主观评价单独归档，不与过程数据混算。
归档责任人为试用负责人，系统管理员负责导出原始数据，部门接口人负责提交本团队反馈。每阶段结束后3个工作日内完成归档，文件名包含阶段、团队和日期。
角色分工与阶段交付物
试用期最常见的失败原因是责任悬空：管理员配了系统，部门不提交数据，财务或项目管理方不参与结论。用职责矩阵把四类角色的动作固定下来。
| 角色 | 准备与基线 | 小范围试点 | 扩面验证 | 结论评审 |
|---|---|---|---|---|
| 试用负责人 | 制定试用方案、确认样本名单 | 组织周会、汇总问题登记表 | 检查样本覆盖、协调补抽 | 汇总结论、提交评审 |
| 部门接口人 | 提供团队和项目清单 | 督促本团队填报、收集反馈 | 提交扩面团队数据 | 参与评审、确认整改项 |
| 系统管理员 | 完成字段、审批链配置，导出基线数据 | 处理配置问题、导出周数据 | 验证跨项目归集与报表 | 提供数据核对说明 |
| 财务或项目管理对接人 | 确认工时统计口径与成本归集要求 | 抽查数据准确性 | 核对工时与项目投入的一致性 | 给出是否满足管理要求的意见 |
阶段评审会由试用负责人主持，参与人包括部门接口人、系统管理员和财务或项目管理对接人。决策权限按事项划分：阶段是否进入下一段由试用负责人和决策人共同确认；样本调整由试用负责人批准；配置变更由系统管理员执行并记录。交付物统一存放在试用共享目录，按阶段建子目录，版本号采用“阶段-序号”，评审后的修改保留历史版本，不覆盖原文件。
在工时填报与审批环节，ONES支持工时登记日志的查询与导出，并可查看项目和团队的资源投入情况，便于管理员按周导出数据、负责人核对成员在不同项目中的投入比重。试用前需确认导出字段与采集表口径一致，字段清单以实际环境为准。
示例：一个研发团队的四周试点安排
以下为演示情景，用于说明安排方式，不代表真实客户案例。背景设定：一个20人研发团队，包含开发12人、测试4人、项目负责人3人、职能支持1人；同时承担一个迭代型项目和一个维护型项目；填报粒度到任务级，审批链为项目负责人一级审批。
| 周次 | 动作 | 检查点 |
|---|---|---|
| 第1周 | 完成字段和审批链配置，抽取样本：开发6人、测试2人、项目负责人2人、职能支持1人，覆盖两个项目类型；采集上一周期统计耗时作为基线 | 样本覆盖检查通过，基线数据入表 |
| 第2周 | 全员开始按任务填报，管理员每日抽查异常记录，接口人收集字段疑问 | 填报完成率、补填率首次统计 |
| 第3周 | 继续填报，项目负责人完成审批；发放体验问卷，访谈3名成员 | 审批时长按层级统计，问题登记表更新 |
| 第4周 | 核对工时与项目投入的一致性，汇总四周数据，形成试点结论初稿 | 数据完整，问题完成分级 |
四周结束时，试用负责人汇总填报完成率、补填率、审批时长和体验评分，对照准备阶段设定的通过条件形成结论：达到约定值的项目列为通过，存在字段或流程问题但可整改的列为有条件通过，出现阻断性问题的列为暂缓。结论连同问题清单提交评审会，由决策人确认是否进入扩面阶段。
试用结论如何转化为推广决策
结论汇总采用三档口径：通过、有条件通过、暂缓。判断依据在试用启动前设定，常用阈值包括填报完成率不低于约定比例、审批时长在可接受范围内、无阻断性配置问题、体验评分达到约定分值。阈值取值结合组织实际确定，阶段间不调整。
问题清单按影响范围排序：阻断性问题（无法填报、数据错误）优先整改，影响单团队的问题次之，体验优化类问题最后处理。每条问题明确整改责任人和完成时间，整改后由提出人确认关闭，形成闭环。
推广决策建议表包含四项内容：建议推广范围（部门、项目类型、角色）、推广节奏（一次性推开或分批）、前置整改项、需要补充的配置或培训。结论和原始数据一并留档，后续扩大试用或正式上线时可直接复用，避免重复采集基线。
完成检查：试用设计是否可交付
试用方案提交前，用以下清单逐项核对，每项确认后由试用负责人签字。
- 四阶段均有明确的进入条件、范围边界、周期和输出物，阶段之间不重叠。
- 样本覆盖开发、测试、项目负责人、职能支持四类角色，覆盖至少两种项目类型，填报粒度与推广计划一致。
- 周期安排避开版本发布高峰，审批链长度已确认，资源投入与阶段工作量匹配。
- 过程指标定义、统计周期和分母范围已写入采集表，阶段间口径一致。
- 角色职责矩阵已确认到人，交付物存放位置和版本规则已约定。
- 结论三档口径和阈值已提前设定，问题清单有责任人和关闭标准。
- 推广决策建议表模板已准备，留档要求已明确。
常见问题
试用周期一定要按2周、4周、4周、1周执行吗？
这组周期是经验参考区间，不是固定要求。团队规模较大、审批链超过两级时，试点和扩面阶段各延长1–2周更稳妥；项目处于版本发布高峰期时，可以避开该窗口或缩小单周验证范围。调整周期时保持阶段顺序和进入条件不变，把调整原因记录在试用方案里，便于后续对照结论。
参与试用的团队很少，样本还怎么保证代表性？
团队总数少时，优先保证角色全覆盖和项目类型至少两种，不强求每层最小人数。抽样名单由试用负责人和部门接口人共同确认，抽取后检查角色与项目类型分布，出现整层缺失时补抽。样本偏差最常见的来源是只选配合度高的团队，这会让填报完成率虚高，确认名单时应有意识地纳入日常填报习惯一般的团队。
试用期收集的数据和正式推广后的统计口径不一致怎么办？
指标定义、统计周期和分母范围应在试用启动前写入采集表，阶段之间不修改定义。正式推广时沿用同一套口径，才能把试用结论直接作为对比基线。如果推广阶段确实需要调整口径，保留旧口径数据并注明变更时间，避免两段数据混算。
试用中出现阻断性问题，是继续走完阶段还是提前终止？
阻断性问题指无法填报或数据明显错误，这类问题会污染后续阶段的数据，应先暂停当前阶段，由系统管理员定位配置或流程原因，整改并验证后再继续。若整改周期超过一周，可缩小当前阶段范围，把受影响的团队移出样本并记录替换名单，保证阶段结论建立在有效数据上。
试用结论为有条件通过时，推广决策该怎么处理？
有条件通过意味着主要流程已跑通，但存在可整改的字段或流程问题。此时推广决策建议表应写明前置整改项、责任人和完成时间，推广节奏可选择分批推进，先覆盖问题影响小的部门。整改项关闭后再扩大范围，结论和原始数据一并留档，后续扩大试用时可直接复用基线，不必重新采集。
