產品經理必知的7種容錯機制

編輯導讀：使用者在使用產品的過程中，少不了會出現操作錯誤的情況，這時容錯機制的重要性就顯現出來了。本文從四個方面圍繞容錯機制進行分析，希望對你有幫助。

子曰：知錯能改，善莫大焉。

產品經理說：且慢！容我想想……

可能很多時候，我們在設計產品時，主要精力投在主流程上，想如何完成閉環，如何節省步驟，提高使用者體驗，對於異常情況，就是給出友好的提示和引導。

但產品上線後，我們會發現客戶老是因為自己點錯的問題找我們，讓我們改資料庫。我們當然是理直氣壯地拒絕了，但仔細想想，是不是我們的容錯機制做得不夠好。

說說我碰到的三個出錯場景吧。

一、我真的知錯了

例1：脈脈錯過了好友

其實關於容錯我之前沒有好好想過，但有個同事對這塊很重視，我當時還覺得他小題大做，直到我親身經歷了，那次感受特別深。

偶爾會開啟脈脈，就會看到人脈，像下圖有待處理請求，直接點選√或者×就可以，當時我拿左手在操作，想點√，結果手指不夠長，在移動過程中碰到了×，這條就直接消失了，我就想找回來點√，我以為會有一個列表像微信好友一樣，至少歷史請求都在，但是當我點開列表時，發現也只有待處理的，沒有歷史記錄。

我當時還發了一條狀態說為什麼點錯了不讓我改，客服說現在功能是沒有，後面有考慮做。但很久過去了，這個功能還是沒有。

或許產品經理認為，反正那麼多人加你，大部分還不認識，點錯了少加幾個有什麼關係呢。但我就是執著地想加上呢？

例2：入庫單刪不掉

在做醫療SaaS時，這個問題真的是隔三差五就有客戶提。我們當時的設計是，入庫完成後有稽核，稽核透過入庫了就不讓改了，如果有錯，可以把這筆單子出了，再重新錄。

按理說多了稽核環節就能避免80%的出錯率了，2個人都沒看出來？但事實就是，很多人自錄自審，然後還點錯了，又不想再出後入，因為這樣藥品流水就會多2條沒必要的記錄，衛生局會來查，怕說不清。

現在在做wms，去倉庫調查時，這個問題也被提出了。這裡的入庫單都不能倉管手動增，是由採購系統推送過來的，採購員錄錯了，推送了錯誤的幾百條資料過來。後來發現了，又重新建了個採購單，再推送過來，但之前的單子沒有調回，就一直掛在待出庫這邊，倉管員看了特別難受，想刪又刪不掉。

例3：昨天的病歷改不了

病歷規範裡面其實是有這樣的要求，門診病歷當天歸檔後就不能修改了，關於出事後篡改病歷逃避責任這類的新聞想必大家都有聽聞過。

我們當時就按這個標準來的，門診病歷過今天24時就不讓改了，體檢的可以，因為體檢報告一般都要好幾天才能寫完。

但客戶就是還經常要改，有時候是因為同名患者寫錯了，有時候是因為太忙了，才想起昨天有幾份病歷沒來得及寫完。

只要是人就會出錯，小學時鉛筆寫錯了字可以拿橡皮擦，高中時中性筆寫錯了還能用膠帶粘掉，為什麼電子化的系統反倒改個東西那麼難呢？

二、為什麼不讓改

產品經理絕對是背鍋俠，我們也想讓客戶隨便改，但我們不得不全域性地考慮系統啊，改了會不會出更大的問題？

資料對不上怎麼辦？

就像案例2中的入庫單，如果採購系統查到有這條入庫任務，但是在WMS裡面被刪掉了，客戶會不會覺得是因為系統有bug，資料沒有推送過來呢？

還遇到過一個比較大的問題，醫生開完處方後藥房也發藥了，但是患者說不想要了，就把藥退了，醫生想把處方單裡把這個藥刪掉，很合理。但是刪掉後我藥品的發藥和退藥記錄要不要保留呢？保留的話後面查時發藥依據在哪？

萬一刪錯了怎麼辦？

使用者可以因為手滑，點錯了想刪除，那如果又手滑，點錯了刪除，把有用的資料刪除了怎麼辦呢？我們還要給他提供一個像照片一樣的垃圾箱，或者word的回到歷史版本嗎？

肯定不可能啊！雖說刪除都有二次確認，其實三次、四次都沒用，有的人就是閉著眼睛在點，錯了就問能不能復原。

好像關於出錯我們是沒法去避免的，但也不能不去處理，我總結了下7種常用的容錯機制，可以在不同的時候用上，希望可以少背點鍋吧。

三、容錯可以這樣做

1。 直接修改

