工时活动分类要能长期用起来，起点是明确它要回答哪些管理问题，再据此设计层级和维度，最后用分类表、填报模板和审核规则把判断标准固定下来。本文按“结构设计—分类表编写—角色分工—填报审核—示例—验收”的顺序展开，适合正在建立或调整工时分类体系的研发团队、PMO 和财务接口人参考。
要点总览（TL;DR）
- 先写清分类要回答的管理问题，再反推层级和维度：活动类型做分类主线，项目、工作性质等作为附加字段，避免把维度塞进层级。
- 分类表至少包含编码、名称、定义、典型示例、排除项、归属大类和版本生效日期，定义用可观察的动作描述，排除项成对指向相邻条目。
- 设计、填报、审核、维护四类角色分开定责，审核人依据分类表判断，遇到未覆盖情况记录后交维护责任人处理，不自行新增条目。
- 填报用下拉选择活动条目并强制关联项目或任务，按周填报；审核围绕完整性、合理性、跨项目一致性，退回原因留痕。
- 验收看覆盖度、定义一致率、填报耗时、审核依据和维护机制，正式运行一个周期后复核“其他”类占比再小幅调整。
先定分类要回答的问题：分类结构与层级怎么设计
工时活动分类的第一步是确定用途。分类要支撑人力投向分析，就需要能看出时间花在需求、开发、测试、运维等哪类活动上；要支撑项目投入核算，就需要每条工时能归到具体项目或任务；要支撑能力与产能盘点，就需要区分不同角色、不同技术领域的投入。用途不同，分类的粗细和维度组合也不同。建议先用一句话写下分类要回答的核心问题，例如“本季度研发人力在各项目和各活动类型上的分布”，再据此反推结构。
层级设计：一级大类、二级活动族、三级具体活动
常见做法是三层结构。一级大类回答“这类活动属于什么性质”，数量控制在五到八个，例如需求与设计、编码实现、测试验证、发布与运维、项目管理、支持与协作。二级活动族在一级之下细分工作内容，例如“测试验证”下分功能测试、自动化测试、性能测试。三级具体活动是填报时真正选择的条目，应当对应填报人日常能直接判断的工作，例如“编写自动化测试脚本”。层级越深，填报和理解成本越高；三级通常已经足够支撑多数分析，超过三级需要谨慎评估。
维度与层级分开设计
活动类型适合作为分类主线，项目或产品、工作性质（如新增、维护、缺陷修复）、角色等更适合作为附加维度，与活动分类组合使用。把维度硬塞进层级，会导致条目数量成倍膨胀，例如“项目A-新增-编码”“项目B-维护-编码”这类组合不应成为分类条目，而应由“活动类型+关联项目+工作性质”三个字段共同表达。判断标准是：某个信息如果每个填报人都要针对每条记录单独选择，就适合做维度字段；如果它描述的是活动本身的性质，就适合放进分类层级。
分类粒度控制
粒度过细的典型表现是条目数量超过填报人愿意阅读的范围，或者两个条目之间的区别需要反复解释才能判断。粒度过粗则表现为大量工时堆在“其他”或“开发”这类大项里，分析时无法区分投入方向。一个可操作的检验方法是：让两三名典型填报人对同一周的工作试填，如果同一项工作被归入不同条目且各有道理，说明该层级的定义需要收紧；如果多数人频繁选择“其他”，说明分类覆盖不足或粒度过粗。分类结构草图和层级规则应在正式推广前完成一轮试填验证。
分类表怎么编写：字段、编码与判定规则
分类结构确定后，需要把它落成一张可维护、可对照的分类表。分类表的质量直接决定填报一致性，字段缺失或定义含糊，审核环节就会变成反复沟通。
| 字段 | 作用 | 填写要求 |
|---|---|---|
| 编码 | 唯一标识，便于系统录入和数据汇总 | 按层级分段编码，如 03-02-01，编码一经启用不随意变更 |
| 名称 | 填报时显示给用户的条目名 | 用动宾结构或明确的活动名，避免“其他工作”这类无法判断的表述 |
| 定义 | 说明该条目包含什么活动 | 用可观察的动作描述，如“编写或修改单元测试用例”，不用“提升质量”这类抽象词 |
| 典型示例 | 帮助填报人快速对号入座 | 给两到三个日常工作中的具体场景 |
| 排除项 | 划清与相邻条目的边界 | 写明“不包含什么、应归入哪个条目” |
| 归属大类 | 标明所属一级、二级分类 | 与层级结构保持一致 |
| 版本与生效日期 | 支持历史数据追溯和口径对比 | 每次调整生成新版本，旧版本保留并标注停用日期 |
编码与命名规范
编码建议体现层级关系，一级两位、二级两位、三级两位，用分隔符连接，便于排序和汇总。命名保持同一风格：同一层级的条目尽量使用相同的词性结构，例如统一用“动词+对象”，避免有的叫“需求分析”、有的叫“会议”。名称中不出现项目名、人名或时间信息，这些属于维度字段而非分类条目。
定义与边界判定规则
定义写法的核心是把抽象词换成可观察的活动。以“代码评审”为例，定义可以写成“阅读他人提交的代码变更并给出评审意见，包括评审会议中的讨论时间”，典型示例列出“参与合并请求评审”“评审会上讨论实现方案”，排除项写明“自己修改代码不计入本条目，归入编码实现”。对容易混淆的活动，例如“需求澄清会议”与“项目例会”，应在两个条目的排除项中互相指向，形成成对的边界说明。边界规则越具体，审核时的争议越少。
角色分工与交付物：谁设计、谁填报、谁审核
分类体系落地涉及设计、填报、审核和维护四类动作，每类动作需要明确责任角色和交付物，否则容易出现分类表无人维护、审核标准因人而异的情况。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 分类设计责任人（如 PMO 或研发管理接口人） | 确定分类要回答的问题，设计层级与维度，组织试填验证 | 分类结构说明、分类表初版 |
| 财务或核算接口人 | 确认分类与项目核算口径的衔接，参与边界规则评审 | 核算口径对接意见 |
| 填报人（项目成员） | 按周期如实选择活动条目、填写工时数量并关联项目或任务 | 工时填报记录 |
| 审核人（项目经理或团队负责人） | 检查完整性、合理性和跨项目一致性，处理异常并退回 | 审核记录与退回意见 |
| 分类维护责任人 | 受理新增或调整申请，发布新版本并通知填报人 | 变更记录、版本说明 |
设计责任人与维护责任人可以是同一角色，但职责要分开写清楚：设计阶段关注结构是否支撑分析目标，维护阶段关注变更是否破坏历史数据可比性。审核人通常由最了解工作内容的人担任，项目经理审核本项目成员的填报，团队负责人审核跨项目的投入分布。变更流程建议设置为“提出申请—评估影响—发布新版本—通知并培训”，评估影响时重点看变更是否导致历史数据无法与新版口径对比。
填报与审核怎么跑：模板、时点与异常处理
填报环节的输入是分类表和项目任务清单，动作是选择活动条目、填写工时数量、关联项目或任务，输出是一条可追溯的工时记录。填报模板应尽量精简：活动条目用下拉选择而非手工输入，工时数量按小时或人天统一单位，关联项目或任务作为必填项，备注栏只用于说明特殊情况。填报周期建议与团队节奏一致，按周填报比按月填报更容易回忆准确，截止时点应避开项目交付高峰。
审核规则
审核围绕三个维度展开：完整性，检查是否有成员未填报、是否有记录缺少项目关联；合理性，检查单日工时是否超出常规范围、同一活动是否长期集中在“其他”类；跨项目一致性，检查同一类工作在多个项目中是否被归入不同条目。审核人依据分类表中的定义和排除项判断，遇到分类表未覆盖的情况，记录后提交维护责任人处理，不自行新增条目。
常见异常与处理
- 漏填：在截止时点后生成未填报清单，由审核人提醒补填，补填记录标注补填日期。
- 错分类：审核人依据排除项退回并说明应归入的条目，同一成员重复出现同类错误时安排一次简短说明。
- 工时与任务不匹配：例如某任务已关闭但仍有工时登记，退回填报人确认是补记还是关联错误。
- “其他”类占比过高：按月统计“其他”类占比，超过约定阈值时由维护责任人评估是否需要新增条目。
审核结果需要留痕，包括审核通过、退回原因和修改记录，便于后续分析填报质量。当团队使用 ONES 进行工时管理时，工时记录可以与项目和工作项关联，项目经理可查询和导出工时登记日志明细，了解成员工时情况；资源投入可按项目和成员多维度查看，为分类分析提供数据基础。具体字段和配置以实际使用的模块为准。
示例：一个研发团队的工时活动分类落地
以下为一个二十人左右研发团队的示例，用于说明分类表、填报和审核如何衔接，情景为演示用途。
分类表片段
| 编码 | 名称 | 定义 | 排除项 |
|---|---|---|---|
| 02-01-01 | 需求澄清 | 与业务方或产品经理讨论需求范围、验收标准并形成记录 | 不含方案设计，归入 02-02-01 |
| 03-01-01 | 功能编码 | 编写或修改业务功能代码 | 不含修复已上线缺陷，归入 03-02-01 |
| 03-02-01 | 缺陷修复 | 定位并修复测试或线上发现的缺陷 | 不含编写测试用例，归入 04-01-01 |
| 04-01-01 | 测试用例编写 | 设计并编写功能或自动化测试用例 | 不含执行测试，归入 04-02-01 |
一次填报与审核
某开发成员本周在项目 A 投入 30 小时，其中需求澄清 4 小时、功能编码 20 小时、缺陷修复 6 小时，均关联到项目 A 下的对应任务。审核人检查时发现该成员将一次线上问题排查记入“功能编码”，依据排除项退回，要求改记“缺陷修复”。另一名成员有 8 小时记为“其他”，审核人询问后确认是参加技术分享，分类表中无对应条目，记录后提交维护责任人，评估是否在“支持与协作”下新增“技术分享与学习”条目。
这个示例可迁移的规律有三点：排除项要成对指向相邻条目，审核才有明确依据；异常记录要回流到维护环节，分类表才能随实际工作演进；填报条目与项目任务关联后，工时与任务的匹配检查才有数据可查。
完成检查：分类体系是否可用的验收清单
分类体系是否达到可用状态，可以按以下清单逐项核对，每项都应有明确的判断依据。
| 检查项 | 判断标准 |
|---|---|
| 覆盖度 | 抽取近一个月的主要工作，九成以上能归入现有条目；“其他”类占比在约定阈值以内 |
| 无重叠 | 任意两个条目之间，通过定义和排除项能判断归属，试填中未出现系统性争议 |
| 定义清晰度 | 两三名填报人对同一组工作样本独立分类，结果一致率满足团队要求 |
| 填报可行性 | 单次填报耗时在可接受范围内，条目选择不需要反复查阅文档 |
| 审核可执行性 | 每条审核规则都能对应到分类表字段或排除项，退回有具体依据 |
| 维护机制 | 有明确的维护责任人、变更流程和版本记录，历史数据可按版本口径对比 |
清单全部通过后，分类体系可以进入正式运行；运行一个填报周期后建议再复核一次覆盖度和“其他”类占比，根据实际数据做小幅调整。分类体系的稳定比一次设计完美更重要，版本管理和定期校准是让它长期可用的关键。
常见问题
团队规模小、活动种类少，还需要做三级分类吗？
不一定。三级结构的价值在于让填报人能直接对号入座，同时让分析能区分投入方向。如果团队只有十人左右、活动集中在编码和测试两类，两级结构（大类+具体活动）通常已经够用，条目总数控制在十五到二十条以内，填报人不需要反复查阅文档。判断依据是试填结果：如果两级结构下同一项工作被不同人归入不同条目且各有道理，说明需要增加一层细分；如果三级条目里多数长期无人选择，说明层级过深，可以合并。
分类表运行一段时间后，发现某个条目使用频率很高但定义很模糊，应该怎么改？
先收集证据再改。把该条目近一个月的填报记录和备注调出来，看填报人实际记入的是哪几类工作，据此判断是定义写得太宽，还是条目本身混合了多种活动。如果是定义问题，补充典型示例和排除项即可；如果是条目混合了不同性质的工作，需要拆成两个条目，并按变更流程发布新版本，旧版本保留并标注停用日期，保证历史数据仍可按原口径对比。改动前建议让两三名填报人用新定义试填一周，确认判断一致后再正式发布。
审核人发现工时与任务不匹配，应该退回还是直接调整？
退回给填报人确认。工时与任务不匹配常见于两种情况：任务已关闭但仍有补记工时，或者关联到了错误的任务。审核人掌握的信息通常不足以判断属于哪一种，直接调整会覆盖填报人的原始记录，也不利于后续追溯。退回时写明具体记录和不匹配的表现，由填报人确认是补记（保留记录并说明原因）还是关联错误（改挂正确任务）。同类问题在同一成员身上重复出现时，安排一次简短说明比逐条退回更有效。
分类体系上线后，“其他”类占比一直降不下来，怎么处理？
先看“其他”类里实际记了什么。按月导出“其他”类记录的备注，归类统计出现频率最高的几类工作，如果某类工作反复出现且性质明确，说明分类覆盖不足，应由维护责任人评估新增条目；如果备注显示填报人只是图省事，说明条目选择成本偏高或培训不到位，可以精简条目数量、优化下拉排序，把高频条目放在前面。约定一个阈值（例如“其他”类不超过总工时的一成），按月统计并在团队内公布，比一次性整改更能让占比稳定下来。
用工具承载工时填报时，需要关注哪些配置点？
重点看三处：活动条目能否按分类表维护成可选列表，避免手工输入造成口径漂移；工时记录能否关联到项目和工作项，这样工时与任务的匹配检查才有数据可查；审核和查询能否按项目、成员、时间维度导出明细。以 ONES 为例，工时记录可以与项目和工作项关联，项目经理可查询和导出工时登记日志明细，资源投入可按项目和成员多维度查看，为分类分析提供数据基础；具体字段和配置以实际使用的模块为准。
