起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從考勤管理需求說起，聊聊場景的思維“工具”
你是否有過做問題分析時，毫無頭緒，生怕會遺漏什么？是否在逐條列出方案后，依然會有人提出些沒想到的問題？看一下作者是如何解決的。
一
上個月，我們在做項目的考勤管理和入職流程需求溝通時，前后討論了不下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用戶打卡失敗或定位不準等各種情況，后臺開放補打卡權限?？梢匝a打當月的任意一天卡，以前日期的也行。補打后，則算當日出勤。
其余細分情況：均為配置操作，應當在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 協議
什么是未來外出打卡
這是18年從0到1做的初版，所以不支持外出打卡功能，需用戶到規定地點如職場打卡，但給未來留下可擴展性（數據表層面），以后用戶外出活動，培訓之類都可以不在職場打卡，未來支持這樣的功能
實際中通用的考勤系統比這個面臨的情況還要復雜不少，比如打卡來源無法單一控制在ap上，還有從各種第三方批量同步倒入的打卡數據、另外打卡和申請之間的優先級關系也是不同客戶有不同的要求，打卡優先，申請優先，打卡和申請取交集等等不一而足，還有好多考勤細節問題不勝枚舉……
說的對，目前已經迭代多次，包括去年上了人臉識別打卡，識別時剛好在遲到點附近，需以發起時的時間為打卡時間才不被用戶埋怨，甚至遲到時間默認延后一分鐘。也有后臺批量導入的培訓名單，主要屬考勤統計范疇，還包括人員入司離司，統計時間以第二天開始，已經請假后的審批問題，上月申請這月才審批，可上月考勤已通算完畢該怎么辦，以及是否可以隨時請假，已經遲到了立馬請假是否可行，然后又打上班卡了算哪個，是有，需要根據實際業務管理制度來制定了
我也是做HR SaaS產品的，我覺得你這個邏輯分析的思路挺麻煩的。我的邏輯是：程序只需要判斷每天是否有異常的出勤記錄就行了，接下來就只需要拆解哪些情況判斷為異常的出勤記錄？首先判斷當天有沒有在規定規則（時間、位置、wifi）打卡，若打卡了為正常出勤，若沒有打卡記錄，再接著判斷是否有外出、補卡、出差單，如果沒有則進一步判斷是否有請假單，如果有請假單，則為請假異常出勤記錄；如果沒有請假單，則為異常出勤記錄。如果有外出、補卡、出差單，接著判斷有沒有審批通過，沒有審批通過則為異常的出勤記錄，審批通過了則為正常出勤。歡迎交流 ??
感覺樓主的方法雖然復雜，但是這套思考方法可以考慮得更全面，避免遺漏吧
謝謝哈，這里也主要引申這種思考方式，應對各種特殊定制化需求吧，跟客戶PK更有底
隔的時間有點久哈。對，對于服務產品化，如果一開始能敲定明確的判斷優先級，上面的分析很大部分不用考慮，直接做成品銷售。當然這樣有前提條件哈，只是我的看法哈：
1、產品規則自己就能拍板下來。
服務型產品可以由自己公司拍板提前做好原型哈，少量定制化后再賣給客戶。我們只是公司內開發團隊，不斷根據公司內各部門要求定制化需求開發，每個部門特殊要求可能不同，如有同一天又有請假“培訓”理由的又有下班打卡的，按半天培訓，半天打卡算。有的部門就按全天培訓算。
2、其他情況做好了特殊處理。
有了判斷優先級，可能要考慮APP操作異常的特殊處理，避免一條提示語覆蓋所有異常：如一天能否允許打N次卡，是否以最早的一次為準；能否允許請假日期交叉，交叉如何處理；能否允許補上月的外出請假，今天只打了上班沒打下班卡能否晚上23點補個外出申請；后臺沒配置打卡規則，該提示用戶不能打卡還是先允許打卡。按實際情況可能需要考慮哈。
3、業務需求的不會靈活變化。
我們面對的是業務部門1個月變化一次的規則調整，今天出勤率按上班打卡統計，下周就考慮有半天打卡半天請假的情況，哪些請假算缺勤，哪些算正常出勤，如果半天打卡半天請假（正常出勤類事由），出勤天數計算公式就要改變。
文中的方法也就只是針對這些特殊情況哈，提前思考清楚。感謝提供的方案，思路很清晰~
哈嘍，請教一下大牛，考勤打卡機系統的打卡數據的如何篩選能分析出來疑似代打卡這種行為的
HI，不是大牛，只是一只產品狗。這個超出我范圍了 ?? 偏向于數據偽造和作弊哈
拋開怎么做，我們試試當做一個問題來玩哈（圖貼不上來，只能手寫了）：
1、分析什么是疑似代打卡，以及場景和方式？
2、怎么解決。
疑似代打卡（只考慮上班）：定義、原因、場景
1、定義：自己需要打卡，但通過某種方式交由他人代打，從而自己未打，但有打卡記錄的現象。
2、原因：包含不限于距離、習慣、特殊需要、制度、環境等（考慮不全哈）
按下述單獨分類后，可以是各種原因的綜合情況。
距離：住的遠，往往時間來不及。
習慣：就是懶，賴床，磨蹭，不想起。
特殊需要：突然生病、路上突發事故、或者天生身體有缺陷不適、做不到。
制度：漏打卡或者遲到，扣當天工資的一半（夸張了），或者考核要求，有事請假難等。
環境：打卡機位置太偏，不夠人性化，比如先上23樓打卡，再下到3樓吃早餐，于是需要代打。
3、場景：時間段、打卡方式
打卡方式：
a：一人打多卡（指紋模、員工卡、別人的手機等）
b：不用打卡的外部人幫別人打卡
c：某種方式偽造打卡記錄
時間段（要參考實際數據來劃分時間段，以下純粹假設）：
a：上班時間前10分鐘以外
大伙慢悠悠，不著急，零零散散的打卡行為，不會有排隊打卡的現象。此時代打卡少。
b：上班時間前10分鐘內
打卡高峰，打卡機前可能會排隊，臨近遲到的人來不及，因此有代打卡的強烈需要，更多有特殊需要、習慣、環境、距離等原因吧。
c：上班時間后10分鐘內
會有些遲到的人打卡，可能因為漏打卡損失更多，寧愿打遲到卡，此時也會有代打卡需要，比較少，反正遲到了。
d：上班時間后10分鐘以外
很少有人再打卡，代打卡的需要應該很低，除非是病假之類的長期原因。
怎么解決（僅僅參考）：預防、控制、排查
1、預防：從制度、環境、特殊需要來看，制度是不是過于嚴格（類似二次方曲線），適度放寬也許能減少行為；打卡機位置是不是不合人的行為習慣，減少員工自主打卡的阻力和耗費時間（縮短轉化路徑），請假制度是不是太苛刻。
2、控制：打卡機設定的策略啦，包括攝像頭等。
3、排查：拉出每日時間-每個打卡記錄的曲線圖（打卡時間排高低），拉出半年或一年日期-固定時間打卡記錄曲線圖，用后者尋找規律和趨勢，用前者尋找毛刺點（不合常規、斜率變化大的）
比如大約每5秒一個打卡記錄，但有一段是每3秒，或者每7,8秒，這就要查，因為有可能他在換指模哈。
采用活體人臉解鎖SDK，植入到APP中。每次打卡的時候采用人臉進行打卡
注：1.活體：照片，識別等無法打卡成功。
每次打卡的時候進行人臉圖像處理保存，上傳到服務器顯示在web前端。我還好奇你能怎么作弊帶打卡 ??
注意需要同時訪問人臉信息，定位信息，在聯網情況下訪問人臉數據庫。根據前后端照片篩選對比確認此人在打卡范圍并確定打卡唯一性，即可完成打卡。并同時防止了代打卡等作弊現象
棒！
當然，不考慮成本的情況下
之前有一家合作公司，就是做人臉考勤的 Aiwinn 可以了解一下 有免費和收費兩個商業模式
感謝O(∩_∩)O
toB分析
其實我們是針對代理人設計的APP ??
我也是做考勤，哈哈哈！大功能
請問考勤系統里邊，哺乳假如何設計??？
假期設置-每個公司根據公司各種假期福利進行設置。哺乳假+更多（自定義）
哈哈哈，握爪握爪，冰山剩下的大部分，還等著你去挖掘
為什么不直接參考釘釘打卡、外勤的設計方式？
嗯！好主意，可以體驗、梳理用到的功能和范圍，調查已有產品。只是，如果能拿到設計的功能關系圖就更好了，因為如果是我，直接玩釘釘去梳理，感覺更像是做黑盒測試、或尋找已有疑問的解決方案，比如糾結是否允許同一天多次打卡？同一天又打卡又請假，我們按哪個處理好？可以參考釘釘是怎么處理的。但是為了考慮大部分可能出現的邏輯關系，避免BUG，除非花時間去梳理其他產品（一個個點去試）感覺確實還是要我們自己有初步設計哈。
而且通過思考，我們能知道為什么做這個功能，為什么這么設計關系，有助于業務和團隊理解功能的意義。所以覺得可以適合結合起來哈，在內部關系分析完后，對拿不準解決方案的問題點上，看看人家是怎么做的，會更有效率。
有道理 ??
比如現在有的客戶部門要求半天打卡半天外出的以最大利益化為準，有的客戶就只要求以打卡為準，有這些客戶根據自己需要的定制化規則需要實現