从考勤管理需求说起,聊聊场景的思维“工具”

从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线学习,做个有竞争力的运营人。了解详情

你是否有过做问题分析时,毫无头绪,生怕会遗漏什么?是否在逐条列出方案后,依然会有人提出些没想到的问题?看一下作者是如何解决的。

上个月,我们在做项目的考勤管理和入职流程需求沟通时,前后讨论了不下10次,文档也修改了N次。需求过程横跨了3个多星期,并且在最后需求确认时,还是能抛出一些当初没考虑到的情况,直接影响主功能点。

在考勤管理需求上,一开始,我们考虑到了用户有两类:一线APP用户+PC端后台管理员。

APP用户可以使用功能打卡签到,以及提出外出请假申请。PC端后台管理员需要提前配置打卡地点、时间、定位允许的误差距离等。

但在随后的沟通中,又有人提出:每天打卡是否可以重复?外出申请是否可以跨月,或请之前漏打卡的假?同一天又有打卡又有请假,以哪个为准?还有哪些情况没考虑到?

所以,我们会经常发现:不论是分析、设计类工作,在定稿完,甚至是系统出现问题时,还是会出现漏考虑的场景,使得不断的返工。

哪怕在生活中,出门办事,做份旅游攻略,可能也会有或多或少的,本可以提前准备,却没有考虑到的情况,使得旅途过程有了不必要的麻烦。

而考虑场景时,更多还是凭借经验,和不断的讨论,靠着每个人偶然间想到的情况来不断完善,始终有种依靠运气的感觉。

于是尝试着思考,有什么办法,能按照规律,尽可能的考虑周全。

(其实,就是分类与排列组合的应用)

在最近接触的需求里,感觉需求大致可分为两种:流程型、离散型。

流程型

像入职流程、购物结算流程、注册流程等,事情有明显的先后顺序,前面做完了才能做后面的。

整个需求就好像是一条直线,线的不同位置,分别有些节点,可以引申到其他关联的属性上。

离散型

像出勤打卡、学习培训、即时通讯等,细分的模块之间存在并发的可能,发生顺序无法预知的。

整个需求好像可以拆分成一个个独立的模块,每个模块实现自己的功能,相互间存在多种可能的联系,并且实际使用时,没有严格的前后顺序。

我们回头再看考勤管理模块(为了更好的说明,缩小了模块范围):

按照先分类、再做排列组合分析的方式分析。

需求用户中,发现打卡用户还可以细分为两种行为:打卡+外出申请。于是先分类,按大致的业务场景,分成各个离散的模块。

A:打卡签到行为;B:外出申请行为;C:后台配置行为

单个分析

A:可以细分为时间、地点、状态。

时间:这次只做上班打卡,且只能在某个时间范围内打卡。比如上班时间是9:30,允许前后增加2小时,打卡范围为7:30到11:30。当然也可以设置成第二天零点起就可以打卡了。在范围外打卡会失败,范围内的,9:30前算正常出勤,9:30后算迟到。

地点:本次需求设定的打卡地点唯一。

状态:分为打卡成功、失败、漏打卡。其中成功时,还会判断正常出勤、迟到,失败和漏打卡都算作缺勤。

B:可以细分为申请、审批。

申请:同样也有时间、地点、状态的维度。当然,申请没有地点要求,状态也是跟审批有关。

时间上,因为本月和跨月在业务上有不同的管理,所以也要拆开。分为:上月及以前日期的外出申请、本月内以前的外出、当日外出、本月内以后的外出、下月及以后的外出。

其中,确定了申请不能跨月,并且只能申请当天或未来的外出或请假,否则拒绝申请。

审批:为了简单,这里就不做分析了。

C:可以细分为配置地点、时间、范围、误差、补打卡。

补打卡:针对APP用户打卡失败或定位不准等各种情况,后台开放补打卡权限。可以补打当月的任意一天卡,以前日期的也行。补打后,则算当日出勤。

其余细分情况:均为配置操作,应当在APP正式使用前,配置好。

这样ABC各自独立的范围就缩小了,因为一旦包括了范围外的场景点,就会以A或B或C单个的处理方式为准。

两两分析

A与B:

打卡状态和时间,与外出申请的排列组合分析。

  • 未来外出申请:对今日是否打卡、打卡状态、打卡时间都没有影响。
  • 当日外出申请:今日漏打卡,则以当做外出申请处理;今日先打卡后申请、今日先申请后打卡,都以打卡时间和状态为准。其中,打卡时间对申请没有影响。

