需求分析是產品經理的日常工作之一，也是基本技能。對於大型需求，一般不會出現太多問題，而對於中小型需求，卻因為過於自信、疏忽等原因容易出現各種小問題，這篇文章，我們嘗試解決一下。
在處理中小型需求時，因為內容過於簡單，所以總自信滿滿，三五兩下就弄完了。
但提交研發后卻發現這個邏輯漏了一點，那個邏輯漏了一點，雖然是細節問題不影響，但也容易拖慢工作進度，還惹研發抱怨。
痛定思痛后，再仔細研讀了一遍楊堃老師的《決勝 B 端》和徐鋒老師的《有效需求分析》，也結合自己的經驗將過往處理中小需求的全流程整理成一張圖，每次有需求都拿出這張圖對著思考一遍，果然媽媽再也不用擔心我需求梳理遺漏了。
今天把這張 SOP 圖分享給大家，並詳細說明使用步驟，希望對大家的工作也能起到説明。
步驟 1：還原需求
1）原始需求
直接將對方提到的所有與需求相關的內容 CtrlC+V 複製到這個框框內，接下來我們圍繞著這個需求拆解就好。
2）提出人、使用人、關聯影響人
直接將提出人的名字和崗位填上，然後將功能直接使用人、關聯影響人填上。
雖然每個公司組織架構都不一樣，總得可以分為這 4 類：
業務執行人：通常是一線執行人員，如銷售人員、地推人員等；
業務管理者：通常是中層管理人員，如銷售主管、地推主管等；
業務提出人（高層）：通常是高層人員，這裡可以更籠統地理解為對整個業務有關鍵決策作用，但平時基本不使用系統的人員。如：CEO、業務線負責人等；
業務協助者：通常是支撐部門，如財務、薪酬等；
3）使用者遇到了什麼問題？
我們常常遇到上來就講：“我們需要一個 xxx 功能”的業務方，但解決方案≠問題，這一步就是督促我們要詢問：“你們遇到了什麼問題？”
相信產品經理們道理都懂，但容易犯錯的是：自以為自己懂了。我就曾自作聰明地從解決方案推斷問題，最後發現自己根本就是瞎猜。
所以無論有多了解業務，還是不能自滿，多問問業務具體遇到了什麼問題。
4）現在怎麼解決？
用戶現狀是如何解決問題的？這不僅能給我們的設計方案一個參考，也能判斷該需求目前的優先順序。
下面是一個例子：
步驟 2：需求補充
1）是否存在同類問題？
很多時候我們容易陷入“點狀思維”，也就是對方提出一個問題，我們解決一個問題，這樣容易導致我們剛上線完需求，第二個需求緊接著就來了，不僅讓工作效率變低，也更容易讓我們陷入“原型仔”的境地。
最好的辦法是舉一反三，當對方提出自己遇到什麼問題時，可以問下對方是否有遇到同類型的其他問題。
例如退款時除了補償金額外，還有沒有其他特殊退出金額的操作？
2）上游關聯者、下游關聯者、協作者、管理者
盤出這幾個角色原因是為了盤出下面的關聯行為。有時候我們遺漏了需求並不是需求本身有問題，而是因為這個改動影響了上下游的另外一個環節。
例如當改動退款功能時，雖然使用人是財務，但是溝通退款細節的客服人員也會被影響到。
這時候我們需要盤出這一整條鏈路的關聯者，並寫出它們在這個鏈路上的工作內容是什麼。
這裡舉例退款功能：
上游關聯者：客訴人員（溝通退款細節，退款金額）、銷售人員（對接客訴人員，告知對方的退款訴求）
下游關聯者：學生（接收錢款）、會計（支出記錄）、班主任（得知學生退款，更新學生標籤）
管理者：財務主管、客訴主管
梳理好后，下一步才是最關鍵的。
3）關聯行為
根據上面梳理的關聯人，捋出這個鏈路上所有的關鍵行為。
1. 財務人員根據客訴人員的記錄來操作具體退款金額。
2. 學生退款後，班主任會避免與學生再次溝通，在備註中備註該學生已退款。
例如學生接收錢款、銷售人員提供退款訴求，當然也是關聯行為。但是如果在本次需求中不是那麼重要，則可以略過。
步驟 3：需求評估
1）是否存在更簡便的解決辦法
挖掘該問題下可能存在的更簡便的解決辦法。
對問題解決思路的窮舉，可以採取金字塔思維、結構化拆解的方式，遵循 MECE 原則（Mutually、Exclusive、Collectively、Exhaustive，相互獨立、完全窮盡）
2）是否存在關聯的改動功能點
如果我們在設計時只是實現了一個點，那麼接下來總會有接二連三的補充需求出現。作為產品經理，需要提前將這些可能的優化點、相關的補充場景都考慮周全，能避免很多緊急需求的出現。
例如剛才的退款功能，關聯改動點梳理后如下：
1. 財務人員根據客訴人員的客訴記錄中也應該對相關字段進行記錄更新來操作具體退款金額。
2. 學生退款後，班主任處的會避免與學生標籤需自動更新再次溝通，打上“在備註中備註該學生已退款”標籤。
諸如此類，就能將鏈路上所有被關聯到的功能點捋出來，避免剛做了 A 功能，緊接著發現 B 功能又要改的局面。
3）評估需求優先順序
最後將捋出來的需求方案拆分功能點，劃分優先順序就大功告成啦。
總結一下
自從用了 SOP，確實感覺工作效率變高，且省了不少思考精力，最重要的是減少了重複返工，避免自己的工作時間又被碎片化切割。