国偷自产av一区二区三区,欧美日本东京热一区二区三区

搜索

APP

起點課堂會員權(quán)益

職業(yè)體系課特權(quán)

線下行業(yè)大會特權(quán)

個人IP打造特權(quán)

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導(dǎo)直播

12場專業(yè)技能直播

會員專屬社群

榮耀標識

發(fā)布

注冊 | 登錄

大話PM | 產(chǎn)品設(shè)計，如何搞定業(yè)務(wù)異常？

iamxiarui

2020-02-07

3 評論 4448 瀏覽 29 收藏

21 分鐘

本文作者從自己的實際工作出發(fā)，結(jié)合案例對業(yè)務(wù)異常的情況、預(yù)防方案和解決方案進行了梳理分析和總結(jié)，供大家一同學(xué)習(xí)和參考。

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

針對這種情況與產(chǎn)品同行們交流后發(fā)現(xiàn)，這是一個很常見但又經(jīng)常被產(chǎn)品經(jīng)理忽視的非功能性異常處理。

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

一、前言

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

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

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

同時有關(guān)功能性異常的情況說明，網(wǎng)絡(luò)上也不乏相關(guān)的優(yōu)秀文章，例如在《設(shè)計中的異常：超全面的設(shè)計異常情況和處理方式匯總》一文中，非常全面的羅列了各種情況，足夠充分，本文不再贅述。

相較于“正?！钡漠惓?，本文討論的是極容易被產(chǎn)品團隊忽略又非常至關(guān)重要的業(yè)務(wù)異常。說它被忽略大部分是因為業(yè)務(wù)分析不夠透徹，忽視細節(jié)紕漏百出。說它重要是由于一旦出現(xiàn)此類型異常，輕則會影響業(yè)務(wù)重則導(dǎo)致業(yè)務(wù)鏈斷裂，根本無法滿足用戶需求。

那么到底什么是業(yè)務(wù)異常呢？

二、業(yè)務(wù)異常

2.1 概念說明

在說明什么是業(yè)務(wù)異常之前，我們首先要明白什么是業(yè)務(wù)需求？

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

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

業(yè)務(wù)異常處理是業(yè)務(wù)需求邏輯細化過程中，對業(yè)務(wù)流程異常情形的處理。

2.2 舉例分析

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

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

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

功能正常流程：順利正確注冊/登錄進入 APP 的流程
功能異常流程：如手機號格式錯誤、網(wǎng)絡(luò)中斷等異常
業(yè)務(wù)異常流程：如已有企業(yè)再注冊如何處理等異常

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

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

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

注冊時加錯企業(yè)如何處理
加入企業(yè)后，返回上頁再加入另外的企業(yè)如何處理
加入企業(yè)后再注冊如何處理
加入企業(yè)后再登錄如何處理
已有企業(yè)的用戶重新注冊時如何處理
企業(yè)管理員長時間未批準如何處理

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

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

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

~~注冊時加錯企業(yè)如何處理~~
~~加入企業(yè)后，返回上頁再加入另外的企業(yè)如何處理~~
~~加入企業(yè)后再注冊如何處理~~
~~加入企業(yè)后再登錄如何處理~~
~~已有企業(yè)的用戶重新注冊時如何處理~~
企業(yè)管理員長時間未批準如何處理
加入企業(yè)后再登錄想更換企業(yè)如何處理
加入企業(yè)后通過返回按鈕可以回到首頁是否合理

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

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

2.3 優(yōu)化建議

既然已經(jīng)發(fā)現(xiàn)了場景明確的問題，那么很容易就通過一些簡單的預(yù)防型提示或主動操作來規(guī)避這些問題。

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

具體歸納如下：

企業(yè)管理員長時間未批準如何處理

用戶主動通過類似“提醒管理員”按鈕來快速催辦
用戶主動通過類似“聯(lián)系管理員”按鈕來聯(lián)系企業(yè)管理員
系統(tǒng)默認 24 小時不處理自動觸發(fā)推送消息來提醒企業(yè)管理員

加入企業(yè)后再登錄想更換企業(yè)如何處理

提供類似“重新選取”按鈕來切換企業(yè)
提供類似“等待申請通過時，暫不支持切換企業(yè)”相關(guān)文案說明

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

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

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

三、預(yù)防方案

從第二節(jié)注冊登錄的真實案例中，我們已經(jīng)初步了解到業(yè)務(wù)異常的概念、出現(xiàn)場景及其解決方案。那么在日常產(chǎn)品設(shè)計工作中，產(chǎn)品經(jīng)理們要如何預(yù)防此類異常的發(fā)生呢？

3.1 業(yè)務(wù)自查表

關(guān)于自查表，產(chǎn)品相關(guān)工作者一定不會陌生。它的百度百科定義是：

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

其實簡單來說，自查表就是一份可能出現(xiàn)風(fēng)險的產(chǎn)品問題清單。如果有細心的讀者可以發(fā)現(xiàn)，在本文 2.2 節(jié)中已經(jīng)列出了一個清單，這就是簡單的自查表。

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

那么在業(yè)務(wù)繁多尤其在各業(yè)務(wù)都很復(fù)雜的 ToB 產(chǎn)品中，我們?nèi)绾谓⒁环萃晟魄液侠淼臉I(yè)務(wù)自查表呢？

首先母庸質(zhì)疑的是，我們必須深度了解業(yè)務(wù)需求背后的業(yè)務(wù)場景。并根據(jù)實際的業(yè)務(wù)場景梳理出當前業(yè)務(wù)的流程圖、狀態(tài)機圖等 UML 圖，便于充分理解業(yè)務(wù)。

關(guān)于 UML 圖的說明，可查閱本系列的另一篇文章《大話PM | 產(chǎn)品經(jīng)理必備利器：UML》。如果是一些復(fù)雜且專業(yè)的核心業(yè)務(wù)流程，在必要時還需要業(yè)務(wù)部門配合梳理。

如下圖是某項目申請單的核心流程狀態(tài)機圖：

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

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

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

整體流程圖示如下：

3.2 知識庫

相較于自查表，知識庫是一種覆蓋范圍更全面、內(nèi)容更有組織的知識管理工具，常用于團隊、組織或企業(yè)。在知識庫中，產(chǎn)品團隊可以共同儲存、分享及管理產(chǎn)品相關(guān)文檔。那我們?nèi)绾卫弥R庫來預(yù)防業(yè)務(wù)異常呢？

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

此時如果再次遇到類似的業(yè)務(wù)，產(chǎn)品經(jīng)理只要關(guān)注核心業(yè)務(wù)邏輯異常即可，其他異?？梢灾苯痈鶕?jù)知識庫進行核查。既減少了工作量提高了效率，也能保證不會對常見的異常進行遺漏。

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

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

3.3 頭腦風(fēng)暴

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

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

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

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

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

四、解決方案

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

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

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

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

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

所以說產(chǎn)品經(jīng)理與項目經(jīng)理，雖然有類別差異之分，但在流程管理和方法論的本質(zhì)上都是相通的。

總結(jié)

至此，本文對于業(yè)務(wù)異常及其預(yù)防和解決方案就已經(jīng)全部闡述完畢。

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

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