工时活动分类的目标，是让团队每天填写的工时能按统一口径归集、比较和审核。做法可以拆成五步：梳理工作对象、设计两级分类、写填报规则、定审核与例外、试运行校准，最终产出分类字典、填报说明和审核清单。本文聚焦投入记录本身，工时成本计量、考勤与工资计算不在讨论范围。
要点总览（TL;DR）
- 工时活动分类先梳理真实工作动作，再设计五到八个一级类目、二十到四十个二级活动项，让填报人能当场判断、审核人能对应到产出。
- 颗粒度以“能当场判断”和“能对应可核对产出”两条标准取舍，命名用动宾结构，部门名和项目名交给关联字段表达。
- 填报规则要写清必填字段、最小时间单位和单条记录上限，跨类工作按产出能否分开核对来拆分，例外优先用现有活动项加备注表达。
- 分类维护人、填报人、审核人和例外裁决人落实到具体人员，审核清单聚焦活动项与关联对象是否匹配、时长是否合规、拆分是否有说明。
- 试运行两到四周，用未归类比例、备注补充率、审核退回率和活动项使用集中度校准字典，四项完成检查齐备后再定版推行。
先定分类口径：工时活动分类要解决什么问题
分类要回答三个问题：成员的时间花在哪些类型的工作上、不同项目或团队的投入能否横向比较、填报记录能否被审核人快速判断真假与合理性。如果活动项名称含糊、颗粒度忽粗忽细，工时数据就只能用于“填了没有”的检查，无法支撑投入分析和资源判断。因此，分类设计从一开始就要围绕“可归集、可比较、可审核”这三个标准取舍。
五步推进的顺序有先后依赖：先有真实工作清单，才谈得上设计层级；先定结构，才能写填报规则；规则明确后，审核才有依据；最后用试运行数据检验前面四步是否成立。每一步的输入、动作和输出如下表。
| 步骤 | 输入 | 核心动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 梳理工作对象 | 角色分工、项目清单、近三个月工作记录 | 按角色和业务环节列出实际工作动作，合并同义项 | 活动项候选清单 | 候选清单覆盖主要角色，无重复表述 |
| 2. 设计两级分类 | 候选清单 | 一级按工作性质归类，二级按具体动作拆分，统一命名 | 两级分类结构 | 每个活动项能当场判断、能对应产出 |
| 3. 写填报规则 | 分类结构、现有填报习惯 | 确定必填字段、填报粒度、拆分方式和例外归类 | 填报规则说明 | 填报人按说明可独立完成一条记录 |
| 4. 定审核与例外 | 填报规则、组织汇报关系 | 明确维护人、填报人、审核人职责与升级路径 | 角色职责表、审核清单 | 每个活动项有维护人，每条记录有审核归属 |
| 5. 试运行校准 | 分类字典、规则、角色安排 | 小范围试填，观察误用和空缺，调整分类 | 试运行结论、定版字典 | 字典定版、规则发布、角色到人 |
需要说明边界：本文讨论的是“成员投入了什么工作”的记录口径。工时如何折算成本、如何与考勤和工资挂钩，属于另外的管理流程，分类设计时不必把这些口径混进活动项名称里，否则填报人会因为不理解成本规则而随意选择。
第一步：梳理工作对象，形成活动项候选清单
候选清单要从真实发生的工作中来，而不是几个人在会议室凭印象列。可行的做法是按角色分别收集：开发、测试、设计、项目管理、运维支持等角色，各自列出一天中实际执行的动作，再按业务环节（需求、设计、开发、测试、发布、线上支持）归并。收集时让成员描述“昨天做了什么、产出是什么”，比直接问“你觉得应该分几类”更容易得到具体动作。
收集过程中要有意识地区分两类工作。项目型工作有明确的项目或需求归属，例如“接口开发”“用例编写”；日常支撑型工作通常没有单一项目归属，例如“环境维护”“答疑支持”“团队例会”。两类工作都需要进入分类，但关联字段的填写要求不同，项目型工作应关联项目或任务，支撑型工作可关联到部门或支撑事项。
候选清单整理时按以下规则处理：
- 合并同义动作：把“写代码”“编码”“开发实现”合并为一个活动项，保留团队最常用的说法。
- 剔除低频偶发动作：半年发生一次的活动不单列，归入相近的“其他支撑”类，避免字典膨胀。
- 保留有管理意义的动作：即使发生频率不高，但如果需要单独观察投入（如线上故障处理），应保留为独立活动项。
- 避免把部门名当活动名：“产品部工作”“测试组事务”无法判断具体动作，应拆成实际动作。
候选清单建议包含四个字段：活动名称、典型场景（一句话说明什么情况下选它）、发生角色、预计占比。预计占比不需要精确，用于判断哪些活动项是高频主项、哪些是低频补充项，为下一步控制颗粒度提供依据。
第二步：设计两级分类结构，控制颗粒度
两级结构是多数团队够用的层级：一级类目按工作性质划分，回答“这类工作属于什么”；二级活动项按具体动作划分，回答“具体做了什么”。一级类目数量控制在五到八个，二级活动项总数控制在二十到四十个之间。超过这个范围，填报人开始犹豫选哪个，审核人也难以记住规则。
颗粒度的判断标准有两条，两条都满足才适合作为独立活动项：填报人看到名称能当场判断是否属于自己刚做的工作；该活动项能对应到可核对的产出或对象，例如代码提交、测试用例、需求文档、故障单。只满足第一条不满足第二条，说明活动项偏虚；只满足第二条不满足第一条，说明名称过于专业或内部化。
命名遵循动宾结构，例如“编写测试用例”“处理线上故障”“评审需求文档”，比“测试工作”“故障”“评审”更明确。同一含义只保留一种说法，避免“开发”和“编码”并存。部门名、项目名、系统名不进入活动项名称，这些信息应通过关联字段表达。
| 常见问题 | 表现 | 调整方法 |
|---|---|---|
| 颗粒度过粗 | “项目工作”一个项装下所有事，无法分析投入结构 | 按业务环节拆成需求、设计、开发、测试等动作 |
| 颗粒度过细 | 把“写接口文档”“写设计文档”“写测试报告”拆成三项，填报时反复纠结 | 合并为“编写技术文档”，用备注区分文档类型 |
| 层级混用 | 一级类目里既有“开发”又有“需求评审” | 统一一级为工作性质，具体动作下沉到二级 |
| 同义并存 | “联调”和“接口对接”同时存在 | 保留一个，另一个停用并在说明中注明对应关系 |
两级结构确定后，形成分类字典初稿。字典中每个活动项应写明所属一级类目、适用角色、典型场景和启用状态，停用的活动项保留记录但不允许新填，便于历史数据仍可解释。
第三步：写填报规则，明确字段、粒度与例外
分类结构只解决“有哪些选项”，填报规则解决“怎么填”。规则要写到填报人不需要再问人的程度，核心是字段、粒度和例外三部分。
必填字段建议包括：日期、活动项、关联项目或任务、投入时长、备注。日期和活动项是归集的基础；关联项目或任务让投入能落到具体对象上；投入时长决定数据能否用于分析；备注用于解释拆分依据或特殊情况。对于日常支撑型工作，关联字段可填写部门或支撑事项，不强制关联项目。
填报粒度需要团队统一。按天填报适合工作内容每天变化不大的团队，按周填报适合以周为节奏安排工作的团队，但无论哪种，都要规定最小时间单位和单条记录上限。例如最小单位为0.5小时，单条记录不超过8小时，超过则要求拆分。粒度规则一旦发布，审核就按同一口径检查，避免有人按天填、有人按任务填导致数据不可比。
跨类工作的拆分依据是“产出是否可分开核对”。一次上午的会议如果同时讨论需求和排期，可以按实际讨论时长拆成两条记录；如果无法区分，按主要目的归入一类并在备注说明。拆分不追求精确到分钟，追求的是归集方向正确。
| 情形 | 归类建议 | 填写要求 |
|---|---|---|
| 临时支援其他项目 | 按实际动作选择活动项，关联被支援项目 | 备注写明支援原因和发起人 |
| 会议 | 归入“会议与沟通”类，或按会议主题归入对应工作类 | 团队需事先统一一种口径 |
| 培训与学习 | 归入“学习与培训”类 | 注明培训主题，不关联具体项目 |
| 等待与阻塞 | 归入“等待与协调”类，或按实际协调动作归类 | 备注写明阻塞原因和等待对象 |
| 返工 | 按返工的实际动作归类，不单设“返工”项 | 备注说明返工原因，便于后续分析 |
例外归类的原则是：不为每种特殊情况新增活动项，优先用现有活动项加备注表达。只有当某类例外频繁出现且需要单独统计时，才考虑在下一版字典中新增。
第四步：定角色分工与审核机制
分类能否长期用下去，取决于有没有人维护、有没有人审核。角色分工要落到具体的人，而不是落到部门。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 分类维护人 | 维护分类字典版本，审批新增、合并、停用活动项的申请 | 字典版本记录、变更说明 |
| 填报人 | 按规则填写工时记录，对活动项选择和拆分负责 | 完整的工时记录 |
| 审核人 | 核对活动项与关联对象是否匹配，处理异常记录 | 审核结论、退回意见 |
| 例外裁决人 | 处理规则未覆盖的归类争议，决定是否临时新增活动项 | 裁决记录，必要时转为字典变更申请 |
审核清单应聚焦可核对的检查项：活动项与关联项目是否匹配，例如测试类活动关联到测试任务而非需求文档；投入时长是否在粒度规则允许范围内；跨类拆分是否有备注说明；同一人同一天是否存在明显重复或遗漏。通过标准是以上检查项全部满足，任一项不满足则退回修改并注明原因。
例外裁决与升级路径要事先约定：填报人遇到无法归类的记录，先按最接近的活动项填写并在备注说明，审核人判断是否属于规则缺口；属于规则缺口的，提交分类维护人评估，必要时由例外裁决人决定临时处理方式。升级路径不宜过长，一般两级足够，避免填报人因为等待答复而拖延填报。
在工具承载上，分类字典、工时记录和审核流转需要放在同一套工作项体系里，才能让活动项选择、关联对象和审核意见互相对应。ONES 的资源和工时管理支持查询和导出工时登记日志明细，也支持按项目和团队查看资源投入情况，适合把填报记录与项目对象关联起来做核对；分类字典的具体维护方式需结合团队实际配置确定。
第五步：试运行与校准，用数据检验分类是否可用
分类设计完成后不要直接全量推行，先选一个范围试运行。范围可以是一个项目组或一个部门，周期建议两到四周，覆盖至少一个完整的工作节奏（含一次发布或一次迭代）。试运行期间保持规则稳定，只记录问题，不频繁改字典，否则无法判断问题来自分类设计还是规则变化。
观察指标用于判断分类是否可用：
- 未归类记录比例：选择“其他”或备注说明无法归类的记录占比，偏高说明分类有缺口。
- 备注补充率：需要靠备注才能解释清楚的记录占比，偏高说明活动项名称或拆分规则不清晰。
- 审核退回率：被退回修改的记录占比，偏高说明填报规则与审核标准不一致。
- 活动项使用集中度：少数活动项占据大部分记录，说明颗粒度可能过粗；大量活动项几乎无人使用，说明存在冗余项。
根据数据做两类校准：冷门项合并或停用，把长期无人选择的活动项并入相近类目；高频混杂项拆分，把集中度过高、备注中频繁出现不同工作内容的活动项拆成两个更具体的动作。校准后更新字典版本并同步填报说明。
完成检查项包括：分类字典定版并记录版本号；填报规则说明发布到所有填报人；维护人、审核人、裁决人落实到具体人员；试运行结论写明调整了哪些项、依据是什么。四项齐备，分类体系才算落地。
示例：一个研发团队的分类字典与一次填报审核
以下为演示情景，用于说明分类字典和填报审核的走查过程，不代表真实团队数据。
某研发团队有开发、测试、产品三个角色，试运行后定版的两级分类字典片段如下：
| 一级类目 | 二级活动项 | 适用角色 | 典型场景 |
|---|---|---|---|
| 需求与设计 | 评审需求文档 | 产品、开发、测试 | 参加需求评审会并给出意见 |
| 需求与设计 | 编写设计文档 | 开发 | 输出接口设计或方案说明 |
| 开发实现 | 编写代码 | 开发 | 按任务完成功能开发 |
| 开发实现 | 联调与自测 | 开发 | 与上下游接口对接、本地验证 |
| 测试验证 | 编写测试用例 | 测试 | 根据需求编写用例 |
| 测试验证 | 执行测试与缺陷跟踪 | 测试 | 执行用例、提交并跟踪缺陷 |
| 日常支撑 | 会议与沟通 | 全部 | 例会、跨团队沟通 |
| 日常支撑 | 环境与工具维护 | 开发、测试 | 维护测试环境、处理工具问题 |
一条跨类记录的填写过程：开发人员上午参加需求评审会一小时，随后编写接口设计文档两小时，下午编写代码四小时并完成一次联调一小时。按规则拆成四条记录：评审需求文档1小时，关联需求单；编写设计文档2小时，关联需求单；编写代码4小时，关联开发任务；联调与自测1小时，关联开发任务。每条记录的活动项与关联对象一一对应，备注中注明联调对象。
审核人核对时发现“联调与自测”关联的是需求单而非开发任务，与规则中“开发实现类活动应关联开发任务”不符，退回并要求修改关联对象。填报人修改后重新提交，审核通过。另有一条记录填写“会议与沟通”3小时但未写备注，审核人要求补充会议主题和参与方，确认属于跨团队沟通后通过。
从这个示例可以迁移的规律是：拆分依据是产出能否分开核对，关联对象要与活动项性质匹配，备注用于解释无法从字段直接看出的信息。适用边界在于，该字典针对的是有明确项目和任务归属的研发工作；如果团队以长期运维或职能支撑为主，一级类目和活动项需要按实际工作重新梳理，不能直接套用。
常见问题
团队规模小、工作类型单一，还需要做两级分类吗？
可以简化，但建议保留一级类目加少量二级活动项的结构。小团队的工作动作数量有限，一级类目可能三到四个就够，二级活动项控制在十个左右。保留层级的价值在于后续团队扩张或项目类型增加时，新活动项有位置可放，不必推倒重来。如果团队确实只有一种工作类型，也可以先只做一级类目，在试运行中观察是否出现需要区分的细分动作，再决定是否增加二级。
成员反映活动项太多、填报时选不出来，应该怎么调整？
先看数据再动手。统计各活动项的实际使用情况，把长期无人选择或极少使用的项合并到相近类目，把集中度过高、备注里频繁出现不同工作内容的项拆开。同时检查名称是否用了内部术语或部门名，这类名称会让填报人无法判断。调整后同步更新填报说明，并在团队内说明变更原因，避免成员按旧习惯继续选择已停用的活动项。
跨部门支援或临时插入的工作，应该归到哪个活动项？
按实际执行的动作选择活动项，关联字段填写被支援的项目或事项，备注写明支援原因和发起人。不建议为临时支援单设活动项，否则字典会随组织变化不断膨胀。如果某类支援持续发生且需要单独统计投入，可以在下一版字典中评估是否新增，评估依据是试运行期间的记录量和统计需求，而不是个别成员的主观感受。
审核人应该重点看什么，怎样避免审核流于形式？
审核聚焦可核对的检查项：活动项与关联对象是否匹配，例如开发实现类活动应关联开发任务而非需求单；投入时长是否在粒度规则允许范围内；跨类拆分是否有备注说明；同一人同一天是否存在明显重复或遗漏。审核意见要写明退回原因和修改要求，便于填报人理解规则。如果退回率持续偏高，应回头检查填报说明是否清楚，而不是单纯加大审核力度。
分类字典定版后，多久需要复审一次？
建议在试运行结束定版后，按季度或按项目阶段复审一次。复审时看三类信号：新增业务出现无法归类的记录、某些活动项使用集中度明显变化、审核退回集中在少数几个活动项。出现这些信号说明字典需要调整。日常新增或停用活动项由分类维护人按申请审批，保留版本记录，历史数据仍可按旧版本解释。
