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

非技术型产品经理福音来了,和程序员不再撕逼,10天在线学习,补齐产品经理必备技术知识。了解一下

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

一、打卡也要考虑战略层

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

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

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

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

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

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

二、不止打卡页面

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

为什么我会说,“考勤打卡”是一个复杂的产品

考勤系统的组成部分

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

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

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

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

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

三、打卡场景其实很复杂

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

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

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

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

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

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

四、“防御式”产品设计

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

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

1)考勤制度突然变动

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

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

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

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

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

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

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

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

 

本文由 @王撼宇 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
2人打赏
评论
欢迎留言讨论~!
  1. 哈哈 所以之前我一直在想,凌晨12点之后的卡,要算上班卡还是下班卡。很遗憾,并没有这个时候打过。

    回复
  2. 你的好朋友琪总为他的无知向你认错 🙇

    回复
    1. 本尊现身。。。。

      回复
  3. 我也做过,现在被钉钉,云之家他们给干死了···

    回复
    1. 兄弟做得是商业化的产品哈?

      回复
    2. 对,不是自己用的

      回复
    3. 哈哈,被巨头干死,也是英雄

      回复
    4. 其实是管理有问题

      回复
  4. 发现一件事情,打赏最低金额从5毛升到1块后,就再也没人打赏了

    回复
  5. 去年做了个考勤项目,就是因为场景考虑不全,客户很不满意。文章分析的比较全面,也指出了不可能覆盖所有场景,只能从实际使用中不断完善。

    回复
    1. 是的,我也是第一次做考勤项目,踩了很多坑

      回复
  6. 全面而有深度

    回复
    1. 过奖,经验尚浅,还有很多上升空间

      回复
  7. 厉害 👍

    回复
    1. 周老师过奖

      回复
  8. 兄台,不错,正需要这个!

    回复
    1. 哈哈,最近在做打卡么?

      回复
    2. 是的,正在写需求分析!

      回复
    3. 可以多交流交流

      回复
  9. 怎么可以避免忘记打卡呢?

    回复
    1. 1.避免忘记打卡:设置打卡提醒,打卡前以某种表现形式提醒用户打卡;
      2.忘记打卡补救:设置补卡流程

      回复
    2. 楼上说得不错,但是避免忘打卡不太可能,除非做无感知打卡

      回复
    3. 无感知打卡,也就是自动打卡!但是存在可能app未打开,定位未打开等情况!

      回复
  10. 我个人觉得考勤打卡难做有两点:一是用户场景太复杂,考虑到的需求也就更多,比如这个部门可能工作日八点上五点下,周末可能九点上,四点下,而且上下班的打卡地点也有可能变化;或者部门领导不需要和普通员工走同一个考勤等等……考勤场景的复杂也让需求要尽可能完善。第二点,市场大环境不景气,钉钉和企业微信依靠平台和能力占有了90%+的市场,真正想从这里分一杯羹,还是需要一些闪光点。

    回复
    1. 是的,打卡这个其实很复杂的

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

    这里的后半句是第二天的上班卡吧?

    回复
    1. 对的,感谢指正

      回复
  12. 分析很到位,想的很全面

    回复
    1. 到处踩坑啊

      回复