從考勤管理需求說起,聊聊場景的思維“工具”

29 評論 17401 瀏覽 102 收藏 11 分鐘

你是否有過做問題分析時,毫無頭緒,生怕會遺漏什么?是否在逐條列出方案后,依然會有人提出些沒想到的問題?看一下作者是如何解決的。

上個月,我們在做項目的考勤管理和入職流程需求溝通時,前后討論了不下10次,文檔也修改了N次。需求過程橫跨了3個多星期,并且在最后需求確認時,還是能拋出一些當初沒考慮到的情況,直接影響主功能點。

在考勤管理需求上,一開始,我們考慮到了用戶有兩類:一線APP用戶+PC端后臺管理員。

APP用戶可以使用功能打卡簽到,以及提出外出請假申請。PC端后臺管理員需要提前配置打卡地點、時間、定位允許的誤差距離等。

但在隨后的溝通中,又有人提出:每天打卡是否可以重復?外出申請是否可以跨月,或請之前漏打卡的假?同一天又有打卡又有請假,以哪個為準?還有哪些情況沒考慮到?

所以,我們會經(jīng)常發(fā)現(xiàn):不論是分析、設(shè)計類工作,在定稿完,甚至是系統(tǒng)出現(xiàn)問題時,還是會出現(xiàn)漏考慮的場景,使得不斷的返工。

哪怕在生活中,出門辦事,做份旅游攻略,可能也會有或多或少的,本可以提前準備,卻沒有考慮到的情況,使得旅途過程有了不必要的麻煩。

而考慮場景時,更多還是憑借經(jīng)驗,和不斷的討論,靠著每個人偶然間想到的情況來不斷完善,始終有種依靠運氣的感覺。

于是嘗試著思考,有什么辦法,能按照規(guī)律,盡可能的考慮周全。

(其實,就是分類與排列組合的應(yīng)用)

在最近接觸的需求里,感覺需求大致可分為兩種:流程型、離散型。

流程型

像入職流程、購物結(jié)算流程、注冊流程等,事情有明顯的先后順序,前面做完了才能做后面的。

整個需求就好像是一條直線,線的不同位置,分別有些節(jié)點,可以引申到其他關(guān)聯(lián)的屬性上。

離散型

像出勤打卡、學習培訓、即時通訊等,細分的模塊之間存在并發(fā)的可能,發(fā)生順序無法預知的。

整個需求好像可以拆分成一個個獨立的模塊,每個模塊實現(xiàn)自己的功能,相互間存在多種可能的聯(lián)系,并且實際使用時,沒有嚴格的前后順序。

我們回頭再看考勤管理模塊(為了更好的說明,縮小了模塊范圍):

按照先分類、再做排列組合分析的方式分析。

需求用戶中,發(fā)現(xiàn)打卡用戶還可以細分為兩種行為:打卡+外出申請。于是先分類,按大致的業(yè)務(wù)場景,分成各個離散的模塊。

A:打卡簽到行為;B:外出申請行為;C:后臺配置行為

單個分析

A:可以細分為時間、地點、狀態(tài)。

時間:這次只做上班打卡,且只能在某個時間范圍內(nèi)打卡。比如上班時間是9:30,允許前后增加2小時,打卡范圍為7:30到11:30。當然也可以設(shè)置成第二天零點起就可以打卡了。在范圍外打卡會失敗,范圍內(nèi)的,9:30前算正常出勤,9:30后算遲到。

地點:本次需求設(shè)定的打卡地點唯一。

狀態(tài):分為打卡成功、失敗、漏打卡。其中成功時,還會判斷正常出勤、遲到,失敗和漏打卡都算作缺勤。

B:可以細分為申請、審批。

申請:同樣也有時間、地點、狀態(tài)的維度。當然,申請沒有地點要求,狀態(tài)也是跟審批有關(guān)。

時間上,因為本月和跨月在業(yè)務(wù)上有不同的管理,所以也要拆開。分為:上月及以前日期的外出申請、本月內(nèi)以前的外出、當日外出、本月內(nèi)以后的外出、下月及以后的外出。

