需求的盡頭是什麼？
編輯導讀：需求需求，戴在每個產品經理頭上的緊箍咒。當我們處理完一個又一個的需求後，不禁會問，需求的盡頭是什麼？對於這個問題，作者給出了自己的解答，一起來看看吧。
產品經理的工作和需求密不可分 ，那麼你有沒有思考過一個問題：需求的盡頭是什麼？
不妨來跟我一起找答案吧！
假設你是R企銷售平台的產品經理，A是R企的產品，並在你負責的平台上銷售。現在A的產品經理找到你，對你提出了一個需求：用户1通過銷售平台購買了產品A，不論用户1是否離職，都不影響訂單的升級續費等操作，也不影響A的使用。
一、判斷是否是偽需求首先，我們需要了解產品A的定位和銷售模式。
A是一款項目協作類的軟件，在銷售平台上的銷售方式分為兩種：個人和企業。
- 個人訂單，只有購買人有查看&操作訂單權限。
- 企業訂單，購買人以及同企業的成員都有操作按鈕，也能夠正常使用。
由此我們可以下一個結論：這是一個偽需求！
但你真的覺得這合理嗎？我們依然從兩種銷售方案的角度分析。
- 我們分析A這個軟件本身，這是一款項目協作類軟件，它的使用場景是多人協作辦公。因此，哪怕是個人購買，實際上卻是公司或項目使用，那麼有可能出現人員離職的情況。所以針對個人訂單，離職轉交是真需求。
- 有操作按鈕一定代表能正常使用嗎？正常使用的定義是什麼？前面的背景説到，銷售平台與A是兩個系統，涉及到兩個系統，那麼底層的數據是否互通就顯得尤為重要。對於兩個系統，正常使用是在銷售平台上操作後，數據也應傳到A上。在實際操作後發現，企業訂單中，只有購買人的操作是有效的！即非購買人操作後的訂單信息未傳輸到A的數據庫中。
由此，我們抽絲剝繭發現這是一個真需求！
二、查看競品玩法確定需求後，我們需要查看頭部的企業中類似產品的銷售模式，拓寬思路。
1. 阿里雲-雲效在阿里雲平台購買雲效時，利用企業id取代用户id來確認訂單信息。因此，如果購買雲效的用户離職，後續企業人員仍可使用企業id進行升級、續費，從根源上避免了離職人轉交的需求。
軟件開發平台並未強制限制購買主體為企業，是利用用户id來確認訂單信息。
查看購買記錄與軟件開發平台頁面，並未發現訂單轉交的按鈕。提交工單詢問後得知，若以個人為主體購買軟件開發平台，離職後會導致訂單無法升級續費，企業將無法使用軟件開發平台。只有將個人賬號做企業認證，或直接以企業方式購買，無論是否離職都不會對訂單或使用造成影響。顯然，華為雲是通過角色來控制權限，並未做離職人轉交的邏輯。
我們瞭解了競品玩法後，提出以下三種解決方案。
1. 利用企業id確認訂單信息在看完競品-阿里雲的銷售模式後，你是否覺得醍醐灌頂？我們從起點開始就錯了：既然A是一款項目協作的軟件，對於此類軟件，支持個人購買明顯不合理。
有了質疑，我們再結合個人購買和企業購買的場景，仔細分析區別。
- S企的採購部購買了產品，但是企業購買需要上傳公司的營業執照在銷售平台認證，財務部不願提供信息或很麻煩。
- 個人工作室買了產品A想二開，無法提供營業執照等信息。
- 這個平台和產品已經運行一段時間了，之前存在一些真實的訂單，我們不方便更改軟件的購買方式。
結合上述場景，若我們把購買方式貿然限制為企業購買，會失去（1）（2）類客户，並且導致（3）類用户出問題。華為並未限制個人購買軟件開發平台應該也是出於這三點的考量。
oh，此路不通！
2. 修復bug，使企業內非購買人的訂單操作生效這個方案和軟件開發平台的銷售模式相似，即個人訂單個人使用，企業訂單管理員均可操作。但若A仍保留個人購買的模式，那麼個人訂單中，離職後仍可正常使用或升級續費的需求無法被滿足。
此方案的優勢在於改動少，但是不能滿足個人訂單的場景需求。因此也不會採納。
3. 新增個人和企業訂單的離職人轉交功能優點：更貼合用户習慣，符合認知
缺點：銷售平台中不僅銷售這一個產品，需要A做特殊的邏輯，銷售平台的開發工作量重
優點：銷售平台無需做特殊邏輯，僅提供修改接口即可
缺點：A的開發工作量重
兩種方案都各有利弊，根據實際的項目情況，A較之銷售平台可提供更多的技術資源，因此選擇方式（2）。
四、冰山露出來的只是一角，潛伏在冰山下的才是一個優秀的產品經理需要看到的
到現在為止，你是否發現了流程的不合理處？
1. 企業訂單中，所有成員都有操作權限？顯然不合理，應該限制企業管理員才能以企業方式購買，如非企業管理員的用户只支持個人購買。
但，真的這麼簡單嗎？
結合離職人轉交的功能，若企業管理員將訂單轉交給了企業成員，那麼就存在非企業管理員可以再次以企業方式購買產品。因此，我們不僅需要在購買時做角色校驗，還需在再次購買和升級續費時校驗。
2. 個人訂單和企業訂單的續費問題對於A這個產品，我們保留了個人訂單和企業訂單兩種購買方式，這就涉及到一個場景：第一年C以個人方式購買了產品，第二年C以企業方式購買，發現沒有升級續費的優惠價，且A的使用有效期沒有疊加。為了避免這個問題，我們需要對已購買過A的用户的購買方式做限制，即若C以個人方式購買過產品，後續C也僅支持個人購買。
但，真的這麼簡單嗎？
首先，如何定義已購買的用户？是提交訂單後，還是付款後算購買。如果提交訂單後就算購買，那麼用户發現購買方式選擇錯誤取消訂單後，卻發現無法修改購買方式；如果付款後算購買，那麼用户先提交一個個人訂單不付款，再提交一個企業訂單後，接着支付兩個訂單。那麼就會存在一個用户既有個人訂單又有企業訂單，限制無效。好像走進了一個死衚衕。不妨跳出這兩個方案來看，加一些別的限制組成方案C：付款後就算購買，但是用户若有未付款訂單，則不允許再提交新的訂單。
其次，結合離職人轉交的功能，針對同一款產品，可能存在一個用户既有個人訂單又有企業訂單的情況。比如，用户1以個人方式購買了A，後續用户2將企業訂單轉交給用户1。因此，再轉交前還需加被轉交人的校驗邏輯。
五、總結啓發需求的盡頭是什麼？還是需求，不過這個需求是從冰山下挖出來的更深層次的需求。
所以我們思考一個需求，他不應是一個點，而是一條線，更復雜的時候是一個面或多個面。
以銷售平台為例，對於用户來説，只是在A上增加了一個轉交的按鈕，但是銷售平台的功能一環扣一環，關聯性非常強，需要產品看到更多，以下兩種方法可以輔助我們思考。
1. 流程圖思考法當我們在設計離職轉交時，可以畫一個簡單的流程圖來幫助我們梳理上游和下游，關鍵的節點標註所需的數據。
比如，訂單結算需要用户信息，那麼需要銷售平台和A做用户打通或用户綁定，才能支持離職轉交操作；訂單結算需要個人/企業實名信息，若A未提供，則銷售平台需要在每一次提交訂單時做實名校驗，增加去實名的跳轉引導；轉交後可能涉及到退款，而退款僅支持原路退回，那麼我們需要在用户支付時或轉交時添加提示。
只考慮訂單數據流轉過程是遠遠不夠的，因為訂單還涉及到多個角色，多種狀態。
不同角色在訂單的不同狀態下，可操作的按鈕不一致，例如企業成員僅能在訂單狀態為生效中時使用產品而無法查看訂單詳情，而企業管理員應從未授權時就能夠查看訂單詳情了。
本文由 @瑪卡巴卡 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。