產品出現了問題，真的只是產品的問題嗎？你是否想到了業務？

眾所周知，B端產品服務于業務。

但回顧最近半年所做需求分析和產品設計過程中，發現一個問題：業務診斷不透徹，做出來的產品投入生產后，總有小細節漏掉或者表面上看起來滿足了需求，實際卻相差甚遠，業務方使用起來并不符合要求。

對于這種情況，作為產品經理在做業務問題診斷的時候，真的診斷清楚了嗎？

下面對業務異常之業務診斷作了一個個人的梳理。

一、出現問題

在《軟件工程》中提到一個專業化的軟件的四個特性中，可依賴性和安全性居于首位。

軟件的穩定是保證業務運轉的基石，但是總有業務阻斷的風險。如電商平臺，交易系統等半分鐘的宕機就會造成巨大的損失。

筆者遇到的業務異常的情況分為以下幾種：

• 交易系統業務全部阻斷，查詢，下單，支付等功能全部崩潰；
• 產線業務整體正常，總有個別產品異常。

1. 第一種情況

對于一個產品汪來說，這無疑是從睡眼朦朧到瞬間清醒的狀態，立刻做好背鍋的準備。

常人的第一反應是系統宕機崩潰。但是，從產品汪的角度，還應該考慮，是否是新上線的功能未測試完全導致對原有功能的影響，亦或者是臨時動了哪個配置參數，導致產品邏輯變化。出現這種情況，肯定是以最快的速度修復系統問題和或者是還原產品配置。

2. 第二種情況

產線整體業務正常，個別產品由于軟件問題，產生異常，這種時候產品經理就要作為一個偵探的角色去還原場景，梳理流程，整體分析此異常出現的原因及修復合理性。

下面就第二種情況作個淺談。

二、業務診斷

業務診斷能力，貫穿所有B端產品的設計，運營，管理等。

不管系統新增需求還是迭代優化，業務診斷是一個產品經理抽象問題的基礎。

全面的業務診斷，抽象出問題，最終提供一個合理有效的產品解決方案；為企業提升運轉效率，經營管理輔助，是一個好的B端產品的價值所在。

當出現業務異常時候，我們應該怎么診斷問題呢？

我們可以從下面兩個步驟來分析：

1. 業務背景調研

1）理解當前業務“目標”

業務背景調研的第一步，理解當前業務目標：這部分業務要實現一個怎么樣的訴求，此業務問題出現在整個業務流轉中的哪個節點，這個節點的目標是什么？

換句話說就是回歸初心。

舉個例子：

短信運營商經常會給用戶發送短信提醒用戶流量使用情況，目的是為了告知用戶剩余流量，提示用戶，防止用戶在不知情的情況下流量用超。

此短信業務的目標便是告知用戶短信使用情況，剩下的流量酌情使用，中國移動在發短信的時候，短信內容顯示了還剩多少MB的流量可使用。

對于用戶來講，平時使用APP或者上網，流量用多少是不知道的，用戶只知道每個月大概會用多少流量，并不容易知道剩下的這些（比如23643MB）流量會用多久。

相比中國移動，中國聯通在發送短信時，加了一句“剩下XX%流量”可使用，這樣不僅直觀，而且達到了發送短信的業務目標。

2）梳理當前業務的“操作流程”

這一點是最坑爹的，有些問題本質上是流程問題，而不是軟件的設計或者BUG。

業務流程涉及到多個業務角色操作，這一步我們應該梳理出當前各業務方現有的操作流程。

3）梳理當前業務“正確”的“產品邏輯”

為了實現以上的目標，梳理原有業務邏輯，和產品設計的“正確”流程。

這里的正確流程不是指絕對正確，是指基于此目的，原有產品邏輯的設計。這個設計現在可能看來不合理，但是因為需要快速上線等各種原因而被一直沿用，此時暴露出了問題，而此刻我們需要理清這個邏輯。

4）分析原有邏輯與業務目標的匹配度

