企业官网建设流程全解析

工时管理系统大概是企业软件里最不起眼、又最容易翻车的一类PRD。我刚接手这套系统时，公司已经换了三版Excel模板，财务和项目负责人每个季度末都要花整整三天对工时表，研发团队却总觉得这是在搞监控。后来我才想明白，工时管理系统真正的本质不是“记录谁几点上班”，而是把“人-任务-时间”这三个维度变成一个可以被汇总、比较、审计的可信数据源，让成本核算和资源调度不再靠拍脑袋。这篇内容是一份完整复盘后的PRD拆解，覆盖产品边界、角色流程、功能模块、数据模型、边界场景和验收方案，适合正在规划或重构工时系统的产品经理、项目负责人参考。

1. 工时管理系统的立项动机与产品边界

1.1 工时数据的本质：不止是“记录时间”

先讲一个我经历过的真实场景。公司做的是项目制交付，对外按人天报价。季度末财务要对项目毛利率，项目经理说A项目投入了120人天，但财务从考勤记录里一算，实际打卡时长折合下来是135人天，中间差了15人天。双方拿着各自的Excel谁也不服谁——项目经理解释说有人加班、有人干到凌晨但第二天调休，考勤机只能记录“人在公司”，根本记录不了“时间为哪个项目花了”。

这就是工时系统要解决的第一层问题：考勤记录的是“人在场”，工时记录的是“时间投向了哪里”。一个研发白天开会三小时、写代码五小时，考勤上都是八小时，但工时系统需要把这八小时拆到项目、任务和具体事项上。换句话说，工时数据是企业经营分析的最小颗粒度——它是项目成本核算的基础、人员利用率计算的输入、甚至对外结算开票的依据。

我见过很多团队一提到工时系统，第一反应就是“做个日历让员工每天填几行字”。这完全低估了这件事。工时系统的本质是一条流水线：采集端要尽量降低填报成本，审批端要保证数据可信，统计端要把明细数据变成经营决策可用的汇总指标。三个环节缺任何一个，系统都会沦为摆设。

1.2 产品边界：工时不是考勤、排期，也不是绩效考核

这是我踩过最大的坑，也是PRD里必须最先划清的一条线。需求评审会上，HR说“最好能跟门禁打卡联动”，项目经理说“能不能顺便做一下迭代排期”，研发负责人说“要不把每个员工每小时的产出也量化一下”。如果这些需求全部收进来，这个PRD就不用写了——它会被撑成一个OA+项目管理+绩效系统的综合体。

我在PRD里用一张边界对比表把这件事写死了：

所以PRD里的范围说明我写得非常直接：本系统不做考勤打卡、不做任务创建与排期、不做自动绩效评分。它只做一件事——把“任务”上发生的时间投入，以可控的方式采集上来，再以多维度的方式分发出去。任务从哪儿来？从项目管理系统同步过来。时间怎么发出去？发给BI、发给财务系统、发给项目周报。边界划清楚了，后面每个需求都能很快判断做还是不做。

1.3 一份PRD的读者和写作策略

工时系统的PRD很特别，它的读者几乎覆盖公司全员。普通员工关心的是一天填多少次、操作麻不麻烦；项目经理关心的是能不能看到团队负载和成本；财务关心的是数据能不能导出成可入账的结构；研发关心的是能不能对接现有系统；老板关心的是数据能不能反映出真实利用率。

写这份PRD的时候我的策略是：先讲清楚产品要解决什么（也就是上面的边界问题），再讲清楚每个人怎么用（角色与流程），然后把功能一条条落到位（模块拆解），最后把数据长什么样、系统稳不稳、上线后怎么验收也一并定下来。这样一份PRD发出去，各角色都能找到自己关心的那部分，而不是像说明书一样从头看到尾。

2. 用户角色与端到端业务流程的完整串联

2.1 五类角色和各自的真实诉求

工时系统最容易被忽略的地方，是不同角色对“工时”二字的理解完全不一样。我在PRD里专门定义了一个“角色诉求表”，这直接决定了权限设计和功能优先级。

普通员工的核心诉求是快。他们已经被各种系统填表填得烦透了，如果填一次工时需要两分钟以上，很快就会有人开始应付了事。所以产品设计上要给到周视图批量填报、上周复制、快捷模板这些能力。

