工时活动分类是什么：项目、任务与活动类型的维度层级界定

工时活动分类是工时填报体系里对“这段时间投入到哪里”的结构化标签，通常由项目、任务、活动类型三个维度组成：项目界定投入归属的业务单元，任务界定项目内的具体工作项，活动类型界定投入的性质。层级界定的核心，是让填报人用较少的选择准确表达投入对象，同时让审核人能够逐层核对归属与合理性。ONES 可作为工时填报与审核的管理承载方向之一。

要点总览（TL;DR）

• 工时活动分类是工时记录上的结构化维度，用项目、任务、活动类型说明每段工时投到哪里、属于什么性质的工作。
• 项目界定投入归属的业务单元，任务界定项目内的具体工作项，活动类型界定投入性质，三者是不同维度而非同一维度的层级。
• 典型层级为项目→任务→活动类型，活动类型作为横向标签挂在任务上；层级深度以审核人能判断归属合理性、填报人能快速完成为准。
• 兼顾填报与审核的关键是选项可枚举、活动类型清单受控、同一段工时只落在一个项目和一个任务上。
• 分类只解决投入归属与性质表达，工时成本计量归研发人力成本核算，考勤与工资计算不在其范围内。

工时活动分类的直接定义

工时活动分类是对“投入对象”和“投入性质”的结构化标签集合。它回答两个问题：这段时间投到哪里，投的是什么性质的工作。前者由项目、任务承担，后者由活动类型承担。填报人提交一条工时记录时，除了填写日期、时长和填报人，还要从分类体系中选择对应的项目、任务和活动类型，让这条记录具备可归类、可汇总、可核对的含义。

分类与工时记录的关系需要分清：工时记录是载体，包含时长、日期、填报人等事实信息；分类是记录上的维度，是对这条记录含义的标注。一条记录可以只有时长没有分类，但这样的数据只能统计“投入了多少时间”，无法回答“投入到哪里、做了什么性质的工作”。分类的价值在于把时长与业务对象连接起来，使工时数据能够按项目汇总、按任务追溯、按活动类型分析投入结构。

用一句话复述：工时活动分类是工时记录上的结构化维度，用项目、任务、活动类型等标签说明每段工时投到哪里、属于什么性质的工作，从而让工时数据具备归属和性质两层含义。

分类的边界：哪些内容属于工时活动分类

明确边界有助于避免把分类体系设计成包罗万象的表格。工时活动分类的范围集中在“投入归属与性质表达”，它不承担核算口径，也不处理考勤与工资。

范围	内容	说明
属于	项目	投入归属的业务单元，决定工时归到哪个项目
属于	任务	项目内的具体工作项，决定工时归到哪件事
属于	活动类型	投入性质，如开发、测试、评审、沟通、支持
属于	必要的子活动或工作项标签	在任务之下进一步细分工作内容时使用
不属于	考勤与工资计算	归考勤与薪酬管理，分类不处理出勤与薪资规则
不属于	工时成本单价与费用核算	归研发人力成本核算，分类不承担单价、费率与费用口径

这条边界的实际意义是：分类体系只需要保证“每段工时能准确落到一个项目、一个任务、一个活动类型上”，不需要在分类字段里塞入成本中心、费率、审批状态等核算或流程信息。核算所需的单价、费率由成本核算体系另行维护，分类提供的是可被核算引用的归属维度。把两类信息混在同一张分类表里，会让填报选项膨胀，也会让核算口径随分类调整而频繁变动。

项目、任务、活动类型三个维度分别界定什么

三个维度各自回答不同问题，混用会导致分类体系失效。项目回答“归到哪个业务单元”，任务回答“归到哪件具体工作”，活动类型回答“以什么性质投入”。它们是不同维度，而非同一维度下的不同层级。

维度	界定内容	回答的问题	典型取值
项目	投入归属的业务单元	这段时间归到哪个项目	某产品迭代项目、某客户交付项目
任务	项目内的具体工作项	这段时间做的是哪件事	登录模块开发、接口联调、需求评审会
活动类型	投入的性质	以什么性质投入	开发、测试、评审、沟通、支持

