本文為PMCAFF作者?iamxiarui?于社區發布

由于疫情影響，在延長的假期中抽空回顧了近一年多來的產品工作。收獲之于發現了一個比較明顯且出現率很高的問題：產品部署上線后，經常會出現未曾預見但又未做處理的異常情況，導致客戶使用體驗很差，團隊也要頻繁返工補漏，很是痛苦。

針對這種情況與產品同行們交流后發現，這是一個很常見但又經常被產品經理忽視的非功能性異常處理。

本文將嘗試用實際工作中的真實案例，來講述如何防范和應對此類問題。既是對自身產品工作的復盤總結，也是與產品同行們的一次分享交流。

一

前言

眾所周知，一款優秀的產品不僅能夠滿足用戶需求、解決用戶剛需，更要在用戶體驗上保持高度的完整性、連貫性和容錯性。此時就需要產品經理們在產品需求確定與設計環節，全面考慮當前產品所面臨的各種使用場景與交互邏輯。

也就是說，產品經理除了需要將產品正常邏輯梳理清楚之外，更需要將不屬于正常流程、不屬于業務范圍或不在產品可控范圍的情況考慮周全。因此，異常設計是產品設計中不可或缺的重要模塊。

需要說明的是，本文不討論類似于網絡中斷、服務器出錯等“正常”的功能性異常。此處之所以稱之為正常，是因為這是產品設計中已經約定俗成的設計模塊，大多數產品團隊都有一套完整且成熟的處理方案。例如下圖所示，各產品都對網絡中斷進行了異常處理。

相較于“正常”的異常，本文討論的是極容易被產品團隊忽略又非常至關重要的業務異常。說它被忽略大部分是因為業務分析不夠透徹，忽視細節紕漏百出。說它重要是由于一旦出現此類型異常，輕則會影響業務重則導致業務鏈斷裂，根本無法滿足用戶需求。

那么到底什么是業務異常呢？

二

業務異常

2.1 概念說明

在說明什么是業務異常之前，我們首先要明白什么是業務需求？

通俗來說，業務需求是基于企業商業目的的實際業務的需求，大多數來源于企業高層或市場業務部門。與功能需求不同的是，業務需求不僅僅關注要實現什么具體功能，更關注此項功能與業務結合后能滿足什么使用場景、帶來什么業務價值。

而在業務需求細化過程中，對各個業務邏輯分支的處理，就要考慮到當前業務流程可能出現的各類場景情形，并為之針對性提供解決方案。于是不難得知：

業務異常處理是業務需求邏輯細化過程中，對業務流程異常情形的處理。

2.2 舉例分析

幾乎所有的互聯網產品中都有登錄注冊模塊，一方面要為用戶建立虛擬身份，用以記錄個人數據；另一方面可以針對用戶屬性提供個性化服務。除此之外在 ToB 產品中，用戶身份可能關聯著某些重要的業務，例如用戶角色、功能權限等。

那么此時，登錄注冊模塊就不僅要考慮要正常登錄/注冊流程中的異常，還要考慮其牽扯到的業務邏輯異常。例如下圖是銷售獲客綜合體驗不錯的加推 APP，其登錄注冊流程就涉及到用戶身份的業務，對企業主體或企業員工進行不同的流程分支。

通過初步分析，在此業務邏輯中需要分別梳理以下三部分：

• 功能正常流程：順利正確注冊/登錄進入 APP 的流程

• 功能異常流程：如手機號格式錯誤、網絡中斷等異常

• 業務異常流程：如已有企業再注冊如何處理等異常

首先功能正常流程如上圖所示，不再重復展示。而功能異常流程，簡單體驗后如下圖所示：

可以看到加推對常見的手機號格式錯誤、網絡中斷與企業名稱重復等異常均做了針對性處理，提示明確且體驗良好。那么本文強調的業務異常呢？

我們先嘗試用一個清單來簡單羅列可能出現的情況：

• 注冊時加錯企業如何處理

• 加入企業后，返回上頁再加入另外的企業如何處理

• 加入企業后再注冊如何處理

• 加入企業后再登錄如何處理

• 已有企業的用戶重新注冊時如何處理

• 企業管理員長時間未批準如何處理

帶著上述問題繼續細致體驗后發現，注冊且提示加入成功后，仍然可以通過返回按鈕返回上級重新選擇企業并成功加入，但無提示或歷史加入記錄。同時加入企業成功后等待通過時，不論是注冊還是登陸都進入等待同意申請頁面，流程合理。最后如果已有企業用戶重新注冊也不會被阻斷，而是會進入選擇企業頁面(如果只有一家企業，則會直接進入)，流程合理，具備流程連貫性。具體如下圖所示：

