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

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

一

上个月，我们在做项目的考勤管理和入职流程需求沟通时，前后讨论了不下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的达叔 。

关键字：产品经理, 方法论, 需求分析

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！