A与C:

整体上看,更多的是顺序问题。虽然可以细分为未配置时间、地点、误差等分别对A的影响,但实际应用中,都属于同一类问题:C没有完成,A打不了卡。

  • 先完成C,再做A:没有问题,正常流程。
  • 先做A,再做C:A需要提示,此时是否允许打卡,先留存打卡数据,待C配置后,自动处理历史数据?

补打卡:是否要限制补打卡和APP打卡在同一天时,只能存在一个?不限制的话,如果C做了当日的补打卡,且当天APP又打卡成功,则以哪个为准?

B与C:

没有直接的影响关系,即配不配置,与外出申请是两条不相交的平行线。除了补打卡。

补打卡:是否要限制补打卡和外出申请在同一天时,只能存在一个?不限制的话,如果C做了某日的补打卡,且当天又有外出申请,则以哪个为准?

A与A:

考虑的是重复多次打卡,和不同时间段的多次打卡。显然实际情况时比较简单,APP每天只允许打卡一次即可。

B与B:

考虑的是多次申请中,申请日期区间完全重叠?日期区间有部分交叉?新申请日期刚好衔接着以前的申请区间?申请有间隔日期的情况?

C与C:

比较好理解和控制,无非是多次配置后,是做修改更新,还是属于新增操作等。补打卡时,同一天只允许补打卡一次。

三三分析

先看下三三关系,在考勤管理中,A与B有联系,A与C有联系,B与C是间接联系,没有实质影响。

A与B与C:

因此真正要考虑的是分别以B、C为变化点,是否对另外两个模块联合分析有影响。

B为变化点:

在A与C基础上,外出申请、补打卡、APP打卡是否有先后本文由 @XXX 原创发布于人人都是产品经理。未经许可,禁止转载顺序影响,由于AC、BC,都是以补打卡为准,所以ABC情况下,也是以补打卡为准,无先后顺序影响。

但如果AC时,以APP打卡为准,BC时,以补打卡为准,AB时,以外出申请为准,就可能存在顺序问题。所以最好的就是设置一个准则:无论当天是否有外出申请、APP是否打卡,都以补打卡为准。

即优先级:补打卡 > APP打卡 > 外出申请。这就能缩小分析范围。

C为变化点:同上。

AAB、ABB、AAC、ACC、BBC、BCC:其实都可以当做两两分析中的情况处理,不用考虑太多。

整个过程下来,主要分为两步:

1、拆解分类;

2、单独、组合分析。

可能有人会质疑做个分析,需要这么多时间精力成本,还不如凭借经验和讨论,尤其对小需求。

首先,上述都是为了说明清楚才写出来。实际情况时,我们只要大致分好类,在脑海中做组合分析就行,记录下有疑问的点即可,时间成本应该不会很高。

并且,需要我们根据实际情况,决定投入的精力成本。投入的越多,当然考虑的越充分,但可能发生的概率会越来越小,因此需要考虑投入产出比。

以上只是对离散化的需求,做的小的复盘过程。

如果有更好的分析方法,可以随时留言沟通~共同进步~

PS:有兴趣还可以考虑,B增加一个功能:外出申请审核,该怎么分析?

 

本文由 @坑die的达叔 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash ,基于 CC0 协议