其中,確定了申請不能跨月,并且只能申請當天或未來的外出或請假,否則拒絕申請。

審批:為了簡單,這里就不做分析了。

C:可以細分為配置地點、時間、范圍、誤差、補打卡。

補打卡:針對APP用戶打卡失敗或定位不準等各種情況,后臺開放補打卡權(quán)限。可以補打當月的任意一天卡,以前日期的也行。補打后,則算當日出勤。

其余細分情況:均為配置操作,應(yīng)當在APP正式使用前,配置好。

這樣ABC各自獨立的范圍就縮小了,因為一旦包括了范圍外的場景點,就會以A或B或C單個的處理方式為準。

兩兩分析

A與B:

打卡狀態(tài)和時間,與外出申請的排列組合分析。

  • 未來外出申請:對今日是否打卡、打卡狀態(tài)、打卡時間都沒有影響。
  • 當日外出申請:今日漏打卡,則以當做外出申請?zhí)幚?;今日先打卡后申請、今日先申請后打卡,都以打卡時間和狀態(tài)為準。其中,打卡時間對申請沒有影響。

A與C:

整體上看,更多的是順序問題。雖然可以細分為未配置時間、地點、誤差等分別對A的影響,但實際應(yīng)用中,都屬于同一類問題:C沒有完成,A打不了卡。

  • 先完成C,再做A:沒有問題,正常流程。
  • 先做A,再做C:A需要提示,此時是否允許打卡,先留存打卡數(shù)據(jù),待C配置后,自動處理歷史數(shù)據(jù)?

補打卡:是否要限制補打卡和APP打卡在同一天時,只能存在一個?不限制的話,如果C做了當日的補打卡,且當天APP又打卡成功,則以哪個為準?

B與C:

沒有直接的影響關(guān)系,即配不配置,與外出申請是兩條不相交的平行線。除了補打卡。

補打卡:是否要限制補打卡和外出申請在同一天時,只能存在一個?不限制的話,如果C做了某日的補打卡,且當天又有外出申請,則以哪個為準?

A與A:

考慮的是重復多次打卡,和不同時間段的多次打卡。顯然實際情況時比較簡單,APP每天只允許打卡一次即可。

B與B:

考慮的是多次申請中,申請日期區(qū)間完全重疊?日期區(qū)間有部分交叉?新申請日期剛好銜接著以前的申請區(qū)間?申請有間隔日期的情況?

C與C:

比較好理解和控制,無非是多次配置后,是做修改更新,還是屬于新增操作等。補打卡時,同一天只允許補打卡一次。

三三分析

先看下三三關(guān)系,在考勤管理中,A與B有聯(lián)系,A與C有聯(lián)系,B與C是間接聯(lián)系,沒有實質(zhì)影響。

A與B與C:

因此真正要考慮的是分別以B、C為變化點,是否對另外兩個模塊聯(lián)合分析有影響。

B為變化點:

在A與C基礎(chǔ)上,外出申請、補打卡、APP打卡是否有先后本文由 @XXX 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載順序影響,由于AC、BC,都是以補打卡為準,所以ABC情況下,也是以補打卡為準,無先后順序影響。

但如果AC時,以APP打卡為準,BC時,以補打卡為準,AB時,以外出申請為準,就可能存在順序問題。所以最好的就是設(shè)置一個準則:無論當天是否有外出申請、APP是否打卡,都以補打卡為準。

即優(yōu)先級:補打卡 > APP打卡 > 外出申請。這就能縮小分析范圍。

C為變化點:同上。

AAB、ABB、AAC、ACC、BBC、BCC:其實都可以當做兩兩分析中的情況處理,不用考慮太多。

整個過程下來,主要分為兩步:

1、拆解分類;

2、單獨、組合分析。

可能有人會質(zhì)疑做個分析,需要這么多時間精力成本,還不如憑借經(jīng)驗和討論,尤其對小需求。