项目经理的核心诉求是看得清。他需要知道哪些人负载过高、哪些人长时间空闲、某个项目是否超预算。注意，项目经理要的不是“你做了多少小时”这个原始数据，而是“我的项目成本消耗了多少、还剩多少预算”这样的经营指标。

部门负责人更关心负荷均衡和人力规划。他需要跨项目看到团队的总体利用率，判断要不要招人、要不要调整资源分配。

财务的角色极其关键。对外结算时，工时明细要能对应到合同里的计费项；对内核算时，要能把工时成本归集到项目，算出真实毛利率。财务对数据可信度的要求是审计级的——不能有逻辑矛盾，不能有重复记录，修改必须留痕。

系统管理员则是被很多PRD忽略的角色。审批规则调整、项目归档、人员异动、历史数据修正，这些都需要一个可配置的后台，而不是每个需求都走开发排期。

2.2 端到端主流程：从任务同步到成本入账

我把完整业务流程分为六个环节，每个环节的输入输出和关键校验都做了定义：

1. 任务同步：项目管理系统（或OA系统）把项目和任务主数据同步到工时系统。PRD里要求至少每15分钟增量同步一次，包含项目编号、名称、负责人、状态、任务层级、任务所属项目。这里有个细节：必须同步一个“是否计费”的标记，财务结算时直接按这个标记区分计费工时和非计费工时。

2. 工时填报：员工在周视图上选择日期和任务，填入时长和工作摘要。系统做基本校验：日期不能晚于今天加一天（允许补录上周但禁止填写未来一周以上）、时长必须是大于0且不超过24小时的数字、任务必须属于当前项目且该项目未被归档。

3. 提交与审批：员工可以按周批量提交，也可以逐日提交。PRD里规定默认按周提交、允许配置按天提交。提交后进入审批流，项目经理或授权审批人逐条核对。这里需要支持整周通过、整周驳回、单条驳回三种操作。

4. 异常处理：驳回后员工可以修改并重新提交，系统保留所有版本记录。审批通过后的数据默认锁定，如需修改必须走“修正申请”流程，由管理员在留痕状态下操作。这个流程设计是为了保证财务结算时数据不再变动。

5. 统计归集：系统按项目、部门、人员、月份四个维度做预汇总。PRD里特别要求生成三类核心报表：项目工时成本报表（项目×人员×月份×工时×标准成本率）、人员利用率报表（人员×月份×有效工时/标准工时）、部门投入结构报表（部门×月份×项目类型×工时占比）。

6. 数据分发：通过接口或数据同步任务，把经过审批且锁定后的工时明细推送到财务系统和BI系统。推送必须是增量的，且每条记录都要带一个全局唯一的记录ID，方便财务对账时做幂等处理——这是避免两边数据对不上的关键设计。

3. 核心功能模块的逐项拆解与取舍理由

3.1 填报交互：低门槛设计的核心原则

填报是整套系统里日活最高的功能，它的交互质量直接决定数据质量。我见过最好的设计不是功能最丰富的，而是让员工“每天花不到一分钟就搞定”的。

具体拆解下来有几个关键交互：

周视图默认展开，周一至周日横向排列，左侧是任务列表，交叉处是时长输入框。员工可以一次性看到整周情况，而不是一天一天切。这个设计基于一个行为判断：人的记忆对“上周三干了什么”比对“今天干了什么”更模糊，所以需要整周上下文辅助回忆。

支持“复制上周”是一个成本极低的实用功能。很多工作内容是周期性重复的，比如每周例会和定期维护。复制过来后允许逐项修改，实测下来能省掉40%左右的填写量。

对不同的项目类型做智能预填。比如某员工本周80%时间在A项目，系统在未填写区域自动推荐A项目作为默认选项，员工确认就行了。但这有个前提：预填必须可以一键清除，避免引导出错误数据。

还有一个必须考虑的交互是“摘要备注”。PRD里我把它设计为选填但鼓励填写，长度限制在200字内。原因是纯数字工时很难审计，有备注才方便项目经理在审批时判断合理性。为了降低填写负担，提供几个常用标签比如说“开发”“联调”“会议”“文档”“排查问题”，员工点一下就行，不用打字。

