很多公司在钉钉里待久了都会冒出同一个问题：人都在钉钉打卡、审批、聊项目，那工时是不是也该在钉钉里自然算出来？
听上去顺理成章，做起来是另一回事。钉钉打卡知道某人今天几点上下班、加了几小时班，但不知道这一天他给哪个项目干了多少活；审批能让员工填「工时申请」，但导出的 Excel 拉不出像样的横向对比；项目群里聊得火热，工时却躺在每个人脑子里。
真正想用工时数据做事的公司——算项目成本、定外包结算、看团队负载、按客户算毛利——都绕不开同一个动作：在钉钉之外再加一层。这层东西是什么，差别就大了，便宜的几乎不花钱，贵的要投十几万元做二开。
一、为什么钉钉自带的工时统计「不够用」
先把话说清楚：钉钉不是不能算工时，而是它算的是「考勤工时」，不是「项目工时」。这两个经常被混在一起讲，完全不是一回事。
考勤工时回答：员工今天在岗多久、加了几小时班、有没有迟到早退。这部分钉钉做得很扎实，HR 算工资完全够用。
项目工时回答的是另一组问题：A 项目这个月烧了多少人天、张三本周花了多少时间在客户 B 上、这个交付包的实际人力成本是多少、外包工时按哪个口径结算。这些钉钉自带的考勤模块没法回答，因为它根本不知道「项目」这个维度。
管理者第一次想拉项目工时，会去翻钉钉审批的工时申请，发现每张单子是独立的，没法按项目聚合、没法跨月对比、没法和云效或 ERP 的项目编号对上。问题不是钉钉做得不好，而是要先分清自己要的是哪种工时。要 HR 算工资的口径，钉钉够用；要项目经理算成本、老板看人均产出、财务和客户对账的口径，下面四套方案才是真正要选的。
二、方案 A：纯钉钉审批 + 表单导出（0 元方案的天花板）
最朴素的做法，是在钉钉里建一个「项目工时填报」自定义审批：员工每天或每周提交一张单子，字段是日期、项目、工作内容、投入小时数；流转给项目经理审批通过，数据沉淀在钉钉审批后台。
优势就一个字：零。零额外许可、零开发、零运维，员工已经习惯在钉钉点同意，培训成本可以忽略。
天花板卡在三个地方。一是数据导出是 Excel，按项目、按人、按月做交叉分析得自己写公式；二是「项目名称」是手输文本，今天「客户 A 二期」明天「A 客户二期项目」，分析时要花大力气清洗；三是审批通过≠数据准确，自报告没有任何系统校验，导出表里一周填 60 小时、某项目一个月突然冒出 200 工时的，全靠人工肉眼抓。
谁适合？团队 30 人以内、项目数量两位数以内、对工时只有「大概知道谁在忙什么」这种粒度需求的公司。再大一点，边际成本会突然飙起来——不是钉钉的钱，是 HR 和项目经理每月清洗 Excel 的时间。
三、方案 B：氚云/简道云工时表单（500-2000 元/年量级）
下一档是低代码搭工时模块。氚云和简道云本质都是「在钉钉里嵌一个能自己设计表单和报表的轻量数据库」。
工时这个场景对低代码来说是教科书级别的甜区。建一张工时表单，字段做成下拉（项目从主表关联、人员从钉钉通讯录同步、客户从客户主表关联），员工不再是手输文本——这一步解决了方案 A 最大的脏数据问题。再配一张仪表盘按项目、按人、按月做透视，Excel 导出不再是分析起点，而是给老板和财务看的最终产物。
费用上，50 人左右的团队纯工时模块一年几千元量级；顺便把项目立项、合同、客户也搬上去做成轻量 PMS，一年大概在万元上下。
边界有两个。一是数据规模，低代码报表引擎在几万行以内跑得飞快，到几十万行（三五年累积的工时明细）开始卡，复杂透视会超时；二是和外部系统的双向打通，往钉钉推消息很顺，但要让工时自动同步进 ERP 做成本核算、按客户合同算分成，往往半接不接最难受。
某连锁餐饮总部就是这个画像：几十人的总部团队加几百号门店督导，工时主要算总部职能的项目投入和督导的巡店时长。上一个低代码表单+仪表盘，几千块一年，省下来的是 HR 主管每月底加班对工时的那两个晚上。
四、方案 C：钉钉 OpenAPI + 自研工时中台
再往上一层，就是基于钉钉 OpenAPI 自己搭一套工时中台。核心是把钉钉当成「人和组织的数据源 + 用户入口」，工时业务逻辑放在自研系统里：通讯录通过 OpenAPI 同步过来；填报做成钉钉里的 H5 应用，员工点开就用；数据落到自己数据库，按项目、客户、合同、成本中心做多维建模；催报通过钉钉机器人推回去。
为什么有公司愿意花十几万元做这件事？因为到了某个规模，工时不再是「记录」，而是经营数据。要按项目实际人时反算客户毛利、要和差旅/采购成本合并出项目利润表、要给外包做月结对账、要按工时驱动绩效奖金、要实时同步给 ERP 项目模块——这些场景都涉及和其他系统的深度耦合，对数据准确性有硬要求。
开沿自己就在这么用工时。内部跑双轨：研发在云效里关任务，工时跟着任务自动沉淀；交付和定制开发在自研的 azeroth 项目工时里按客户编号、合同号填报，月底直接出客户毛利表和员工产能表。两套数据每周对一次，差异超过阈值自动报到企业群里。作为一家定制开发公司，我们必须知道每一个客户、每一个合同到底烧了多少人，否则报价和续费完全靠拍脑袋。[^1]
成本上，方案 C 常见区间是十几万元一次性开发 + 每年一两万元服务器和维护。前提是公司里有人愿意长期运营——组织变了、项目类型变了、计费规则变了，它都得跟着改。没有持续运营，三个月后填的人变少、数据准确率掉下来，再贵的中台也是摆设。
五、方案 D：接入云效/PingCode 项目工时
最后一类是不在钉钉侧做工时，而是直接用专业项目管理工具自带的工时模块——阿里云效、PingCode、Worktile、Teambition、Jira 都属于这一档。
逻辑很不一样：不是「员工去填一张工时单」，而是「员工把任务做了，工时自然就有了」。任务关联人员、关联工时预算、关联实际投入，工时是任务管理的副产品。
这套方案在研发型团队里特别突出。工程师每天的工作本来就是开任务、推进度、关任务，多花十秒记一下投入，比每周末专门花半小时填工时单省得多。费用按用户数收，云效国内版有免费额度，PingCode 和 Worktile 大致每月每人几十到上百块，50 人团队一年几千到一两万元都有可能。
短板也明显。对非研发同学不友好——销售、行政、市场这些岗位的日常不是「关任务」的形态，硬塞进去最后大概率退化成方案 A。所以更现实的做法，是把方案 D 限定在研发、产品、设计这类「天然按任务工作」的团队里，其他职能用 A 或 B 兜底。
六、四套方案真实成本表
| 方案 | 一次性投入 | 年度许可 | 二开/集成 | 长期维护 | 适合规模 |
|---|---|---|---|---|---|
| A：钉钉审批 + 导出 | 0 | 0 | 0 | HR 每月几小时清洗 | 30 人以下 |
| B：氚云/简道云 | 1-2 人周搭建 | 几千到万元量级 | 基础接口够用 | 半人月/年 | 30-150 人 |
| C：OpenAPI + 自研中台 | 几万到十几万元 | 服务器一两万元/年 | 视集成深度 | 建议有专岗 | 100 人以上、工时即成本 |
| D：云效/PingCode | 0-1 人周接入 | 几千到两万元量级 | 视报表需求 | 工具自有团队 | 研发型团队优先 |
几个容易被忽略的隐性成本：A 的「免费」是用 HR 和项目经理的时间换的，团队大了之后折算会反超 B 的许可费；C 的开发费看着吓人，分摊到三五年月均也就几千块，关键是有没有人长期维护；D 的许可费看着便宜，一旦给非研发部门开账号，单价乘以人数会让账单跳一档。
七、4 套方案选型决策
三个问题问下来基本就能定。
第一，工时数据的下游是谁在用？只是 HR 看个大概、老板偶尔关心，方案 A 够。项目经理每周复盘、财务月底算成本、销售给客户出对账单，至少要走 B。工时要进 ERP、进经营分析、要驱动绩效和客户毛利核算，基本就是 C。
第二，团队是研发型还是混合型？纯研发主导，方案 D 几乎是天选。混合型团队（研发+交付+销售+职能）就老老实实承认分层：研发走 D、交付和项目走 B 或 C、职能岗用 A 兜底，不要追求大一统。[^2]
第三，公司有没有人愿意长期养这套系统？这是方案 C 唯一的硬门槛。十几万元的开发费不可怕，可怕的是上线半年没人维护，新业务全部塞进「其他项目」这个垃圾桶。如果公司里找不到一个愿意把工时中台当作分内事的人，宁可不上 C，先用 B 顶住。
工时这件事最大的误区，是把它当成工具问题。工具只是承载，真正决定数据值不值钱的，是公司有没有想清楚「我们到底要拿工时干嘛」。想清楚了，方案 A 也能跑出洞察；没想清楚，方案 C 也只是一个更贵的填报系统。开沿在帮客户落地工时方案时，第一件事不是问要用哪个工具，而是问一句：你打算拿这份数据做哪个决策？把这个问题答清楚，四套方案的选择会自己浮出来。
[^1]: 开沿内部目前在跑「云效 + azeroth 自研项目工时」双轨：研发在云效里关任务自然出工时，交付和定制开发在 azeroth 里按客户和合同填报，每周对账。这套做法不是一开始就有的，是踩了几次「让所有人填同一张表」的坑之后才妥协出来的分层方案。
[^2]: 某 80 人左右的项目交付型公司，最初想一刀切上自研工时中台，跑了三个月发现销售和行政的填报率不到三成，最后回退到「交付和研发走自研、销售和职能走简道云」的混合架构，整体填报率回到九成以上。承认不同工种工作形态不一样，比强行统一省心得多。
