考勤打卡这个产品你一点都不简单

　　上班打卡是大多数上班狗每天都会做的事情，打卡的方式多种多样，很多厂商也有很完善的解决方案。这样一个大家每天习以为常的动作，是不是让我们都忽略了一件事考勤打卡实际上是一个toB类型的产品，并且，其背后逻辑一点也不简单。
　　一、打卡也要考虑战略层
　　做产品的其实都知道，在设计一款产品时，我们首先要考虑的是，公司战略是如何定位的？我这款产品在公司战略中处于什么样的位置？我的产品可以给用户带来什么价值？
　　对于打卡这个看似很简单的产品，其实也要经历以上思考。
　　首先我们来看公司层面，一个产品经理需要知道公司处在什么阶段，公司内部的文化是怎么样的，然后再决定自己的打卡产品的设计方向。
　　比如：一个公司处在高速增长阶段，企业内部文化极具包容性，对员工的管制少，那打卡产品可以尝试更多新奇的方向，让大家要不能从打卡找到乐趣，要不就是在打卡补卡这种操作上少浪费时间。反之，如果一个公司非常强调对员工的管控，那在打卡上也容不得马虎，可能需要对打卡范围和时间严格限制，甚至界面也要走严肃风。
　　其次我们要考虑用户需求，打卡这个东西，是制度催生的需求，而不是员工自己的内在需要。所以，对于员工来说，打卡还是越简单越好。比如考勤机排队打卡就没有用手机软件打卡舒服，而用手机软件打卡肯定没有不打卡让人心情愉悦。
　　做为一个产品经理，还是要在用户需求和公司战略中找到一种平衡，要在公司认可的情况下做到用户体验最好，说起来很简单，但做起来非常困难，还容易出现两头都得罪的情况，需要产品经理好好把握。
　　二、不止打卡页面
　　考勤打卡实际上应该是一整套系统，打卡只是其中的一个部分，可以看做是系统中的数据录入的页面，只有与其他系统结合，打卡这个页面才是具有意义的。而这一整套系统的组成，大致有以下几个部分组成。
　　考勤系统的组成部分
　　首先是硬件设施，硬件设施的作用是对打卡数据的校验。比如WiFi设备，只有连接上公司WiFi的手机才可以打卡成功，有的公司还有蓝牙设备，只有进入到蓝牙范围内才可以打卡，这里就不一一列举，所有这些都只有一个目的让员工的打卡数据更加真实。
　　其次是中台系统，包括管理后台、考勤状态计算系统、薪资系统等。管理后台提供员工行为的查询、考勤规则配置等功能，是监督员工考勤状态的重要产品。考勤状态计算系统，名字有点拗口，说白了就是计算员工是否正常上班的系统，输入的是员工的打卡数据，输出的是员工的考勤状态，如：迟到、旷工等，这个在下一节会详细讲到，里面的计算逻辑很复杂。
　　还有就是薪资系统，是通过考勤数据来算工资的，在不同公司不一样，有的直接算到考勤系统中，有的是读取考勤系统的数据，有的压根就没有这个系统。
　　最后就是跟用户接触的前台页面，有必备的打卡页面，提供查询功能的查询页面，还有为弥补忘记打卡而设置的补卡页面，这三样是不可或缺的。
　　所有的这些（可能有些公司接入系统更多），才是一套完整的考勤系统，是不是比你认知中的要复杂？
　　三、打卡场景其实很复杂
　　我的朋友琪总曾经就质疑过我：打卡这么简单的事情，为什么你们老是说算不准呢？这可能也是很多人的疑问，这个答案其实很简单，就是打卡场景过于复杂。
　　打卡的情况分为很多种，对于小公司来说，可能很简单，但对于大公司来说，一个产品覆盖所有打卡场景似乎是不可能的。就考勤的类型来说，大公司的考勤类型可能分为严格考勤、弹性考勤、开放考勤要打卡、开放考勤只打一次卡、开放考勤不打卡、内勤外勤等，而上班时间可能还要分为白班、夜班，更有甚者有一个公司的上班时间可能有五六种。
　　另外还有一个问题需要考虑的就是加班。比如：一个朝九晚五的同学加班到凌晨，那他走的时候打的卡是算第一天的下班卡，还是算第二天的下班卡呢？
　　那你可能会说，我把下班卡的判定时间设晚一点，设定到凌晨五点前打卡都算是前一天的下班卡。很好，问题又来了，那如果一个人第一天下班忘打卡，第二天又来得特别早怎么算？
　　即使上面问题解决了，也还有一个同步时间问题，我系统不可能实时去算这些，因为全公司数据都跑一边可能就要半小时甚至更长，在没有更多资源投入到打卡上面时，只能选择分时同步，但是这样会造成信息同步及时的情况，所以这个同步的时间间隔需要设置的很巧妙。
　　对于这么复杂的场景，现在产品是如何解决的呢？答案是无法解决，打卡产品无法覆盖到每一个场景，只能保证覆盖到尽量多的场景。那些概率极小的场景，就随他去吧，不必做过多纠结。
　　四、防御式产品设计
　　我们在做开发的时候会提到一个名词防御式编程，防御式编程是一种编程习惯，是指预见在什么地方可能会出现问题，然后创建一个环境来测试错误，当预见的问题出现的时候通知你，并执行一个你指定的损害控制动作，如停止程序执行，将用户重指向到一个备份的服务器等。
　　我们在做考勤产品设计时，也应充分吸收防御式思想，对可能出现的问题做预见，并给出相应的对策，在考勤产品设计中，可预见的风险有以下几种：
　　1）考勤制度突然变动
　　这种情况虽然不常见，但是我确实是遇到过，当时是通宵加班，才赶在考勤制度发布前上线。在这以后，我把考勤产品中的所有内容都做成了后台可配置项，甚至连错误提示语都做了可配置，这样在下一次这种情况到来时，五分钟就可以完成所有修改。
　　2）员工使用不正当方式打卡
　　这里涉及到员工伪造打卡环境，代打卡等不正当行为，在产品设计之初，应与开发充分沟通，对此种情况能规避就规避，不能规避就在行为发生时告警，同时，打卡日志也要尽可能多的保留信息。
　　3）员工没有考勤记录却宣称打卡成功
　　这个是我经常遇到的情况，明明没有打卡，却非要说自己打了。对于此类事件，我们需要在将用户的所有操作都记录在日志里，比如我们的产品在用户访问到打卡页面时，不管有没有成功，都会做一次记录，如果没记录，说明连页面都没访问到，明显是来扯皮的。
　　其实，防御式产品设计是为自己和用户负责，而不是不愿意背锅的无奈之举，这一点需要大家认清楚。
　　说了这么多，总结一下，就是考勤产品其实比大家想象中的要复杂，而且没有完美的解决方案，只能尽量做到更接近完美。
　　大家有什么问题或者想法或者质疑，欢迎评论区留言。