3.2 规则配置引擎：不要让规则写死在代码里

工时系统的规则会随着公司管理阶段不断变化。我见过一个反面案例：某公司把“超过8小时的部分按加班填写”写死在代码里，后来公司改制不再区分正常和加班，开发团队花了三周才把逻辑改掉，期间所有报表口径都是错的。

所以PRD里专门设计了一个规则配置引擎，把常见的校验和计算规则都做成可配置项。这个引擎至少需要支持以下几类规则：

审批规则支持按条件路由。比如“单周工时超过40小时的记录自动转给部门负责人复核”“涉及外部项目的工时必须由财务复核”“普通员工由项目经理审批，项目经理的工时由部门负责人审批”。每个条件都对应一个可下拉选择的操作。

填报时限规则建议做成分级提醒。比如工作日当天20:00提醒一次，周五17:00对未填报员工发出应用内通知，周一10:00对上周未提交的记录自动抄送直属上级。这些都是运营侧最需要的“柔性压迫”，比硬性截止更能平衡体验和数据完整性。

统计口径规则化管理很关键。哪些工时算入“有效工时”？跨项目切换是否算？培训、团建、内部技术分享怎么归类？这些在不同公司答案完全不同。因此PRD里要求做一个“工时类型”字典，默认包含开发、测试、会议、文档、运维、培训、其他七类，管理员可以增删改，每个类型还能设置是否计入项目成本。

规则引擎的配置界面要遵循“先选场景，后选动作”的设计，避免管理员面对一堆规则无从下手。同时每条规则要记录生效时间和变更历史，防止规则调整后历史数据统计口径对不上。

3.3 审批流与异常处理：状态机设计是灵魂

审批流是工时系统数据可信度的第一道防线。我在PRD里用状态机来定义工时记录的生命周期，而不是简单用一个is_approved布尔值。状态包括：草稿、待提交、审批中、已通过、已驳回、已撤销、修正中。每个状态下能执行的操作完全不同，例如“撤销”只能发生在审批中之前，已通过的数据不能直接编辑，只能发起修正。

审批页面要为项目经理提供聚合视图，不是一条条看，而是看“本周项目整体填报情况”——哪些人还没填、哪些记录时长明显异常（比如一天超过12小时、连续7天都有加班记录）、哪些备注为空且时长超过4小时。这些都能靠服务端规则自动打标，审批人只需要处理那些被标记为“异常”的记录。

驳回时要求选择原因类型，包括工时与实际不符、任务归属错误、时长超限、备注不足、其他。原因类型会同步给填报人，减少来回沟通成本。如果一单被连续驳回两次，系统自动通知项目负责人介入，避免员工和审批人之间来回踢皮球。

修正流程要单独设计。已通过并锁定后的数据如果发现错误，允许发起“修正申请”，流程与普通审批一致，但修正记录会永久保留，包括原值、新值、修改人、修改时间、审批人。财务结算时看到的永远是“当前值+历史修正链”，这样审计时不必猜。

3.4 统计看板：从明细到决策指标的转化

统计模块是工时系统价值的最终出口。设计上必须区分“明细查询”和“指标看板”两个层面。明细查询是导出Excel供财务和项目经理核对；指标看板面向管理层，展示的是加工后的聚合指标。

指标看板我建议分成四块。第一块是项目健康度，展示每个项目的计划工时、实际工时、剩余预算工时、偏差率。偏差率超过20%自动标红。第二块是团队利用率矩阵，行是人员，列是项目，格子里的颜色深浅代表投入比例，一眼就能看出某个人是否同时被五个项目拉扯。第三块是部门负载趋势，用近12个月的月趋势判断团队是长期过载还是阶段性紧张。第四块是成本归集结果，按标准成本率将工时折算成金额，与项目收入对比得出毛利预估。

这里有一个很重要的设计原则：看板上的数字必须能一键溯源到明细。管理层看到“项目A偏差率35%”时，会立刻点击看明细，如果点不到就会觉得系统不可信。所以每个聚合数字后面都要挂一个下钻入口，逐级追踪到项目、任务、人员、工时记录。