项目维度的职责是确定归属。同一段时间只能归属一个项目，跨项目投入需要拆成多条记录。任务维度的职责是确定具体工作项，它通常来自项目计划中的任务分解，填报人从已有任务中选择，减少自由描述。活动类型维度的职责是标注性质，它独立于任务存在：同一个任务下可能既有开发性质的投入，也有评审和沟通性质的投入，活动类型让这些投入在统计时可以分开看。

把活动类型当成任务的下一级，是常见的混用。任务表达“做什么”，活动类型表达“以什么性质做”，两者是正交关系。一个“登录模块开发”任务下，可以出现开发、评审、沟通三种活动类型的工时，这并不矛盾，反而正是分类体系要表达的信息。

层级怎么搭：从项目到任务到活动类型的组合规则

典型层级是项目→任务→活动类型。项目在最上层确定归属，任务在中间层确定工作项，活动类型作为横向标签挂在任务上，标注这段工时的性质。这种结构既保证归属唯一，又保留性质区分。

层级深度需要按管理颗粒度取舍。层级过深，填报人每填一条工时都要逐级选择，负担增加，容易出现随意选择或集中补填；层级过浅，审核人无法判断工时归属是否合理，统计也只能停留在项目总量。一个可操作的判断标准是：审核人能否凭现有层级判断“这段工时该不该出现在这个项目、这个任务上”。如果判断不了，说明层级不足；如果填报人需要为一条普通工时做五次以上选择，说明层级过细。

组合规则有三条需要守住：

• 同一段工时只落在一个项目和一个任务上，跨项目或跨任务投入拆成多条记录，保证归属不重叠。
• 活动类型清单保持受控，由管理员统一维护，填报人从清单中选择，减少自由填写带来的口径漂移。
• 任务与活动类型的关系保持正交，任务来自项目计划，活动类型来自统一清单，两者组合使用，不互相替代。

在工具承载上，这套层级需要工时记录能挂接到具体工作项，并能按项目、成员等维度汇总。ONES 资源和工时管理解决方案支持统计项目工时、多维度掌握项目和成员的资源投入情况，并支持查询和导出工时登记日志明细，可作为分类数据落地后的统计与核对方向；活动类型字段的具体配置方式需在选型时确认。

同时满足填报与审核的界定原则

分类体系有两个使用方：填报人和审核人。设计时两侧都要照顾，只优化一侧通常会让另一侧失效。

填报侧的原则是减少选择成本：

• 选项可枚举。项目、任务从已有数据中选择，活动类型从受控清单中选择，避免开放输入。
• 默认值合理。根据填报人所在项目或近期记录给出默认项目，减少重复选择。
• 选择步骤少。常用组合尽量在少量步骤内完成，层级深度控制在填报人能快速判断的范围内。

审核侧的原则是保证可核对：

• 能按项目、任务、活动类型逐层查看，先看项目总量是否合理，再看任务分布是否匹配计划，最后看活动类型结构是否符合预期。
• 分类口径稳定。同一类工作在不同人手里应落到相同维度，口径频繁变动会让历史数据无法比较。
• 活动类型清单受控。自由填写会让“沟通”“沟通协调”“会议沟通”并存，统计时无法合并。

两侧原则存在张力：填报侧希望选项少，审核侧希望信息全。可行的平衡是把区分度放在活动类型上，把归属精度放在项目和任务上，子活动等更细的标签只在确有分析需求时启用。审核环节若需要提交、审批、驳回等流程，也应在选型时一并确认工具支持情况。

相邻概念区别：工时活动分类与工时记录、成本核算、考勤的区别

几个概念经常被混为一谈，区分清楚才能把分类体系放在正确位置。

概念	核心内容	与工时活动分类的关系
工时活动分类	项目、任务、活动类型等结构化标签	本体，解决投入归属与性质表达
工时记录	时长、日期、填报人等事实信息	分类是记录上的维度，记录是分类的载体
工时成本核算	单价、费率、费用计量	分类提供归属维度供核算引用，不承担单价与费用口径
考勤与工资计算	出勤、请假、薪资规则	不在本文范围，分类不处理出勤与薪资

与工时记录的区别最直接：记录回答“花了多少时间”，分类回答“时间花在哪里、什么性质”。一条记录缺少分类仍然存在，但无法参与按项目或活动类型的分析。与成本核算的区别在于，分类只提供可被引用的归属维度，单价和费用由核算体系维护，分类调整不应牵动费率。与考勤工资的区别在于适用对象不同，考勤处理出勤事实与薪资规则，工时分类处理投入结构，两者数据可以互相参考，但口径各自独立。

