一圖搞定所有中小需求分析和梳理

2 評論 1506 瀏覽 16 收藏 9 分鐘

需求分析是產品經理的日常工作之一,也是基本技能。對于大型需求,一般不會出現太多問題,而對于中小型需求,卻因為過于自信、疏忽等原因容易出現各種小問題,這篇文章,我們嘗試解決一下。

在處理中小型需求時,因為內容過于簡單,所以總自信滿滿,三五兩下就弄完了。

但提交研發后卻發現這個邏輯漏了一點,那個邏輯漏了一點,雖然是細節問題不影響,但也容易拖慢工作進度,還惹研發抱怨。

痛定思痛后,再仔細研讀了一遍楊堃老師的《決勝B端》和徐鋒老師的《有效需求分析》,也結合自己的經驗將過往處理中小需求的全流程整理成一張圖,每次有需求都拿出這張圖對著思考一遍,果然媽媽再也不用擔心我需求梳理遺漏了。

今天把這張SOP圖分享給大家,并詳細說明使用步驟,希望對大家的工作也能起到幫助。

步驟1:還原需求

1)原始需求

直接將對方提到的所有與需求相關的內容CtrlC+V復制到這個框框內,接下來我們圍繞著這個需求拆解就好。

2)提出人、使用人、關聯影響人

直接將提出人的名字和崗位填上,然后將功能直接使用人、關聯影響人填上。

雖然每個公司組織架構都不一樣,總得可以分為這4類:

  1. 業務執行人:通常是一線執行人員,如銷售人員、地推人員等;
  2. 業務管理者:通常是中層管理人員,如銷售主管、地推主管等;
  3. 業務提出人(高層):通常是高層人員,這里可以更籠統地理解為對整個業務有關鍵決策作用,但平時基本不使用系統的人員。如:CEO、業務線負責人等;
  4. 業務協助者:通常是支撐部門,如財務、薪酬等;

3)用戶遇到了什么問題?

我們常常遇到上來就講:“我們需要一個xxx功能”的業務方,但解決方案≠問題,這一步就是督促我們要詢問:“你們遇到了什么問題?”

相信產品經理們道理都懂,但容易犯錯的是:自以為自己懂了。我就曾自作聰明地從解決方案推斷問題,最后發現自己根本就是瞎猜。

所以無論有多了解業務,還是不能自滿,多問問業務具體遇到了什么問題。

4)現在怎么解決?

用戶現狀是如何解決問題的?這不僅能給我們的設計方案一個參考,也能判斷該需求目前的優先級。

下面是一個例子:

步驟2:需求補充

1)是否存在同類問題?

很多時候我們容易陷入“點狀思維”,也就是對方提出一個問題,我們解決一個問題,這樣容易導致我們剛上線完需求,第二個需求緊接著就來了,不僅讓工作效率變低,也更容易讓我們陷入“原型仔”的境地。

最好的辦法是舉一反三,當對方提出自己遇到什么問題時,可以問下對方是否有遇到同類型的其他問題。

例如退款時除了補償金額外,還有沒有其他特殊退出金額的操作?

2)上游關聯者、下游關聯者、協作者、管理者

盤出這幾個角色原因是為了盤出下面的關聯行為。有時候我們遺漏了需求并不是需求本身有問題,而是因為這個改動影響了上下游的另外一個環節。

例如當改動退款功能時,雖然使用人是財務,但是溝通退款細節的客服人員也會被影響到。

這時候我們需要盤出這一整條鏈路的關聯者,并寫出它們在這個鏈路上的工作內容是什么。

這里舉例退款功能:

  • 上游關聯者:客訴人員(溝通退款細節,退款金額)、銷售人員(對接客訴人員,告知對方的退款訴求)
  • 下游關聯者:學生(接收錢款)、會計(支出記錄)、班主任(得知學生退款,更新學生標簽)
  • 管理者:財務主管、客訴主管
  • 協作者:數據人員(相關數據更新)

梳理好后,下一步才是最關鍵的。

3)關聯行為

根據上面梳理的關聯人,捋出這個鏈路上所有的關鍵行為。

1.財務人員根據客訴人員的記錄來操作具體退款金額。

2.學生退款后,班主任會避免與學生再次溝通,在備注中備注該學生已退款。

3.…………………………

例如學生接收錢款、銷售人員提供退款訴求,當然也是關聯行為。但是如果在本次需求中不是那么重要,則可以略過。

步驟3:需求評估

1)是否存在更簡便的解決辦法

挖掘該問題下可能存在的更簡便的解決辦法。

對問題解決思路的窮舉,可以采取金字塔思維、結構化拆解的方式,遵循MECE原則(Mutually、Exclusive、Collectively、Exhaustive,相互獨立、完全窮盡)

2)是否存在關聯的改動功能點

如果我們在設計時只是實現了一個點,那么接下來總會有接二連三的補充需求出現。作為產品經理,需要提前將這些可能的優化點、相關的補充場景都考慮周全,能避免很多緊急需求的出現。

例如剛才的退款功能,關聯改動點梳理后如下:

1.財務人員根據客訴人員的客訴記錄中也應該對相關字段進行記錄更新來操作具體退款金額。

2.學生退款后,班主任處的會避免與學生標簽需自動更新再次溝通,打上“在備注中備注該學生已退款”標簽。

3.……………………

諸如此類,就能將鏈路上所有被關聯到的功能點捋出來,避免剛做了A功能,緊接著發現B功能又要改的局面。

3)評估需求優先級

最后將捋出來的需求方案拆分功能點,劃分優先級就大功告成啦。

總結一下

自從用了SOP,確實感覺工作效率變高,且省了不少思考精力,最重要的是減少了重復返工,避免自己的工作時間又被碎片化切割。

希望今天的分享能對你也有幫助,也歡迎大家留言分享更好用的需求分析法,一起交流和進步。

參考資料:

楊堃-《決勝B端2》

徐鋒-《有效需求分析》

作者:Thea小里,公眾號:小里產品手冊

本文由 @Thea小里 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 好棒呀!

    來自廣東 回復
    1. 感謝認可!

      來自廣東 回復