域名频道资讯站
我们一直在努力制造惊吓

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


上班打卡是大多数上班狗每天都会做的事情,打卡的方式多种多样,很多厂商也有很完善的解决方案。这样一个大家每天习以为常的动作,是不是让我们都忽略了一件事——考勤打卡实际上是一个to B类型的产品,并且,其背后逻辑一点也不简单。

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

一、打卡也要考虑战略层

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

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

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

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

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

做为一个产品经理,还是要在用户需求和公司战略中找到一种平衡,要在公司认可的情况下做到用户体验最好,说起来很简单,但做起来非常困难,还容易出现两头都得罪的情况,需要产品经理好好把握。

二、不止打卡页面

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

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

考勤系统的组成部分

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

其次是中台系统,包括管理后台、考勤状态计算系统、薪资系统等。管理后台提供员工行为的查询、考勤规则配置等功能,是监督员工考勤状态的重要产品。考勤状态计算系统,名字有点拗口,说白了就是计算员工是否正常上班的系统,输入的是员工的打卡数据,输出的是员工的考勤状态,如:迟到、旷工等,这个在下一节会详细讲到,里面的计算逻辑很复杂。

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

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

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

三、打卡场景其实很复杂

我的朋友琪总曾经就质疑过我:打卡这么简单的事情,为什么你们老是说算不准呢?这可能也是很多人的疑问,这个答案其实很简单,就是打卡场景过于复杂。

打卡的情况分为很多种,对于小公司来说,可能很简单,但对于大公司来说,一个产品覆盖所有打卡场景似乎是不可能的。就考勤的类型来说,大公司的考勤类型可能分为严格考勤、弹性考勤、开放考勤要打卡、开放考勤只打一次卡、开放考勤不打卡、内勤外勤等,而上班时间可能还要分为白班、夜班,更有甚者有一个公司的上班时间可能有五六种。

另外还有一个问题需要考虑的就是——加班。比如:一个朝九晚五的同学加班到凌晨,那他走的时候打的卡是算第一天的下班卡,还是算第二天的下班卡呢?

那你可能会说,我把下班卡的判定时间设晚一点,设定到凌晨五点前打卡都算是前一天的下班卡。很好,问题又来了,那如果一个人第一天下班忘打卡,第二天又来得特别早怎么算?

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

对于这么复杂的场景,现在产品是如何解决的呢?答案是无法解决,打卡产品无法覆盖到每一个场景,只能保证覆盖到尽量多的场景。那些概率极小的场景,就随他去吧,不必做过多纠结。

四、“防御式”产品设计

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

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

1)考勤制度突然变动

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

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

这里涉及到员工伪造打卡环境,代打卡等不正当行为,在产品设计之初,应与开发充分沟通,对此种情况能规避就规避,不能规避就在行为发生时告警,同时,打卡日志也要尽可能多的保留信息。

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

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

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

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

大家有什么问题或者想法或者质疑,欢迎评论区留言。

 

本文素材来自互联网

赞(0)
分享到: 更多 (0)

中国专业的网站域名及网站空间提供商

买域名买空间