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

一

上個月，我們在做項目的考勤管理和入職流程需求溝通時，前后討論了不下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 協議