导出功能也别做太粗糙。PRD里要求提供三种导出模板：财务对账模板（按项目、月份、计费类型汇总）、项目管理模板（按人、按周汇总）、运营审计模板（保留字段的历史变更链）。模板要通过配置文件维护，不能写死在代码里，因为财务的格式要求经常变。

3.5 第三方系统对接：同步和推送的取舍

工时系统一定是企业软件生态里的一个节点，它需要从项目管理系统拿任务数据，向财务系统输出成本数据，向BI系统输出明细数据。PRD里对对接的时序和保障机制做了明确要求。

任务同步采用拉取模式，每15分钟轮询一次项目系统的增量接口。增量判断依赖对方的updated_at字段和全量快照对比，防止漏更新。如果项目系统不可用，工时系统不阻塞填报——员工仍然可以手工选择历史任务或输入任务名称，等同步恢复后再做任务匹配。这个降级方案很实用，避免因上游系统故障导致全员无法填报。

数据分发采用推送模式，审批锁定后的数据每5分钟增量推送一次，推送接口要求对方支持幂等，靠记录ID去重。这里踩过一个坑：如果推送失败不能无限重试，要设置重试上限（默认5次），超过后转人工处理，避免消息积压导致队头阻塞。

还有一个容易忽略的对接点：组织架构和人员异动。员工换部门、转岗、离职，都会影响历史工时数据的归属。PRD要求组织架构按“生效日期版本化”，查询任何一天的历史工时都能还原当天的部门归属，而不是用当前部门去看三个月前的数据。

3.6 权限模型：RBAC加数据范围双维度

工时数据的敏感性不容忽视，薪资都未必能看出一个人的投入方向，但工时能。权限模型我采用RBAC和数据范围两个维度叠加。

角色层面分为系统管理员、财务专员、部门管理员、项目审批人、普通员工五类。每个角色的权限在PRD里用矩阵表定义清楚。

数据范围维度很关键：项目经理只能看自己负责的项目；部门负责人只能看本部门人员的数据；财务能看到全部数据但不能修改；系统管理员拥有全部权限，但所有操作都要进审计日志。跨部门查看必须单独申请权限，审批通过后设置有效期，避免权限长期悬挂的风险。

员工只能看到自己的记录，但在“项目成员视图”下可以看到同项目成员填写的工时分布（不含备注和明细），这样有助于协作时双方确认工作安排，同时防止敏感信息过度暴露。

4. 数据模型与关键字段设计：把时间变成可计算的数据

4.1 工时记录表：每个字段为什么必须存在

工时记录表是整个系统的核心实体。我在PRD里设计了一张字段表，每个字段都经过实际业务验证，这里列出来供参考：

有几个字段我需要专门解释一下为什么这么设计。首先，duration_minutes用整数分钟而不是小数小时，这是一个非常实用但少有人注意的决策。小数小时在四舍五入、累计汇总时会产生精度误差，而且财务对账时“0.1小时”到底算6分钟还是5分钟会引发纠纷。整数分钟在存储、求和、比较时都不会有语义歧义，显示端再做分钟到小时的转换完全来得及。

其次，source_channel这个字段看起来不起眼，但它对运营非常有价值。如果某个渠道的填报占比持续走低，说明交互设计出了问题；如果API导入占比异常高，说明某个部门在绕过界面批量上传数据，需要排查是否合规。渠道数据也是后续优化填报体验的直接证据。

第三，version字段是解决并发冲突的关键。在实际场景里，员工可能同时打开两个浏览器标签页，或者移动端和Web端同时操作，如果没有乐观锁，最后一次写入会覆盖前面的数据。每次提交时带上version，如果和数据库里的不一致就提示“记录已被其他终端修改，请刷新后重试”，这个机制能挡掉大多数数据覆盖问题。

summary这个字段虽然选填，但我在PRD里特意加了一个建议：超过4小时的单条记录，系统会在前端给出“建议补充备注”的提示。它不是硬校验，但能从数据质量角度引导用户留下可审计的依据。实测发现，有了这个提示后，备注填写率从35%提升到了70%以上。

4.2 汇总表与索引：查询性能的保障