在理清了現有產品邏輯之后，既然業務能正常運轉肯定有它的穩定之處。但是也出現了瑕疵，說明當前產品設計不是最完美的解決方案，存在漏洞。

基于此，我們下面進一步分析。

2. 問題分析維度

1）從用戶場景進行分析

用戶場景在和研發梳理需求的時候，是一種溝通工具，而在分析問題或者產品設計的時候，更是一種思維工具。

產品經理應該設身處地把自己當成一線業務員，或者直接到一線觀看操作業務的流程；某些問題可能并不是因為軟件問題，是業務流程的問題。

對業務員來說，他會通過最方便但可能不是正確的操作流程來達到他的目的，造成這種情況的原因可能是業務員對這個業務的理解脫節，只關注到了他的節點業務，也可能是業務培訓不到位造成。

當產品經理走了一遍全流程，或者進入一線用戶場景調研分析后，便不會容易出現想當然的分析結果。

2）從用戶角色進行分析

分析業務流程中相關的角色，各個角色對應的需求，他要實現的業務目標。

區別于整體業務目標，這里的目標是角色目標，對應崗位上的職責則不同。

3）分析用戶角色之間的協同關系

產品優化方面來說，基于各個角色的業務目標分析，了解他們的訴求之后，在這個角色之間要實現一種協同平衡，實現業務穩定，效率提升，考慮該業務目標的主要受益方是誰，業務需求契合度最高的一方，此時優化方案應該偏向該角色。

對于問題查找來說，可能各個業務角色之間的協同流程都有問題，而不是軟件本身的問題，規范流程，或許會豁然開朗。

這里筆者想起一個例子：

一個產品經理，手上有個正在開發的緊急項目，當到最后一天項目計劃要完成開發工作的時候，產品經理發現有個研發所開發的模塊還沒開發完，項目整體出現延期風險。

研發給出的理由是總經理臨時讓他改一個其他項目的緊急需求，兩邊都是緊急項目，這個研發選擇了先做領導總經理的項目。

這個產品經理氣的不行，和研發吵了起來，去找老板理論；老板讓這個產品經理分析哪里出了問題。

產品經理說總經理不懂先來后到，不知道研發手上有緊急的項目。

老板說，總經理和研發都沒有錯，站在研發的角度，迫于領導的壓力，先做領導的項目；站在總經理的角度，手上的項目確實緊急。

那到底是哪里出了問題？下次遇到同樣場景豈不是還是會出現這種沖突？

老板說，是流程出現了問題。

如果在流程上規避了此種風險，出現臨時資源調度的情況，根據提前制定出的流程，當出現這種情況時，申請走相應的流程，需要各部門審核，這樣就可以提前獲得各方支持協調，而不至于出現項目延期。

現在說來，與其說是流程，不如說是規范，各業務方按照統一規范協同合作。

三、解決方案

1. 問題深度和廣度判斷

不管是業務異常問題，還是產品優化，都需要判斷其是否有改進及迭代的價值。

通過影響的深度和廣度來判斷，深度即出現該業務異常后對整體生產的影響；廣度及出現的頻率和概率等。

而優化即是對此問題作出改進后，是否會對原業務穩定性，效率有提升。判斷的依據最好可以量化。

2. 考慮最快替代方案

在《軟件工程》理論中提到，任何系統，進行更新優化成本都是巨大的。

首先應該想到的是在原有基礎上進行復用：其一是從業務的操作流程上進行優化；其二是從現有系統功能中使用其他功能方式替代。

這種方式不僅成本最低，也是最穩定及快速解決問題的最優方式。

3. 重新開發，成本和可行性分析

如果是需要優化該業務流程或者解決業務異常，需從產品角度重新進行可行性分析及規劃。

結語

以上就是筆者根據實際工作中所遇到的，對業務診斷的思考，作為個人的一個復盤以及記錄。

希望對你有幫助，歡迎指正和討論。

本文由 @謝君翊 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議