关注并标星「人人都是产品经理」

每天早07 : 45 按时送达

作者：王撼宇，企业信息化产品经理

题图来自正版图库 图虫创意

全文共 2608 字 1 图，阅读需要 5 分钟

上班打卡是大多数上班狗每天都会做的事情，打卡的方式多种多样，很多厂商也有很完善的解决方案。

这样一个大家每天习以为常的动作，是不是让我们都忽略了一件事——考勤打卡实际上是一个to B类型的产品，并且，其背后逻辑一点也不简单。

一、打卡也要考虑战略层

做产品的其实都知道：在设计一款产品时，我们首先要考虑的是，公司战略是如何定位的？我这款产品在公司战略中处于什么样的位置？我的产品可以给用户带来什么价值？

对于打卡这个看似很简单的产品，其实也要经历以上思考。

首先我们来看公司层面：一个产品经理需要知道公司处在什么阶段，公司内部的文化是怎么样的，然后再决定自己的打卡产品的设计方向。

比如：一个公司处在高速增长阶段，企业内部文化极具包容性，对员工的管制少，那打卡产品可以尝试更多新奇的方向，让大家要不能从打卡找到乐趣，要不就是在打卡/补卡这种操作上少浪费时间。反之，如果一个公司非常强调对员工的管控，那在打卡上也容不得马虎，可能需要对打卡范围和时间严格限制，甚至界面也要走严肃风。

其次，我们要考虑用户需求。打卡这个东西，是制度催生的需求，而不是员工自己的内在需要；所以，对于员工来说，打卡还是越简单越好——比如考勤机排队打卡就没有用手机软件打卡舒服，而用手机软件打卡肯定没有不打卡让人心情愉悦。

做为一个产品经理，还是要在用户需求和公司战略中找到一种平衡，要在公司认可的情况下做到用户体验最好。

——说起来很简单，但做起来非常困难；还容易出现两头都得罪的情况，需要产品经理好好把握。

二、不止打卡页面

考勤打卡实际上应该是一整套系统，打卡只是其中的一个部分，可以看做是系统中的数据录入的页面，只有与其他系统结合，打卡这个页面才是具有意义的。

而这一整套系统的组成，大致有以下几个部分组成：

考勤系统的组成部分

首先是硬件设施，硬件设施的作用是对打卡数据的校验。比如WiFi设备，只有连接上公司WiFi的手机才可以打卡成功，有的公司还有蓝牙设备，只有进入到蓝牙范围内才可以打卡，这里就不一一列举，所有这些都只有一个目的——让员工的打卡数据更加真实。

其次是中台系统，包括管理后台、考勤状态计算系统、薪资系统等。

管理后台提供员工行为的查询、考勤规则配置等功能，是监督员工考勤状态的重要产品。

考勤状态计算系统，名字有点拗口，说白了就是计算员工是否正常上班的系统。

输入的是员工的打卡数据，输出的是员工的考勤状态，如：迟到、旷工等，这个在下一节会详细讲到，里面的计算逻辑很复杂。

还有就是薪资系统，是通过考勤数据来算工资的，在不同公司不一样——有的直接算到考勤系统中，有的是读取考勤系统的数据，有的压根就没有这个系统。

最后就是跟用户接触的前台页面，有必备的打卡页面，提供查询功能的查询页面，还有为弥补忘记打卡而设置的补卡页面，这三样是不可或缺的。

所有的这些（可能有些公司接入系统更多），才是一套完整的考勤系统，是不是比你认知中的要复杂？

三、打卡场景其实很复杂

我的朋友琪总曾经就质疑过我：打卡这么简单的事情，为什么你们老是说算不准呢？

这可能也是很多人的疑问，这个答案其实很简单，就是打卡场景过于复杂。

打卡的情况分为很多种，对于小公司来说，可能很简单，但对于大公司来说，一个产品覆盖所有打卡场景似乎是不可能的。

就考勤的类型来说，大公司的考勤类型可能分为严格考勤、弹性考勤、开放考勤要打卡、开放考勤只打一次卡、开放考勤不打卡、内勤外勤等，而上班时间可能还要分为白班、夜班，更有甚者有一个公司的上班时间可能有五六种。

另外还有一个问题需要考虑的就是——加班。

比如：一个朝九晚五的同学加班到凌晨，那他走的时候打的卡是算第一天的下班卡，还是算第二天的上班卡呢？

那你可能会说：我把下班卡的判定时间设晚一点，设定到凌晨五点前打卡都算是前一天的下班卡。

很好，问题又来了：那如果一个人第一天下班忘打卡，第二天又来得特别早怎么算？

即使上面问题解决了，也还有一个同步时间问题：系统不可能实时去算这些，因为全公司数据都跑一边可能就要半小时甚至更长；在没有更多资源投入到打卡上面时，只能选择分时同步，但是这样会造成信息同步及时的情况，所以这个同步的时间间隔需要设置的很巧妙。

对于这么复杂的场景，现在产品是如何解决的呢？

答案是：无法解决！

打卡产品无法覆盖到每一个场景，只能保证覆盖到尽量多的场景。那些概率极小的场景，就随他去吧，不必做过多纠结。

四、“防御式”产品设计

我们在做开发的时候会提到一个名词——防御式编程。

防御式编程是一种编程习惯，是指预见在什么地方可能会出现问题，然后创建一个环境来测试错误；当预见的问题出现的时候通知你，并执行一个你指定的损害控制动作，如停止程序执行，将用户重指向到一个备份的服务器等。

我们在做考勤产品设计时，也应充分吸收“防御式”思想，对可能出现的问题做预见，并给出相应的对策，在考勤产品设计中，可预见的风险有以下几种：

1）考勤制度突然变动

这种情况虽然不常见，但是我确实是遇到过。

当时是通宵加班，才赶在考勤制度发布前上线，在这以后，我把考勤产品中的所有内容都做成了后台可配置项，甚至连错误提示语都做了可配置；这样在下一次这种情况到来时，五分钟就可以完成所有修改。

2）员工使用不正当方式打卡

这里涉及到员工伪造打卡环境，代打卡等不正当行为。

在产品设计之初，应与开发充分沟通，对此种情况能规避就规避，不能规避就在行为发生时告警；同时，打卡日志也要尽可能多的保留信息。

3）员工没有考勤记录却宣称打卡成功

这个是我经常遇到的情况，明明没有打卡，却非要说自己打了。

对于此类事件，我们需要在将用户的所有操作都记录在日志里，比如我们的产品在用户访问到打卡页面时，不管有没有成功，都会做一次记录，如果没记录，说明连页面都没访问到，明显是来扯皮的。

其实，防御式产品设计是为自己和用户负责，而不是不愿意背锅的无奈之举，这一点需要大家认清楚。

说了这么多，总结一下就是：考勤产品其实比大家想象中的要复杂，而且没有完美的解决方案，只能尽量做到更接近完美。

———————— END ————————

每个「在看」，都是一次鼓励 ▼