赞赏是对原创者的最大认可
4人打赏
评论
欢迎留言交流
  1. 哈喽,请教一下大牛,考勤打卡机系统的打卡数据的如何筛选能分析出来疑似代打卡这种行为的

    回复
    1. HI,不是大牛,只是一只产品狗。这个超出我范围了 :oops: 偏向于数据伪造和作弊哈

      回复
    2. 抛开怎么做,我们试试当做一个问题来玩哈(图贴不上来,只能手写了):
      1、分析什么是疑似代打卡,以及场景和方式?
      2、怎么解决。

      回复
    3. 疑似代打卡(只考虑上班):定义、原因、场景

      1、定义:自己需要打卡,但通过某种方式交由他人代打,从而自己未打,但有打卡记录的现象。

      2、原因:包含不限于距离、习惯、特殊需要、制度、环境等(考虑不全哈)

      按下述单独分类后,可以是各种原因的综合情况。

      距离:住的远,往往时间来不及。
      习惯:就是懒,赖床,磨蹭,不想起。
      特殊需要:突然生病、路上突发事故、或者天生身体有缺陷不适、做不到。
      制度:漏打卡或者迟到,扣当天工资的一半(夸张了),或者考核要求,有事请假难等。
      环境:打卡机位置太偏,不够人性化,比如先上23楼打卡,再下到3楼吃早餐,于是需要代打。

      3、场景:时间段、打卡方式

      打卡方式:
      a:一人打多卡(指纹模、员工卡、别人的手机等)
      b:不用打卡的外部人帮别人打卡
      c:某种方式伪造打卡记录

      时间段(要参考实际数据来划分时间段,以下纯粹假设):
      a:上班时间前10分钟以外
      大伙慢悠悠,不着急,零零散散的打卡行为,不会有排队打卡的现象。此时代打卡少。
      b:上班时间前10分钟内
      打卡高峰,打卡机前可能会排队,临近迟到的人来不及,因此有代打卡的强烈需要,更多有特殊需要、习惯、环境、距离等原因吧。
      c:上班时间后10分钟内
      会有些迟到的人打卡,可能因为漏打卡损失更多,宁愿打迟到卡,此时也会有代打卡需要,比较少,反正迟到了。
      d:上班时间后10分钟以外
      很少有人再打卡,代打卡的需要应该很低,除非是病假之类的长期原因。

      回复
    4. 怎么解决(仅仅参考):预防、控制、排查

      1、预防:从制度、环境、特殊需要来看,制度是不是过于严格(类似二次方曲线),适度放宽也许能减少行为;打卡机位置是不是不合人的行为习惯,减少员工自主打卡的阻力和耗费时间(缩短转化路径),请假制度是不是太苛刻。

      2、控制:打卡机设定的策略啦,包括摄像头等。

      3、排查:拉出每日时间-每个打卡记录的曲线图(打卡时间排高低),拉出半年或一年日期-固定时间打卡记录曲线图,用后者寻找规律和趋势,用前者寻找毛刺点(不合常规、斜率变化大的)
      比如大约每5秒一个打卡记录,但有一段是每3秒,或者每7,8秒,这就要查,因为有可能他在换指模哈。

      回复
    5. 采用活体人脸解锁SDK,植入到APP中。每次打卡的时候采用人脸进行打卡
      注:1.活体:照片,识别等无法打卡成功。

      每次打卡的时候进行人脸图像处理保存,上传到服务器显示在web前端。我还好奇你能怎么作弊带打卡 :|

      回复
    6. 注意需要同时访问人脸信息,定位信息,在联网情况下访问人脸数据库。根据前后端照片筛选对比确认此人在打卡范围并确定打卡唯一性,即可完成打卡。并同时防止了代打卡等作弊现象 :mrgreen:

      回复
    7. 棒! :mrgreen: 当然,不考虑成本的情况下

      回复
    8. 之前有一家合作公司,就是做人脸考勤的 Aiwinn 可以了解一下 有免费和收费两个商业模式

      回复
    9. 感谢O(∩_∩)O

      回复
  2. toB分析

    回复
    1. 其实我们是针对代理人设计的APP :oops:

      回复
  3. 我也是做考勤,哈哈哈!大功能

    回复
    1. 请问考勤系统里边,哺乳假如何设计啊?

      回复
    2. 假期设置-每个公司根据公司各种假期福利进行设置。哺乳假+更多(自定义)

      回复
    3. 哈哈哈,握爪握爪,冰山剩下的大部分,还等着你去挖掘

      回复
  4. 为什么不直接参考钉钉打卡、外勤的设计方式?

    回复
    1. 嗯!好主意,可以体验、梳理用到的功能和范围,调查已有产品。只是,如果能拿到设计的功能关系图就更好了,因为如果是我,直接玩钉钉去梳理,感觉更像是做黑盒测试、或寻找已有疑问的解决方案,比如纠结是否允许同一天多次打卡?同一天又打卡又请假,我们按哪个处理好?可以参考钉钉是怎么处理的。但是为了考虑大部分可能出现的逻辑关系,避免BUG,除非花时间去梳理其他产品(一个个点去试)感觉确实还是要我们自己有初步设计哈。

      回复
    2. 而且通过思考,我们能知道为什么做这个功能,为什么这么设计关系,有助于业务和团队理解功能的意义。所以觉得可以适合结合起来哈,在内部关系分析完后,对拿不准解决方案的问题点上,看看人家是怎么做的,会更有效率。

      回复