全栈工程师?
嗯.....目前并不是!

“考勤打卡”這個產品,你一點都不簡單

上班打卡是大多數上班狗每天都會做的事情,打卡的方式多種多樣,很多廠商也有很完善的解決方案。這樣一個大家每天習以為常的動作,是不是讓我們都忽略了一件事——考勤打卡實際上是一個to B類型的產品,並且,其背後邏輯一點也不簡單。

一、打卡也要考慮戰略層

做產品的其實都知道,在設計一款產品時,我們首先要考慮的是,公司戰略是如何定位的?我這款產品在公司戰略中處於什麼樣的位置?我的產品可以給用戶帶來什麼價值?

對於打卡這個看似很簡單的產品,其實也要經歷以上思考。

首先我們來看公司層面,一個產品經理需要知道公司處在什麼階段,公司內部的文化是怎麼樣的,然後再決定自己的打卡產品的設計方向。

比如:一個公司處在高速增長階段,企業內部文化極具包容性,對員工的管制少,那打卡產品可以嘗試更多新奇的方向,讓大家要不能從打卡找到樂趣,要不就是在打卡/補卡這種操作上少浪費時間。反之,如果一個公司非常強調對員工的管控,那在打卡上也容不得馬虎,可能需要對打卡範圍和時間嚴格限制,甚至界面也要走嚴肅風。

其次我們要考慮用戶需求,打卡這個東西,是制度催生的需求,而不是員工自己的內在需要。所以,對於員工來說,打卡還是越簡單越好。比如考勤機排隊打卡就沒有用手機軟件打卡舒服,而用手機軟件打卡肯定沒有不打卡讓人心情愉悅。

做為一個產品經理,還是要在用戶需求和公司戰略中找到一種平衡,要在公司認可的情況下做到用戶體驗最好,說起來很簡單,但做起來非常困難,還容易出現兩頭都得罪的情況,需要產品經理好好把握。

二、不止打卡頁面

考勤打卡實際上應該是一整套系統,打卡只是其中的一個部分,可以看做是系統中的數據錄入的頁面,只有與其他系統結合,打卡這個頁面才是具有意義的。而這一整套系統的組成,大致有以下幾個部分組成。

為什麼我會說,“考勤打卡”是一個複雜的產品

考勤系統的組成部分

首先是硬件設施,硬件設施的作用是對打卡數據的校驗。比如WiFi設備,只有連接上公司WiFi的手機才可以打卡成功,有的公司還有藍牙設備,只有進入到藍牙範圍內才可以打卡,這裡就不一一列舉,所有這些都只有一個目的——讓員工的打卡數據更加真實。

其次是中台系統,包括管理後台、考勤狀態計算系統、薪資系統等。管理後台提供員工行為的查詢、考勤規則配置等功能,是監督員工考勤狀態的重要產品。考勤狀態計算系統,名字有點拗口,說白了就是計算員工是否正常上班的系統,輸入的是員工的打卡數據,輸出的是員工的考勤狀態,如:遲到、曠工等,這個在下一節會詳細講到,裡面的計算邏輯很複雜。

還有就是薪資系統,是通過考勤數據來算工資的,在不同公司不一樣,有的直接算到考勤系統中,有的是讀取考勤系統的數據,有的壓根就沒有這個系統。

最後就是跟用戶接觸的前台頁面,有必備的打卡頁面,提供查詢功能的查詢頁面,還有為彌補忘記打卡而設置的補卡頁面,這三樣是不可或缺的。

所有的這些(可能有些公司接入系統更多),才是一套完整的考勤系統,是不是比你認知中的要複雜?

三、打卡場景其實很複雜

我的朋友琪總曾經就質疑過我:打卡這麼簡單的事情,為什麼你們老是說算不準呢?這可能也是很多人的疑問,這個答案其實很簡單,就是打卡場景過於複雜。

打卡的情況分為很多種,對於小公司來說,可能很簡單,但對於大公司來說,一個產品覆蓋所有打卡場景似乎是不可能的。就考勤的類型來說,大公司的考勤類型可能分為嚴格考勤、彈性考勤、開放考勤要打卡、開放考勤只打一次卡、開放考勤不打卡、內勤外勤等,而上班時間可能還要分為白班、夜班,更有甚者有一個公司的上班時間可能有五六種。

另外還有一個問題需要考慮的就是——加班。比如:一個朝九晚五的同學加班到凌晨,那他走的時候打的卡是算第一天的下班卡,還是算第二天的下班卡呢?

那你可能會說,我把下班卡的判定時間設晚一點,設定到凌晨五點前打卡都算是前一天的下班卡。很好,問題又來了,那如果一個人第一天下班忘打卡,第二天又來得特別早怎麼算?

即使上面問題解決了,也還有一個同步時間問題,我系統不可能實時去算這些,因為全公司數據都跑一邊可能就要半小時甚至更長,在沒有更多資源投入到打卡上面時,只能選擇分時同步,但是這樣會造成信息同步及時的情況,所以這個同步的時間間隔需要設置的很巧妙。

對於這麼複雜的場景,現在產品是如何解決的呢?答案是無法解決,打卡產品無法覆蓋到每一個場景,只能保證覆蓋到盡量多的場景。那些概率極小的場景,就隨他去吧,不必做過多糾結。

四、“防禦式”產品設計

我們在做開發的時候會提到一個名詞——防禦式編程,防禦式編程是一種編程習慣,是指預見在什麼地方可能會出現問題,然後創建一個環境來測試錯誤,當預見的問題出現的時候通知你,並執行一個你指定的損害控制動作,如停止程序執行,將用戶重指向到一個備份的服務器等。

我們在做考勤產品設計時,也應充分吸收“防禦式”思想,對可能出現的問題做預見,並給出相應的對策,在考勤產品設計中,可預見的風險有以下幾種:

1)考勤制度突然變動

這種情況雖然不常見,但是我確實是遇到過,當時是通宵加班,才趕在考勤制度發布前上線。在這以後,我把考勤產品中的所有內容都做成了後台可配置項,甚至連錯誤提示語都做了可配置,這樣在下一次這種情況到來時,五分鐘就可以完成所有修改。

2)員工使用不正當方式打卡

這裡涉及到員工偽造打卡環境,代打卡等不正當行為,在產品設計之初,應與開發充分溝通,對此種情況能規避就規避,不能規避就在行為發生時告警,同時,打卡日誌也要儘可能多的保留信息。

3)員工沒有考勤記錄卻宣稱打卡成功

這個是我經常遇到的情況,明明沒有打卡,卻非要說自己打了。對於此類事件,我們需要在將用戶的所有操作都記錄在日誌里,比如我們的產品在用戶訪問到打卡頁面時,不管有沒有成功,都會做一次記錄,如果沒記錄,說明連頁面都沒訪問到,明顯是來扯皮的。

其實,防禦式產品設計是為自己和用戶負責,而不是不願意背鍋的無奈之舉,這一點需要大家認清楚。

說了這麼多,總結一下,就是考勤產品其實比大家想象中的要複雜,而且沒有完美的解決方案,只能盡量做到更接近完美。

大家有什麼問題或者想法或者質疑,歡迎評論區留言。

 

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《“考勤打卡”這個產品,你一點都不簡單》
文章链接:https://www.pmbear.com/archives/9264
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们