業務問題的診斷:由簡入繁,漸進成長

3 評論 8432 瀏覽 22 收藏 25 分鐘

編輯導語:產品的價值在于解決了用戶的問題。業務問題的診斷,發現用戶的真實問題,撥云見日。本文將從業務相關信息的整理、梳理業務現狀、業務流程圖、總結業務問題這四個方面來進行如何進行業務問題的診斷方法的分享,希望對你有所幫助。

產品的價值在于解決了一定范圍的問題,讓整體的業務運轉、參與角色都能收到因為產品的貢獻而產生的價值或便利。微信解決了熟人之間的溝通問題,支付寶解決了個人、商戶之間的資金流轉問題,滴滴解決了打車的不便和接送任務獲取不易的問題…
【產品經理】業務問題的診斷。由簡入繁,漸進成長

要能較好的設計產品,就得清晰產品要解決的根本問題是什么!

進行業務問題診斷,發掘問題的根本本質。

業務問題的診斷就顯得尤為重要!

一、業務相關信息的整理

要解決問題,就需要先明確問題。

做一款產品,需要有明確的定位及產品規劃,用于指導產品的成長周期。而明確問題,明確業務情況就是進行規劃的先決條件。

要明確問題,就需要找對關鍵的人,問對關鍵的問題。

1. 干系人員的選擇

在人員選擇上,建議按照金字塔的情況選擇,選擇關鍵崗位的人員。一線最優秀的成員多選擇幾個,用于挖清楚他們各自不同優秀的方式;基層管理選擇多名,梳理管理的視角和問題;中高層領導選擇1到2名,主要梳理管理的方式及戰略規劃,明確其達成目標的管理方式。

中高層領導特別需要了解關注的重點,以及通過幾個信息檢核很多方面的歸納方法,明確業務中的關鍵點。

在這個信息溝通中,首先需要做到盡量不主觀引導,盡量記錄真實的信息情況;其次需要就問題本身多發問,為什么,還有什么,什么時間,有哪些人…持續就問題本身去獲取更多信息;再就是信息記錄盡量詳盡,初始不做任何加工。

信息的采集決定信息是否完整,是否存在重大信息的遺漏。在信息整理的基礎上,基于信息整理本身進行信息再補充;也可以基于信息整理,再找相關的業務人員進行信息再溝通。

2. 信息的整理

信息的整理,將信息進行有效整理,是為了厘清業務流程,挖掘業務問題做準備的。信息整理為發現問題服務,推薦用思維導圖進行信息整理和梳理。

思維導圖是一種信息記錄和整理的方式。

一是沒有信息的邏輯順序,優先只是信息的記錄,軟件本身支持信息的擴展;二是信息的順序、前后,都可以依據需要來進行調整,逐步符合真實的需要;三是信息本身是可以進行分層級的,可以對每一個層級進行信息的檢查,從而實現查漏補缺。

另外信息整理也可以根據5W2H(what ,where,when,why,who,)來跟進,檢查信息整理是否完善。

3. 信息的確認和延展

基于信息整理,再和對應溝通的人再確認一下。首先是,明確他說的信息,自己這樣整理理解是和他一致的;其次是,把其他人的信息再溝通一下,看看作為另外的人看其他人的信息是否是一致的;最后是,溝通過程中,再發掘一下是否還有更多信息或者之前沒有想到的地方。

信息的溝通并不是一次性的,需要多次溝通,多次確認。盡量確保信息的完整性、理解一致性。信息需要備份記錄,用于后續的檢查檢核。

信息整理的結果需要包含,業務的流轉,業務中的異常情況,當前的痛點,當前的解決方式。

二、梳理業務現狀

1. 最小閉環,自檢核問題,發現真實的問題

信息的溝通主要達成了解用戶當前的痛點,基于痛點解決問題,最快速實現產品的價值。MVP,最有價值產品設計方案,也是產品實現的重要方略。

在自有的經驗里,常出現的情況是,最常見的是沒有達成最小閉環。

沒有達成最小閉環,也就是當前工序沒有做成該工序的成品。示例,醫藥代理第三方記賬時,銷售代表按照負責關系把具體的貨物銷售金額分攤到具體個人,會存在銷售代表離職、換市場、缺崗等情況。更甚是出現,知道賣出了金額,沒有完整的客戶檔案,也不能確定該客戶由誰負責。

如上述的情況,需要先處理未建立客戶檔案的客戶,并指定給具體人員負責;然后按照離職、換市場、TBA情況處理對應的銷售金額。