對於列表頁，我們最常見的按鈕就是新增、檢視、編輯、刪除。這裡的修改不止是隨著時間場景的推移，事務發生變化，比如提成規則發生了變化，需要及時修改。還包括簡單的就是因為輸錯了，想改，比如員工的姓名。

如果說修改的欄位沒有和業務流程掛鉤，也沒有被其他功能引用，那麼事情就很簡單了，隨便改。但B端產品中，欄位往往沒那麼單純，大部分欄位都是有深意的，特別是一些基礎資料，那可以試試下面的辦法。

2。 只可停用，不可刪除

員工資訊是系統中很基礎的資料，很多地方都有用到，特別是統計報表中。

比如醫務統計中會按醫生統計看診量，門診金額，處方金額等，如果把醫生刪除了，有可能統計的資料就不對了，醫務統計處的總金額就比收費統計那邊的金額少了。

這時候可以讓員工只能停用，不能刪除。但這會引發另一個問題，員工太多了，看著礙眼，那可以在進入頁面時用狀態過濾下，當然還有強迫症的客戶就是想刪。

很多時候就算能刪，我們也為了保險起見，讓開發只做邏輯刪除，不做物理刪除，但只能針對重要資料，所有的都做邏輯刪除對資料庫的壓力也是很大的。

3。 調錯與紅衝

調錯與紅衝這個概念在會計裡面是用的最成熟的，記賬憑證會計科目錯誤時，用紅字填寫一張與原始憑證完全相同的記賬憑證，以示登出原記賬憑證，然後用藍字填寫一張正確的記賬憑證，並據以記賬。

我們在WMS裡面也經常會聽到這些名詞：紅領料，紅驗收，就是說領料有問題，退回倉庫；採購來的貨有問題，退回供應商。

同樣系統中有過的痕跡不能直接刪、改，涉及流程有關的，可以用調錯和紅衝，把下游環節的流程給撤回來。

遇到財務系統中結轉時也是如此，如果發現結轉的賬有錯誤，可以反結轉，把賬調回，修正後再重新結轉。

4。 限時修改

這個用的最好的是微信了，我們都發生過這樣的情況，一不小心把一條八卦或吐槽發給了領導或者客戶群。微信可以讓我們在短時內撤回訊息，如果能不顯示“xx撤回了一條訊息”會更好，畢竟還有99%的人好奇撤回的是啥。

案例3中病歷的情況就可以這樣處理，限時還是必須的，但可以不一刀切，可以給醫生緩一緩的時間，比如24小時，72小時內可修改，畢竟過了72小時，大部分人想不起之前的事了吧。

5。 加強稽核

案例2中入庫和出庫，我們都有增加稽核環節，對於管理嚴格的診所來說，還是有會有效果的。但稽核最好還是能搭配調錯與紅衝一起，這樣容錯率能更高一點。

另一種常見的場景就是我們的OA，我們在批假時，如果小於1天，上級領導批就可以了，2-5天需要總監再稽核，5天以上可能又要增加HR，CEO之類的審批了。

當然OA的這麼多審批本質不是為了容錯，但這個例子能說明稽核人越多，流程越長，錯誤率就越低。有時候我們也可以適當增加些環節。

6。 角色控制

系統角色來看肯定有超級管理員，超管擁有一切的許可權，如果一些資料很重要，我們可以把修改和刪除的許可權只開給他。

除了系統裡面的許可權控制，還可以有專門的容錯平臺。我們之前為了方便修改病歷，特地做了一個只能客服使用的病歷修改小系統。如果客戶有問題，客服輸入具體的患者名稱、時間等後可以改該條資料，不提供模糊搜尋，以防惡意操作。

7。 日誌留檔

最後的最後，也是最重要的，所有的重要修改都要留檔，不然有口說不清。

我們就經常碰到客戶投訴，說病歷沒了，客戶檔案沒了，系統有bug。那肯定是不可能的，我們說肯定是你的員工動了。他會說：我把員工都問了一遍了，都說沒動。這不廢話嗎，如果我是員工，我也不想承認。

我們就可以把操作日誌甩他們臉上，xx時間xx人改了xx，把xx改成了xx，然後你們自己去處理吧。

四、總結

犯錯很容易，容錯很難，但不讓人家改又不行，做產品經理好難啊。

但有時候我們想想，其實沒必要那麼執著在系統資料的完整性上，保留好罪證，讓他們願意改就改去吧。如果有個回收站和歷史版本最好，這樣萬一想回來也容易。

所以說了7種容錯機制，最頂級的還是回收站和歷史版本回退，下面讓我們想想，這2個功能該怎麼做呢？

8年+網際網路資深產品經驗，多年B端產品管理經驗。具有多個從0到1的大型B端產品的孵化、重構、迭代經驗；主要教授產業網際網路產品相關的硬核知識點。

本文原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議。