編輯導讀：用户在使用產品的過程中，少不了會出現操作錯誤的情況，這時容錯機制的重要性就顯現出來了。本文從四個方面圍繞容錯機制進行分析，希望對你有幫助。
子曰：知錯能改，善莫大焉。
產品經理説：且慢！容我想想……
可能很多時候，我們在設計產品時，主要精力投在主流程上，想如何完成閉環，如何節省步驟，提高用户體驗，對於異常情況，就是給出友好的提示和引導。
但產品上線後，我們會發現客户老是因為自己點錯的問題找我們，讓我們改數據庫。我們當然是理直氣壯地拒絕了，但仔細想想，是不是我們的容錯機制做得不夠好。
説説我碰到的三個出錯場景吧。
一、我真的知錯了例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協議。