實現最小閉環,就需要各個場景處理之后的銷售金額之和應該等于未處理前待分配的總金額,并且每個處理場景的處理方式要完善。其中需要注意細節是,未建檔客戶建檔之后,會不會存在離職、換市場、缺崗的情況。處理流程要通暢完整。

【產品經理】業務問題的診斷。由簡入繁,漸進成長

數據作為檢核,在實際的業務中,可以具體到貨物的流轉、錢的流轉、票的流轉。還可以拆解和互相檢核。例:飲料百貨貨物的發貨、出庫、裝車、運輸、配送、確認、簽收,發貨的數量 = 路上損耗的數量+簽收的數量,其中損耗可能包括出庫錯誤、路上摔壞、臨期退貨等情況。堅持數據的平衡,可以在長業務鏈中檢核業務問題。

2. 業務中出現的問題

在上面過程厘清具體業務的處理方式,并通過數據的一致性檢查業務的完整性。就會逐漸發現問題,以上舉例的部分就需要特別關注“未建檔客戶”的處理。

問題的處理方案,首先可參考當前業務的實現方式,線下是如何解決的,線上也依舊如此處理。次之的方案是,追蹤出現的具體場景,在當時的場景下解決問題的出現,從根本上解決問題。在最后的處理方式就是處理方式上更簡潔有效,做好交互,再出現問題時能夠直接處理。

在這個厘清的過程中,梳理處理的流程,盡可能縮短處理流程,提高易用性。

3. 相關處理人員的期望

在整個處理過程中,要緊著重要問題優先解決。有些業務的現實問題,并非是線上運行就能解決的,盡量達成使用效果,盡量優化交互效果就已足夠。

問題追蹤、調研詢問了具體的人員,在最后的處理效果上,也可以詢問相關人員。對于出現的問題以及想達成的解決方法,在實際的執行人員身上已經有一個初期的答案。詢問清楚,將解決方案實現就已經達成初期的期望。

在這里,若存在需要改變認知,進行創新就需要提前引導。給出新的方法和當前解決方案的優劣勢,然后加以說服,實現產品的品質提升。

基于三次握手原理,在問題整理、問題梳理、解決方案的給出,都需要再和相關的人員進行確認。確定在初期的信息溝通中沒有偏向。

三、業務流程圖

基于了解的信息,按照標準的方式進行梳理,進行專業的輸出便于成果的檢驗和漏洞的避免;降低理解難度,便于和業務確認,和研發講解,和培訓引導,降低初始使用的學習難度。

業務流程圖,就是很好的標準。

1. 對象描述世界

現實世界是復雜的,用計算機語言來描述復雜的事務就需要尋找一種模式、方法來模擬世界的運轉。提取有效信息,應用關鍵信息的有效組合是抽象方式的一種具體表現。

面向對象的思想提供了一個很好的思路,把任何事物都描述為一個對象,如:一輛車,一個訂單,一瓶水,一個節目。對象、對象間關聯、對象生命周期,用相對較為模式化、簡潔化的方式來實際描述復雜的世界及運轉。

在不同的場景下,對象本身的屬性(描述信息)不同。如蘋果,在水果的范疇里,屬性應該包含顏色、口味、香型、單價…在手機的范疇里,屬性應該包含尺寸、內存、機型、版本…

世界的運轉就是對象之間的信息關聯,以及對象本身的生命周期。多瓶水可生成一個訂單;一個訂單的貨物可以由一輛車運送;一輛車運送的過程可以做成一檔直播節目…這就是對象之間的信息關聯。訂單的生成、付款、配送、簽收、退貨、完成、關閉…這就是一個對象的生命周期。簡化按圖表示則如下圖所示:

【產品經理】業務問題的診斷。由簡入繁,漸進成長

按照如上圖展示,用現實案例來進行解釋。

現實生活中,我們會遇到“問題”,問題本身有:什么問題,關于什么,問題的難度,問題的詳細情況,和哪些人相關,可能的后果,發現人,發現時間,負責人,處理緊急度…等一系列的基礎屬性。問題的發現、創建、轉換、解決、關閉,就是“問題”本身的生命周期。“問題”可以轉換成為“需求”,也可以轉換成為“缺陷”,也可以根據“問題”創建“任務”…這就是“問題”的關聯。

2. 參與角色及功能需要

在整個業務運轉下,都是由于人的參與促進整體流轉起來的。各個人員是不同的,但在系統使用中,很多人員的參與情況是一致的,也就是角色的來源。一般的系統參與角色主要包含系統管理員、管理員、執行人員;有根據系統的不同,對具體角色進行細分,常見管理員區分為基層管理與高管;執行人員又區分為銷售、人事、內務等。