由此可以看出上述清單中，前五個可能存在的業務異常均已得到妥善的解決。但在體驗過程中還發現，加入企業且等待申請通過時再登錄，此時無法更換企業。而且如果企業管理員一直不處理請求，用戶端也無任何提示。同時在注冊流程走完且加入企業申請后，可以一直通過返回按鈕返回到首頁，且仍然可以走注冊流程，重新修改資料并進行其他企業的申請。

相對來說，這些流程似乎不太合理。于是重新梳理清單后如下：

• 注冊時加錯企業如何處理

• 加入企業后，返回上頁再加入另外的企業如何處理

• 加入企業后再注冊如何處理

• 加入企業后再登錄如何處理

• 已有企業的用戶重新注冊時如何處理

• 企業管理員長時間未批準如何處理

• 加入企業后再登錄想更換企業如何處理

• 加入企業后通過返回按鈕可以回到首頁是否合理

不難發現，清單中未得到解決的問題，就是本文重點關注的很容易被忽略但用戶又有可能會觸發的異常情況。如果此類場景未做處理，在流程中斷的同時也會降低用戶使用體驗。

那么如何解決這些異常流程呢？

2.3 優化建議

既然已經發現了場景明確的問題，那么很容易就通過一些簡單的預防型提示或主動操作來規避這些問題。

例如可行的優化建議有：企業管理員長時間未批準時，用戶可以通過類似“催辦提醒”的按鈕來提醒或聯系企業管理員。系統也可以通過 APP 內消息、短信服務等措施發送至管理員端。其次加錯企業可以通過登錄后頁面中的“重新申請”按鈕，自行重新申請。最后回到首頁的問題可以通過點擊返回按鈕提示“是否重新注冊”來解決。

具體歸納如下：

• 企業管理員長時間未批準如何處理

• • 用戶主動通過類似“提醒管理員”按鈕來快速催辦

  • 用戶主動通過類似“聯系管理員”按鈕來聯系企業管理員

  • 系統默認 24 小時不處理自動觸發推送消息來提醒企業管理員

• 加入企業后再登錄想更換企業如何處理

• • 提供類似“重新選取”按鈕來切換企業

  • 提供類似“等待申請通過時，暫不支持切換企業”相關文案說明

• 加入企業后通過返回按鈕可以回到首頁是否合理

• • 提供“您已申請成功，是否回到主頁”提示框

當然以上優化方案僅為建議可選方案，均存在細節考究。例如主動提醒是否有時間限制？每天允許提醒幾次？默認多長時間自動觸發等細節，不在本文重點范圍，不展開描述。

三

預防方案

從第二節注冊登錄的真實案例中，我們已經初步了解到業務異常的概念、出現場景及其解決方案。那么在日常產品設計工作中，產品經理們要如何預防此類異常的發生呢？

3.1 業務自查表

關于自查表，產品相關工作者一定不會陌生。它的百度百科定義是：

按照系統工程分析方法，在對一個系統進行科學分析的基礎上，找出各種可能存在的風險因素，然后以提問的方式將這些風險因素列成的表格。

其實簡單來說，自查表就是一份可能出現風險的產品問題清單。如果有細心的讀者可以發現，在本文 2.2 節中已經列出了一個清單，這就是簡單的自查表。

值得強調的是，不論是需求分析、交互設計還是業務邏輯方面，自查表既能保證產品設計過程中不遺漏各類細節，也能梳理出詳細的業務流程。所以在預防業務異常時，一份完善詳細的業務自查表必不可少。

那么在業務繁多尤其在各業務都很復雜的 ToB 產品中，我們如何建立一份完善且合理的業務自查表呢？

首先毋庸置疑的是，我們必須深度了解業務需求背后的業務場景。并根據實際的業務場景梳理出當前業務的流程圖、狀態機圖等 UML 圖，便于充分理解業務。

如下圖是某項目申請單的核心流程狀態機圖：

其次在此基礎上，按照業務正向流程逐個排查每一個業務狀態下，各種操作可能出現的情形，并對可能出現的異常情況做好記錄。而且在確保正向已經梳理完畢的同時，也要嘗試檢查反向流程是否也存在問題。

最后一個非常重要的環節，就是帶著吹毛求疵的態度，刻意尋找流程中的漏洞。尤其是一些涉及到商品或金額交易等敏感業務，更要抱著惡意灰產的角色，避免出現被薅羊毛的重大問題。前段時間京東的薅家電事件，可以說是損失重大，最真實的慘痛教訓。