工时系统的数据量不会小——500人的公司，一年下来工时明细记录大概在18万到20万条左右。如果每次报表都实时扫描明细表聚合，查询会越来越慢，所以必须做预聚合。

PRD里设计了月度汇总表，粒度为“用户×项目×月份×工时类型”，存储预计算的总分钟数、记录条数、可计费分钟数。每天凌晨由定时任务重算昨天的增量，并回填到汇总表。报表页面优先查汇总表，只有点击溯源时才去查明细表。

索引设计上，明细表需要三个核心复合索引：第一个是(user_id, work_date)用于个人历史查询和校验“一人一天多条记录”；第二个是(project_id, work_date)用于项目维度汇总；第三个是(approval_status, submit_at)用于待审批列表的拉取。每条数据都不大，加上合理索引，百万级别以内的数据量查询性能完全不是问题。

4.3 填报人的行为数据也是产品数据

这里分享一个比较特别的设计视角：工时系统里不仅要有员工填写的工时数据，还应该有员工“如何填写工时”的行为数据。这个数据帮助产品团队了解填报流程哪里卡住了。

我在PRD中定义了一套埋点事件：填报页面停留时长、从打开页面到完成提交的步数、复制上周功能的使用次数、修订单条记录的前后差额、放弃离开页面时是否有未保存内容。这些数据不直接展示给管理层，而是给产品运营团队看。

一个实际场景是：某月中旬发现填单页面的平均完成时间从50秒突然涨到120秒，埋点数据显示是因为一个下拉框的数据量过大、浏览器渲染卡顿导致的。没有行为埋点，这个体验问题会一直存在下去。所以工时系统不能只做“业务数据”，也要把操作过程当成数据资产来看待。

5. 非功能需求、边界场景与容错设计

5.1 性能指标和可用性目标

工时系统的并发压力属于典型的“平日低、峰值高”。绝大多数时间同时在线填报的人可能只有几十个，但周一早上十点或月末最后三天，可能几百人同时集中填报和审批。PRD里我定了一套清晰但不过分的指标：

写接口（提交、审批、修改）的P95响应时间需要小于800毫秒，P99小于1.5秒。这个目标不需要复杂的分布式架构，把数据库连接池配好、避免写接口里做重查询就完全能达标。读接口分为两类：明细查询的P95小于1秒，聚合报表的P95小于5秒。聚合报表主要通过汇总表和缓存解决，避免每次实时扫描明细。

可用性按月计算需要达到99.9%，换算下来每月不可用时间不超过43分钟。工时系统虽然不是在线交易系统，但月末结算的那一天如果挂了，财务流程会被卡住半天，所以在月结前一天会做一次只读模式的切换演练，确保万一系统抖动也不会影响数据读取。

这里要强调的是，工时数据一旦提交并审批通过，它就会进入财务流程，所以对数据的可用性要求从“员工体验层面”提升到了“财务合规层面”。PRD里要求数据库开启自动备份，每日全量备份保留30天，增量备份保留90天。同时要求核心表开启审计日志的独立表，和业务表分开存储，防止某一天生产环境数据被误操作后审计证据跟着丢。

5.2 十大边界场景的处理策略

我把在日常使用中会遇到的异常场景整理成清单，并在PRD里逐一敲定了处理策略：

这里我在实际项目里感受最深的是“补录时限”。一开始设计的很宽松，允许补录任意历史日期，结果出现了有人一次性补录三个月的工时，数据可信度直接被拉穿。后来改成“本月15日前可补录上月，更早要审批”，这个弹性加限制的组合既给了员工修正空间，又挡住了批量回溯式的乱填。

5.3 容错设计与幂等保障

容错主要体现在几个层面。首先是前端降级：当项目系统不可用时，前端要允许员工手工选择任务名称并将项目ID置空，待同步恢复后由后台做匹配尝试。匹配成功的记录会自动标记“已关联”，匹配不上的记录仍保留在“未匹配任务”的列表中，由管理员每月集中清理一次。