厘清一個費用報銷流程,就需要同行人確認、直接主管確認,人事行程確認,審計審查確認,財務確認及打款。其中涉及的角色就有同行人、主管、人事、審計、財務。

  • 同行人是系統中的用戶,可通過通訊錄或者組織架構選擇;主管是組織架構的層級,就需要考慮多層級問題,及主管的主管;
  • 人事是一個崗位,可通過職務或者角色,配置相關信息(基礎檔案、出差信息、行程安排)的查看權限;
  • 審計則是另一個崗位,對于事件的真實發生及發生過程的實際信息進行合理的懷疑和確認,需要有更多數據權限和功能來支撐其決定是否審計通過;
  • 財務則是另一個崗位,需要確認該同事是否有其他的財務問題,根據最后審核通過的結果來進行打款處理。

【產品經理】業務問題的診斷。由簡入繁,漸進成長

報銷審批業務流程(當前為簡化理解,更合適的描述為:功能流程圖)

由簡漸漸進入繁雜了,小伙伴們,別只是看看哈。動動手,你也來試試~我知道很簡單,但是羅馬不是一天建成的呀~這個里面往深里挖掘也不少,后續我肯定給你證明證明 [小嘚瑟]。

在整個系統的實現中,為了確保信息可追溯,需要記錄更多額外的信息。例如:同樣是審計審核的,需要記錄具體由誰處理的,在處理發生錯誤的時候,可以找到誰審計錯誤的,進而挖掘出錯誤的原因以便于根治問題。

互聯網因其信息傳播的快速,在很大程度提升了工作效率。在工作中,難免出現錯誤,需要增加容錯機制,錯誤操作可以撤回。在系統設置上不能無限回退,對于很重要或者易出錯的地方,進行二次確認,也能夠很大程度的減少錯誤的發生。

3. 業務流程流轉

拆解對象的方法描述整個事情,然后通過角色決定對象的流轉及各個角色所需要的功能。當前就需要讓對象在各個角色之間流轉起來,從而模擬業務的實現方式。

按照上面的方法拆解,歸結到功能的粒度,會有很多的功能流程圖,易導致信息過多。業務流程圖是為了說明整個業務的信息流轉情況。(當前情況,缺少產品架構的環節,直接進入業務流程,容易進入細節點,而忽略宏觀點)在現實中,業務是為了說明一種具體模式的整體方案,如平臺加盟模式,如下圖所示,展示類淘寶電商平臺的業務模式。

【產品經理】業務問題的診斷。由簡入繁,漸進成長

如圖所示,展示了用戶、商家、物流、平臺之間的業務關系。確定的是整體的業務流轉,而隨著業務發展,用戶會有更多的體驗要求,需要評價反饋、需要視頻或三維查看商品;商家會有更多需要,多種活動模式的支持,店品質的展示,商品良率、反饋優質的show;物流也會有更多需要,物流信息的及時同步(別再催促),貨物裝車的合理搭配,特殊包裝的物流分揀;平臺也會有更多的需求,商家的管理、假貨的管理、刷單的管理、店家展示公平性的管理等。

先梳理業務模式,依據當前可執行的情況,來決定系統參與的環節。并在分析的模式上,優先確保最小閉環,實現業務能夠完全上線運轉。然后再根據優先級,依次強化各個環節。

本身的梳理過程,也在檢核系統設置的合理性,以及業務運轉的合理性,為后續的問題發掘以及解決問題的優先級提供支撐。

4. 挖掘解決方案

基于以上的情況,可梳理出來具體角色的具體功能點,并按照功能點的執行,檢查是否能夠達到客戶初期期望。這個圖形的整理并不是最終結果,再和客戶溝通的過程中,可以對圖形再做優化,以符合現狀。如實確定要按照圖形描述修改,請深度思考修改的原因,以及可帶來的優勢。

當然,個人的知識面和經驗豐富度都有限。在厘清業務流程的情況,完全可發揮信息收集能力,擴展競品信息,借鑒類似問題的解決方案。同時,也借此明確,競品分析是在明確要達成什么目的的時候來進行競品分析。

同時,人和路途都不是一個人的旅程,可以和其他人討論,可以在產品群里面發問,也可以在各個論壇里吸取營養??偸菚薪鉀Q辦法的,總是解決問題的方式比問題多一點的。