當然在整個自查流程中，不要忘記隨時做好記錄，并最終整理成一份針對性的業務自查表。

整體流程圖示如下：

3.2 知識庫

相較于自查表，知識庫是一種覆蓋范圍更全面、內容更有組織的知識管理工具，常用于團隊、組織或企業。在知識庫中，產品團隊可以共同儲存、分享及管理產品相關文檔。那我們如何利用知識庫來預防業務異常呢？

從 3.1 節我們已經有了針對某項具體業務的單個自查表，那么如果有多個類似業務的自查表，就完全可以總結歸納出此類業務的共性，將它們相同的業務流程及對應的異常進行常規化處理，并形成對應的知識庫。

此時如果再次遇到類似的業務，產品經理只要關注核心業務邏輯異常即可，其他異常可以直接根據知識庫進行核查。既減少了工作量提高了效率，也能保證不會對常見的異常進行遺漏。

例如下圖所示，A 和 B 同樣都是登錄功能，但功能對應的業務不同。此時知識庫可以采取兩者自查表的交集部分，就是登錄業務模塊的共性自查表。

但要注意的是，知識庫是在長期工作中不斷豐富、完善和沉淀的產物。產品團隊不僅要學會利用知識庫，更要利用豐富的產品業務場景來反哺知識庫，這樣才能發揮出其強大的作用。

3.3 頭腦風暴

頭腦風暴是敏捷開發中一項很特別也很有趣的會議，它是指：

在正常融洽和不受任何限制的氣氛中以會議形式進行討論、座談，打破常規，積極思考，暢所欲言，充分發表看法。

也就是說你可以在頭腦風暴會議上充分展開想象，對產品進行討論，并無對錯之分。但要注意的是，在此處強調的頭腦風暴，并非倡導各個產品團隊開展這樣的會議，而是要掌握并利用頭腦風暴的方法，來從不同的角度更加全面的討論問題。

例如在產品需求分析會時，整個產品團隊中的任一個成員都可以對業務邏輯進行非常規的思考。它的作用在于，不同角色成員對待需求及其背后的業務認知可能不一樣，這樣看待問題的角度就會不一樣。重要的是，這些不一樣的觀點往往就是異常發生的場景所在。產品經理可以根據不同的意見或建議，對業務邏輯進行優化或補充。

當然不一定非要在需求會運用這樣的方法，也可以在設計會、每日站會甚至個人每天自我總結時運用，同樣會有意想不到的效果。

四

解決方案

盡管我們在第三節介紹了幾種有效的預防方案，但事實上仍然可能存在極個別異常成為漏網之魚，此時需要我們放平心態去積極解決。

解決問題的首先，一定是根據異常反饋針對性的定位問題，此時業務流程圖依然會起到很大的幫助作用。順利定義問題后，還需要根據異常的影響范圍確定其緊急度。

如果此異常已造成重大業務影響，則必須高優先級解決問題，即刻修復、測試、打包并上線；反之如果是影響度較小或者是一些體驗上的問題，則完全可以規劃到最近的迭代版本中，進行集中優化。

分析并確立好方案后，不論是產品經理個人還是整個產品團隊都應該積極總結復盤，找出問題出現的根本原因，并根據實際情況決定是否豐富知識庫與自查表，以便未來避免同類問題。

說到這里，如果有拿到 PMP 認證的讀者伙伴，很容易明白上文提到的知識庫與自查表，其實就是 PMI 所提倡的風險登記冊與經驗教訓登記冊。但要知道工具并非解決問題的最佳方案，而是在面對不同場景時，合理的使用正確的方案，才是最佳的解決方案。

所以說產品經理與項目經理，雖然有類別差異之分，但在流程管理和方法論的本質上都是相通的。

總結

至此，本文對于業務異常及其預防和解決方案就已經全部闡述完畢。

需要補充強調的是，本文雖然以簡單的登錄注冊模塊為例，但業務異常與產品本身的業務緊密相關，不同的業務可能就帶來不同的異常情形。所以產品經理及其團隊一定要掌握其分析及處理方法，這樣才能在各類業務的處理中得心應手。

此外在很多情況下，業務異常流程可能比正常流程還要多，此時就需要團隊評估實現成本與實現價值，看是否有必要處理全部的異常邏輯。在需求緊急的情況下，仍然建議優先關注核心業務邏輯，但不要忘記做好業務異常的預備處理。

點個“在看”吧

總結

以上是生活随笔為你收集整理的大话PM|产品设计中常被忽视的业务异常的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。