首先,上述都是為了說明清楚才寫出來。實際情況時,我們只要大致分好類,在腦海中做組合分析就行,記錄下有疑問的點即可,時間成本應(yīng)該不會很高。

并且,需要我們根據(jù)實際情況,決定投入的精力成本。投入的越多,當然考慮的越充分,但可能發(fā)生的概率會越來越小,因此需要考慮投入產(chǎn)出比。

以上只是對離散化的需求,做的小的復盤過程。

如果有更好的分析方法,可以隨時留言溝通~共同進步~

PS:有興趣還可以考慮,B增加一個功能:外出申請審核,該怎么分析?

 

本文由 @坑die的達叔 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自 Unsplash ,基于 CC0 協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 什么是未來外出打卡

    來自廣東 回復
    1. 這是18年從0到1做的初版,所以不支持外出打卡功能,需用戶到規(guī)定地點如職場打卡,但給未來留下可擴展性(數(shù)據(jù)表層面),以后用戶外出活動,培訓之類都可以不在職場打卡,未來支持這樣的功能

      回復
  2. 實際中通用的考勤系統(tǒng)比這個面臨的情況還要復雜不少,比如打卡來源無法單一控制在ap上,還有從各種第三方批量同步倒入的打卡數(shù)據(jù)、另外打卡和申請之間的優(yōu)先級關(guān)系也是不同客戶有不同的要求,打卡優(yōu)先,申請優(yōu)先,打卡和申請取交集等等不一而足,還有好多考勤細節(jié)問題不勝枚舉……

    回復
    1. 說的對,目前已經(jīng)迭代多次,包括去年上了人臉識別打卡,識別時剛好在遲到點附近,需以發(fā)起時的時間為打卡時間才不被用戶埋怨,甚至遲到時間默認延后一分鐘。也有后臺批量導入的培訓名單,主要屬考勤統(tǒng)計范疇,還包括人員入司離司,統(tǒng)計時間以第二天開始,已經(jīng)請假后的審批問題,上月申請這月才審批,可上月考勤已通算完畢該怎么辦,以及是否可以隨時請假,已經(jīng)遲到了立馬請假是否可行,然后又打上班卡了算哪個,是有,需要根據(jù)實際業(yè)務(wù)管理制度來制定了

      回復
  3. 我也是做HR SaaS產(chǎn)品的,我覺得你這個邏輯分析的思路挺麻煩的。我的邏輯是:程序只需要判斷每天是否有異常的出勤記錄就行了,接下來就只需要拆解哪些情況判斷為異常的出勤記錄?首先判斷當天有沒有在規(guī)定規(guī)則(時間、位置、wifi)打卡,若打卡了為正常出勤,若沒有打卡記錄,再接著判斷是否有外出、補卡、出差單,如果沒有則進一步判斷是否有請假單,如果有請假單,則為請假異常出勤記錄;如果沒有請假單,則為異常出勤記錄。如果有外出、補卡、出差單,接著判斷有沒有審批通過,沒有審批通過則為異常的出勤記錄,審批通過了則為正常出勤。歡迎交流 ??

    來自安徽 回復
    1. 感覺樓主的方法雖然復雜,但是這套思考方法可以考慮得更全面,避免遺漏吧

      來自上海 回復
    2. 謝謝哈,這里也主要引申這種思考方式,應(yīng)對各種特殊定制化需求吧,跟客戶PK更有底

      來自湖南 回復
    3. 隔的時間有點久哈。對,對于服務(wù)產(chǎn)品化,如果一開始能敲定明確的判斷優(yōu)先級,上面的分析很大部分不用考慮,直接做成品銷售。當然這樣有前提條件哈,只是我的看法哈:
      1、產(chǎn)品規(guī)則自己就能拍板下來。
      服務(wù)型產(chǎn)品可以由自己公司拍板提前做好原型哈,少量定制化后再賣給客戶。我們只是公司內(nèi)開發(fā)團隊,不斷根據(jù)公司內(nèi)各部門要求定制化需求開發(fā),每個部門特殊要求可能不同,如有同一天又有請假“培訓”理由的又有下班打卡的,按半天培訓,半天打卡算。有的部門就按全天培訓算。
      2、其他情況做好了特殊處理。
      有了判斷優(yōu)先級,可能要考慮APP操作異常的特殊處理,避免一條提示語覆蓋所有異常:如一天能否允許打N次卡,是否以最早的一次為準;能否允許請假日期交叉,交叉如何處理;能否允許補上月的外出請假,今天只打了上班沒打下班卡能否晚上23點補個外出申請;后臺沒配置打卡規(guī)則,該提示用戶不能打卡還是先允許打卡。按實際情況可能需要考慮哈。
      3、業(yè)務(wù)需求的不會靈活變化。
      我們面對的是業(yè)務(wù)部門1個月變化一次的規(guī)則調(diào)整,今天出勤率按上班打卡統(tǒng)計,下周就考慮有半天打卡半天請假的情況,哪些請假算缺勤,哪些算正常出勤,如果半天打卡半天請假(正常出勤類事由),出勤天數(shù)計算公式就要改變。
      文中的方法也就只是針對這些特殊情況哈,提前思考清楚。感謝提供的方案,思路很清晰~

      來自湖南 回復
  4. 哈嘍,請教一下大牛,考勤打卡機系統(tǒng)的打卡數(shù)據(jù)的如何篩選能分析出來疑似代打卡這種行為的

    來自上海 回復
    1. HI,不是大牛,只是一只產(chǎn)品狗。這個超出我范圍了 ?? 偏向于數(shù)據(jù)偽造和作弊哈

      來自湖南 回復
    2. 拋開怎么做,我們試試當做一個問題來玩哈(圖貼不上來,只能手寫了):
      1、分析什么是疑似代打卡,以及場景和方式?
      2、怎么解決。

      來自湖南 回復
    3. 疑似代打卡(只考慮上班):定義、原因、場景

      1、定義:自己需要打卡,但通過某種方式交由他人代打,從而自己未打,但有打卡記錄的現(xiàn)象。

      2、原因:包含不限于距離、習慣、特殊需要、制度、環(huán)境等(考慮不全哈)

      按下述單獨分類后,可以是各種原因的綜合情況。

      距離:住的遠,往往時間來不及。
      習慣:就是懶,賴床,磨蹭,不想起。
      特殊需要:突然生病、路上突發(fā)事故、或者天生身體有缺陷不適、做不到。
      制度:漏打卡或者遲到,扣當天工資的一半(夸張了),或者考核要求,有事請假難等。
      環(huán)境:打卡機位置太偏,不夠人性化,比如先上23樓打卡,再下到3樓吃早餐,于是需要代打。

      3、場景:時間段、打卡方式

      打卡方式:
      a:一人打多卡(指紋模、員工卡、別人的手機等)
      b:不用打卡的外部人幫別人打卡
      c:某種方式偽造打卡記錄

      時間段(要參考實際數(shù)據(jù)來劃分時間段,以下純粹假設(shè)):
      a:上班時間前10分鐘以外
      大伙慢悠悠,不著急,零零散散的打卡行為,不會有排隊打卡的現(xiàn)象。此時代打卡少。
      b:上班時間前10分鐘內(nèi)
      打卡高峰,打卡機前可能會排隊,臨近遲到的人來不及,因此有代打卡的強烈需要,更多有特殊需要、習慣、環(huán)境、距離等原因吧。
      c:上班時間后10分鐘內(nèi)
      會有些遲到的人打卡,可能因為漏打卡損失更多,寧愿打遲到卡,此時也會有代打卡需要,比較少,反正遲到了。
      d:上班時間后10分鐘以外
      很少有人再打卡,代打卡的需要應(yīng)該很低,除非是病假之類的長期原因。

      來自湖南 回復
    4. 怎么解決(僅僅參考):預防、控制、排查

      1、預防:從制度、環(huán)境、特殊需要來看,制度是不是過于嚴格(類似二次方曲線),適度放寬也許能減少行為;打卡機位置是不是不合人的行為習慣,減少員工自主打卡的阻力和耗費時間(縮短轉(zhuǎn)化路徑),請假制度是不是太苛刻。

      2、控制:打卡機設(shè)定的策略啦,包括攝像頭等。

      3、排查:拉出每日時間-每個打卡記錄的曲線圖(打卡時間排高低),拉出半年或一年日期-固定時間打卡記錄曲線圖,用后者尋找規(guī)律和趨勢,用前者尋找毛刺點(不合常規(guī)、斜率變化大的)
      比如大約每5秒一個打卡記錄,但有一段是每3秒,或者每7,8秒,這就要查,因為有可能他在換指模哈。

      來自湖南 回復
    5. 采用活體人臉解鎖SDK,植入到APP中。每次打卡的時候采用人臉進行打卡
      注:1.活體:照片,識別等無法打卡成功。

      每次打卡的時候進行人臉圖像處理保存,上傳到服務(wù)器顯示在web前端。我還好奇你能怎么作弊帶打卡 ??

      來自廣東 回復
    6. 注意需要同時訪問人臉信息,定位信息,在聯(lián)網(wǎng)情況下訪問人臉數(shù)據(jù)庫。根據(jù)前后端照片篩選對比確認此人在打卡范圍并確定打卡唯一性,即可完成打卡。并同時防止了代打卡等作弊現(xiàn)象 :mrgreen:

      來自廣東 回復
    7. 棒! :mrgreen: 當然,不考慮成本的情況下

      來自湖南 回復
    8. 之前有一家合作公司,就是做人臉考勤的 Aiwinn 可以了解一下 有免費和收費兩個商業(yè)模式

      來自廣東 回復
    9. 感謝O(∩_∩)O

      來自上海 回復
  5. toB分析

    回復
    1. 其實我們是針對代理人設(shè)計的APP ??

      來自湖南 回復
  6. 我也是做考勤,哈哈哈!大功能

    來自廣東 回復
    1. 請問考勤系統(tǒng)里邊,哺乳假如何設(shè)計???

      來自上海 回復
    2. 假期設(shè)置-每個公司根據(jù)公司各種假期福利進行設(shè)置。哺乳假+更多(自定義)

      來自廣東 回復
    3. 哈哈哈,握爪握爪,冰山剩下的大部分,還等著你去挖掘

      來自湖南 回復
  7. 為什么不直接參考釘釘打卡、外勤的設(shè)計方式?

    來自廣東 回復
    1. 嗯!好主意,可以體驗、梳理用到的功能和范圍,調(diào)查已有產(chǎn)品。只是,如果能拿到設(shè)計的功能關(guān)系圖就更好了,因為如果是我,直接玩釘釘去梳理,感覺更像是做黑盒測試、或?qū)ふ乙延幸蓡柕慕鉀Q方案,比如糾結(jié)是否允許同一天多次打卡?同一天又打卡又請假,我們按哪個處理好?可以參考釘釘是怎么處理的。但是為了考慮大部分可能出現(xiàn)的邏輯關(guān)系,避免BUG,除非花時間去梳理其他產(chǎn)品(一個個點去試)感覺確實還是要我們自己有初步設(shè)計哈。

      來自湖南 回復
    2. 而且通過思考,我們能知道為什么做這個功能,為什么這么設(shè)計關(guān)系,有助于業(yè)務(wù)和團隊理解功能的意義。所以覺得可以適合結(jié)合起來哈,在內(nèi)部關(guān)系分析完后,對拿不準解決方案的問題點上,看看人家是怎么做的,會更有效率。

      來自湖南 回復
    3. 有道理 ??

      來自遼寧 回復
    4. 比如現(xiàn)在有的客戶部門要求半天打卡半天外出的以最大利益化為準,有的客戶就只要求以打卡為準,有這些客戶根據(jù)自己需要的定制化規(guī)則需要實現(xiàn)

      來自湖南 回復