其次是推送的幂等设计。发给财务系统的每条数据都要带一个sourceId，它就是工时记录表的ID。财务系统需要按sourceId去重，重复推送的数据不会导致成本重复计算。这个设计在我对接金蝶和SAP时都验证过非常关键，否则一旦网络抖动触发重试，财务就要花大量时间去人工清重复数据。

第三是导入功能的批量容错。系统要允许管理员通过Excel模板批量导入工时记录，但导入过程是“逐行校验、批量中兼容局部失败”：1000行里如果某一行格式不对，不能整个文件回滚，而是跳过那行并把错误原因生成一个报告文件，让管理员改了再传。一次性全盘回滚的导入体验对管理员来说就是噩梦。

6. 埋点方案与验收标准：上线之前先想清楚怎么量

6.1 三类必须埋的数据

工时系统上线后，除了业务数据，还要有能真实反映系统健康度的三种数据。第一种是漏斗类数据：从打开填报页到完成提交的转化率。如果填报页打开很多但提交很少，大概率是交互卡住或者按钮找不到；如果提交了但审批被大量驳回，那是规则设置或填报指引的问题。

第二种是时效类数据：审批流的平均处理时长。我见过最夸张的情况，有人提交了两周还没被审批，员工等到数据过期后彻底放弃填写。所以PRD里要求在审批超时(默认72小时)时自动给审批人发送提醒，并且把审批时长作为项目的月度运营指标之一，让管理者知道审批环节有没有变成瓶颈。

第三种是质量类数据：未填报率、驳回率、修正率。未填报率反映的是提醒策略是否有效；驳回率反映的是填报指导和规则配置是否清晰；修正率反映的是审批流的严谨度。这三个率放在一起，基本能判断一套工时系统有没有在公司里真正跑起来。理想状态下，上线三个月后周未填报率应低于5%，驳回率低于10%，修正率低于2%。

6.2 功能验收标准：不能只凭“感觉做完了”

PRD的验收标准要具体到可执行、可验证。比如“填报功能”，我会写成：员工可在周视图上为每个项目填写任意时长的工时，系统即时计算当日累计时长并在超过12小时时给出拦截提示；修改已提交的记录需要撤销或驳回后才能操作；提交后的数据出现在审批人的待办列表中且状态正确。

再比如“规则配置”，验收标准是：管理员创建一条“单周超过40小时自动转部门负责人审批”的规则后，提交一条41小时的周记录，系统能自动将审批流分发给部门负责人，且原始审批人看到的状态为“已转审”，后台审计日志中记录规则触发的完整链路。

统计看板的验收标准是：更新当月工时后5分钟内，项目看板和部门看板的聚合数字同步刷新；点击任意聚合数字可以逐级追溯至原始明细；导出的财务模板字段与协议约定一致且金额计算准确。

这些验收标准都要求QA人员在测试环境里用真实数据跑一遍，而不是单纯用Mock数据验证界面能跳转。工时系统的核心逻辑是数值的流转和状态的演进，验收重点永远是数据链条的完整性和一致性，不能用“界面长这样就行”来糊弄。

6.3 上线后的运营节奏

最后说一点PRD之外、但实际执行中特别重要的东西：工时系统上线绝对不要追求一步到位。

我踩过最痛的坑是一上线就把所有校验规则开到最严，结果员工提交的每单都被弹窗拦截，一天之内就有十几个部门投诉“系统没法用”。后来我改用“先宽后严”的策略：第一个月只保留基础校验（时长非零、必须关联项目），第二个月开启超时提醒，第三个月才启用“超过40小时自动转审”这种管理强度较高的规则。每一步都做好运营铺陈，让团队逐步适应规则的存在，而不是第一天就迎面一棒。

另外，上线前一定要选两三个配合度高的项目组做种子用户。种子用户能提供真实的数据反馈和操作反馈，还能在全员推广时充当内部的“使用教练”。我见过很多系统死在全员推的第一天——大家只会机械地点“提交”，根本不懂怎么填才规范。种子用户在这个过程中能起到很大的缓冲作用。

工时管理系统真正难的地方，从来不是功能开发，而是让每一个填写的员工都觉得这事情合理、有用、不烦人，让审批的人觉得数据可信、流程透明。能做到这两点，系统才能成为公司经营管理的可信底座，而不是又一个躺着吃灰的内部系统。