具体例子与常见误解

以下为演示情景：某工程师一天内投入某产品迭代项目，上午完成登录模块开发，下午参加需求评审会，其间与测试同事沟通接口问题。按分类体系填报，可拆成三条记录：项目均为该产品迭代项目；任务分别为“登录模块开发”和“需求评审会”，沟通部分可挂在“接口联调”任务下；活动类型分别为开发、评审、沟通。审核人查看时，先看该项目当日工时总量，再看任务分布是否与计划一致，最后看活动类型结构是否以开发为主、评审和沟通占比合理。三条记录各自归属唯一，性质清晰，统计时既能按项目汇总，也能按活动类型分析投入结构。

常见误解有三条：

• 把活动类型当成任务层级。活动类型是性质标签，任务才是工作项，两者正交，不应把“开发”“测试”写成任务名称。
• 把项目当成唯一维度。只有项目没有任务和活动类型，工时只能汇总到项目总量，无法区分项目内投入结构和性质分布，审核也缺少判断依据。
• 层级越细越好。过度细分会让填报人每条约工时做大量选择，导致随意勾选、集中补填，数据质量反而下降。层级深度应以审核人能判断归属合理性、填报人能快速完成为准。

把这三点守住，工时活动分类就能在填报效率和审核有效性之间取得平衡，并为后续按项目、任务、活动类型的统计分析提供稳定的数据基础。

常见问题

活动类型和任务到底是什么关系，能不能把“开发”“测试”直接写成任务名称？

两者是正交关系，不宜互相替代。任务表达“做什么”，来自项目计划中的工作分解，例如“登录模块开发”；活动类型表达“以什么性质投入”，来自统一维护的受控清单，例如开发、测试、评审、沟通。同一个任务下可以同时出现开发、评审、沟通三种活动类型的工时，这正是分类体系要保留的信息。把“开发”“测试”写成任务名称，会让任务列表失去工作项含义，统计时也无法区分同一任务内的性质分布。

团队规模不大、项目也不复杂，层级是不是可以只保留项目一层？

可以简化，但要先确认审核是否还判断得了。只保留项目维度时，工时只能汇总到项目总量，审核人看到的是“这个项目花了多少时间”，无法判断时间是否落在计划内的工作项上，也难以发现投入性质是否偏离预期。如果团队确实只需要项目级投入总量、且审核环节不核对任务分布，简化是合理的；一旦需要按任务追溯或分析开发、测试、沟通的投入结构，就应至少补上任务与活动类型两层。层级深度按管理颗粒度取舍，没有统一标准。

活动类型清单由谁维护，填报人遇到清单里没有的工作性质怎么办？

活动类型清单宜由管理员统一维护，填报人从清单中选择，这是控制口径漂移的常见做法。清单之外出现新工作性质时，处理方式有两种：一是由管理员评估后增补清单项，保持全局一致；二是允许在受控范围内补充说明，但不新增统计口径。需要避免的是每位填报人自行输入活动类型，否则“沟通”“沟通协调”“会议沟通”会并存，汇总时无法合并。清单增补的频率和审批方式应在制度中写明，避免清单随项目临时变化而频繁调整。

工时分类数据能不能直接用来算人力成本？

分类提供的是归属维度，成本计量需要另行维护单价与费率。工时活动分类回答“时间投到哪个项目、哪件事、什么性质”，研发人力成本核算则在此基础上引用归属数据，结合人员单价、费率等口径计算费用。两者衔接的方式是分类数据可被核算体系引用，分类本身不承担单价与费用口径。这样处理的好处是分类调整不会牵动费率，核算口径也不会因分类细化而频繁变动。考勤与工资计算属于另一套口径，不在工时分类的处理范围内。

跨项目投入的工时怎么填，会不会出现同一段工时归属两个项目？

跨项目投入应拆成多条记录，每条记录归属唯一。例如某工程师上午在两个项目间切换，就按实际投入分别填写两条工时，各自选择对应项目和任务，而不是在一条记录里挂两个项目。这样处理保证归属不重叠，按项目汇总时不会重复计算。拆分粒度以能准确表达投入为准，不必细到每次切换都单独记录，但同一时间段只能落在一个项目和一个任务上，这是组合规则中需要守住的一条。