從角色出發,然后抽象對象,之后厘清對象之間的關聯,之后是對象本身的生命周期管理,在之后就是根據業務復雜度拆解成為不同的系統,逐漸豐富整體。這是實際做事的方式,也是當前文章落定的思路。而另外的頂層設計思路才是更好的思路。只是在攀爬梯子的過程中,我們首先看到的是我們當前的處境,更貼切地說,實際上我們忽視了對我們指引最強的“太陽”。要了解更好的方式,記得看接下來的產品定位和產品規劃喲
[手動比心]

5. 業務流程圖的實現注意

業務流程中,最好確定的是角色,畢竟會很少,也是最明確的。只是在角色上,別忽略系統管理員。只有管理員賦予每個使用者權限,才能通暢的走完整個流程。同時,對于各個使用主體可能會有不同方案的部分也可以放置在這里,通過配置來達成不同的細節區分。既有配置項,記得勿忘默認值。

業務流程中的各個對象可能是最難定下來的,存在理解不一致,存在取名不一致,存在細節功能劃分不一致…

業務流程是為了輔助溝通的雙方達成一致理解,可以對對象進行關鍵信息備注,以及擴展的功能細節。示例,下訂單,本身包含信息,需要包含誰在什么時間下的什么商品多少數量的訂單;下訂單涉及的功能有訂單生成、自動取消、付款提醒。這樣表述下來,雖然溝通對方對“下訂單”這個對象不太理解,但是對于這一塊要做什么就很清晰了。( 哈哈哈,不小心被你發現了,這個“下訂單”確實取名有點沒那么嚴謹哈。嘿嘿,不是說來著,對于整體框架搭建的穩,細節出點小差錯并不影響~~~
好的好的,實際上每一個細節的優化都會不自覺的提升質量喲,可是,我還沒改 )

四、總結業務問題

1. 歸納總結問題

終于終于到了理清楚了問題了,并且還初步確定了解決方案?,F在就需要再做歸納和整理,明確切切實實解決問題了。

莫急莫急,步步檢核。去看看前面定的目標:信息整理的結果需要包含,業務的流轉,業務中的異常情況,當前的痛點,當前的解決方式。

一一對照把問題記錄及解決確定下來。然后,再找干系人確定當前的梳理和解決方案是否符合他們的預期。當獲取他們的認可的時候,專業的表現,就是需要各位甲方爸爸簽字畫押一下。哈哈,沒那么嚴重,就是跟他們確認一下。簽字過于正式,那就郵件發送一下,記得提醒人家查閱和和回復喲。

2. 優勢講清楚,壞處說透

問題找出來了,解決方案也明確了,但畢竟還沒有完全落實,就需要業務部門的同事輔助輔助,打打助攻。

在對外交接的時候,需要給業務部門預期,明確排期計劃,明確后續的安排,千萬別少了驗收和試用環節。需要跟業務部門溝通,當前可進入需求池,會有排期計劃的影響,并溝通清楚,后續有進度進展會通知相關部門。有問就有回答,讓業務部門得到付出的“初期”回報。

產品投入使用,還需要經歷驗收、試用的環節。為更好的順利過度,需要做好試用環境準備,萬不可因為其他功能、數據問題等破壞了新功能的驗收,否則整個設計、研發階段的付出就真的很有風險。并且,團隊經歷新功能還未使用就推翻重來的話,會極大的降低對于產品的信任度,也會受到較大的打擊,不利于團隊的和諧。(很不幸,我的團隊在之前經歷了兩個核心模塊的超過三次重構,現如今對于執行這一塊費了老大鼻子勁,才有一點點改觀,過去的很長一段時間,步步有些如履薄冰感覺。哎,可憐如我~)

另一塊需要注意的就是,完全是新功能還好,處理好前值依賴項就好。而若是功能升級,就需要做好數據兼容處理了。

業務問題的診斷,細節拆分理解了業務,發覺了問題,明確了解決方案。之后還需要執行力,對于執行部門來講,執行力就是一切。(哈哈哈,撿個嘴說一下,我現在團隊的執行力還是嘎嘎的,盡管前面偏差了兩三個版本,還是依舊躺過來了。如果沒有這些偏差,或者減少一些這些偏差,是不是團隊的價值會更不一樣呢?!)

作為產品經理,是管理產品一切的人,相比較執行力,正確的方向會更重要??醋‘a品,擬定太陽朝向,實時勤驗證。

 

本文由 @鋼鐵俠戰幻視 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 作者的分享比較實用!謝謝

    回復
  2. 分析的很到位,非常有幫助,感謝作者分享!

    來自廣西 回復
  3. 要明確問題,就需要找對關鍵的人,問對關鍵的問題

    來自陜西 回復