上班打卡是大多數上班狗每天都會做的事情，打卡的方式多種多樣，很多廠商也有很完善的解決方案。這樣一個大家每天習以為常的動作，是不是讓我們都忽略了一件事——考勤打卡實際上是一個to B類型的產品，並且，其背後邏輯一點也不簡單。
一、打卡也要考慮戰略層
做產品的其實都知道，在設計一款產品時，我們首先要考慮的是，公司戰略是如何定位的？我這款產品在公司戰略中處於什麼樣的位置？我的產品可以給用戶帶來什麼價值？
對於打卡這個看似很簡單的產品，其實也要經歷以上思考。
首先我們來看公司層面，一個產品經理需要知道公司處在什麼階段，公司內部的文化是怎麼樣的，然後再決定自己的打卡產品的設計方向。
比如：一個公司處在高速增長階段，企業內部文化極具包容性，對員工的管制少，那打卡產品可以嘗試更多新奇的方向，讓大家要不能從打卡找到樂趣，要不就是在打卡/補卡這種操作上少浪費時間。反之，如果一個公司非常強調對員工的管控，那在打卡上也容不得馬虎，可能需要對打卡範圍和時間嚴格限制，甚至界面也要走嚴肅風。
其次我們要考慮用戶需求，打卡這個東西，是制度催生的需求，而不是員工自己的內在需要。所以，對於員工來說，打卡還是越簡單越好。比如考勤機排隊打卡就沒有用手機軟體打卡舒服，而用手機軟體打卡肯定沒有不打卡讓人心情愉悅。
做為一個產品經理，還是要在用戶需求和公司戰略中找到一種平衡，要在公司認可的情況下做到用戶體驗最好，說起來很簡單，但做起來非常困難，還容易出現兩頭都得罪的情況，需要產品經理好好把握。
二、不止打卡頁面
考勤打卡實際上應該是一整套系統，打卡只是其中的一個部分，可以看做是系統中的數據錄入的頁面，只有與其他系統結合，打卡這個頁面才是具有意義的。而這一整套系統的組成，大致有以下幾個部分組成。
考勤系統的組成部分
首先是硬體設施，硬體設施的作用是對打卡數據的校驗。比如WiFi設備，只有連接上公司WiFi的手機才可以打卡成功，有的公司還有藍牙設備，只有進入到藍牙範圍內才可以打卡，這裡就不一一列舉，所有這些都只有一個目的——讓員工的打卡數據更加真實。
其次是中臺系統，包括管理後臺、考勤狀態計算系統、薪資系統等。管理後臺提供員工行為的查詢、考勤規則配置等功能，是監督員工考勤狀態的重要產品。考勤狀態計算系統，名字有點拗口，說白了就是計算員工是否正常上班的系統，輸入的是員工的打卡數據，輸出的是員工的考勤狀態，如：遲到、曠工等，這個在下一節會詳細講到，裡面的計算邏輯很複雜。
還有就是薪資系統，是通過考勤數據來算工資的，在不同公司不一樣，有的直接算到考勤系統中，有的是讀取考勤系統的數據，有的壓根就沒有這個系統。
最後就是跟用戶接觸的前臺頁面，有必備的打卡頁面，提供查詢功能的查詢頁面，還有為彌補忘記打卡而設置的補卡頁面，這三樣是不可或缺的。
所有的這些（可能有些公司接入系統更多），才是一套完整的考勤系統，是不是比你認知中的要複雜？
三、打卡場景其實很複雜
我的朋友琪總曾經就質疑過我：打卡這麼簡單的事情，為什麼你們老是說算不準呢？這可能也是很多人的疑問，這個答案其實很簡單，就是打卡場景過於複雜。
打卡的情況分為很多種，對於小公司來說，可能很簡單，但對於大公司來說，一個產品覆蓋所有打卡場景似乎是不可能的。就考勤的類型來說，大公司的考勤類型可能分為嚴格考勤、彈性考勤、開放考勤要打卡、開放考勤只打一次卡、開放考勤不打卡、內勤外勤等，而上班時間可能還要分為白班、夜班，更有甚者有一個公司的上班時間可能有五六種。
另外還有一個問題需要考慮的就是——加班。比如：一個朝九晚五的同學加班到凌晨，那他走的時候打的卡是算第一天的下班卡，還是算第二天的下班卡呢？
那你可能會說，我把下班卡的判定時間設晚一點，設定到凌晨五點前打卡都算是前一天的下班卡。很好，問題又來了，那如果一個人第一天下班忘打卡，第二天又來得特別早怎麼算？
即使上面問題解決了，也還有一個同步時間問題，我系統不可能實時去算這些，因為全公司數據都跑一邊可能就要半小時甚至更長，在沒有更多資源投入到打卡上面時，只能選擇分時同步，但是這樣會造成信息同步及時的情況，所以這個同步的時間間隔需要設置的很巧妙。
對於這麼複雜的場景，現在產品是如何解決的呢？答案是無法解決，打卡產品無法覆蓋到每一個場景，只能保證覆蓋到儘量多的場景。那些概率極小的場景，就隨他去吧，不必做過多糾結。
四、「防禦式」產品設計
我們在做開發的時候會提到一個名詞——防禦式編程，防禦式編程是一種編程習慣，是指預見在什麼地方可能會出現問題，然後創建一個環境來測試錯誤，當預見的問題出現的時候通知你，並執行一個你指定的損害控制動作，如停止程序執行，將用戶重指向到一個備份的伺服器等。
我們在做考勤產品設計時，也應充分吸收「防禦式」思想，對可能出現的問題做預見，並給出相應的對策，在考勤產品設計中，可預見的風險有以下幾種：
1）考勤制度突然變動
這種情況雖然不常見，但是我確實是遇到過，當時是通宵加班，才趕在考勤制度發布前上線。在這以後，我把考勤產品中的所有內容都做成了後臺可配置項，甚至連錯誤提示語都做了可配置，這樣在下一次這種情況到來時，五分鐘就可以完成所有修改。
2）員工使用不正當方式打卡
這裡涉及到員工偽造打卡環境，代打卡等不正當行為，在產品設計之初，應與開發充分溝通，對此種情況能規避就規避，不能規避就在行為發生時告警，同時，打卡日誌也要儘可能多的保留信息。
3）員工沒有考勤記錄卻宣稱打卡成功
這個是我經常遇到的情況，明明沒有打卡，卻非要說自己打了。對於此類事件，我們需要在將用戶的所有操作都記錄在日誌裡，比如我們的產品在用戶訪問到打卡頁面時，不管有沒有成功，都會做一次記錄，如果沒記錄，說明連頁面都沒訪問到，明顯是來扯皮的。
其實，防禦式產品設計是為自己和用戶負責，而不是不願意背鍋的無奈之舉，這一點需要大家認清楚。
說了這麼多，總結一下，就是考勤產品其實比大家想像中的要複雜，而且沒有完美的解決方案，只能儘量做到更接近完美。
大家有什麼問題或者想法或者質疑，歡迎評論區留言。
本文由 @王撼宇 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議