編輯導讀：需求需求，戴在每個産品經理頭上的緊箍咒。當我們處理完一個又一個的需求後，不禁會問，需求的盡頭是什麼？對于這個問題，作者給出了自己的解答，一起來看看吧。

産品經理的工作和需求密不可分 ，那麼你有沒有思考過一個問題：需求的盡頭是什麼？

不妨來跟我一起找答案吧！

假設你是R企銷售平台的産品經理，A是R企的産品，并在你負責的平台上銷售。現在A的産品經理找到你，對你提出了一個需求：用戶1通過銷售平台購買了産品A，不論用戶1是否離職，都不影響訂單的升級續費等操作，也不影響A的使用。

一、判斷是否是僞需求

首先，我們需要了解産品A的定位和銷售模式。

A是一款項目協作類的軟件，在銷售平台上的銷售方式分為兩種：個人和企業。

• 個人訂單，隻有購買人有查看&操作訂單權限。
• 企業訂單，購買人以及同企業的成員都有操作按鈕，也能夠正常使用。

由此我們可以下一個結論：這是一個僞需求！

但你真的覺得這合理嗎？我們依然從兩種銷售方案的角度分析。

• 我們分析A這個軟件本身，這是一款項目協作類軟件，它的使用場景是多人協作辦公。因此，哪怕是個人購買，實際上卻是公司或項目使用，那麼有可能出現人員離職的情況。所以針對個人訂單，離職轉交是真需求。
• 有操作按鈕一定代表能正常使用嗎？正常使用的定義是什麼？前面的背景說到，銷售平台與A是兩個系統，涉及到兩個系統，那麼底層的數據是否互通就顯得尤為重要。對于兩個系統，正常使用是在銷售平台上操作後，數據也應傳到A上。在實際操作後發現，企業訂單中，隻有購買人的操作是有效的！即非購買人操作後的訂單信息未傳輸到A的數據庫中。

由此，我們抽絲剝繭發現這是一個真需求！

二、查看競品玩法

确定需求後，我們需要查看頭部的企業中類似産品的銷售模式，拓寬思路。

1. 阿裡雲-雲效

在阿裡雲平台購買雲效時，利用企業id取代用戶id來确認訂單信息。因此，如果購買雲效的用戶離職，後續企業人員仍可使用企業id進行升級、續費，從根源上避免了離職人轉交的需求。

2. 華為雲-軟件開發平台

軟件開發平台并未強制限制購買主體為企業，是利用用戶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未提供，則銷售平台需要在每一次提交訂單時做實名校驗，增加去實名的跳轉引導；轉交後可能涉及到退款，而退款僅支持原路退回，那麼我們需要在用戶支付時或轉交時添加提示。

2. 權限矩陣思考法

隻考慮訂單數據流轉過程是遠遠不夠的，因為訂單還涉及到多個角色，多種狀态。

不同角色在訂單的不同狀态下，可操作的按鈕不一緻，例如企業成員僅能在訂單狀态為生效中時使用産品而無法查看訂單詳情，而企業管理員應從未授權時就能夠查看訂單詳情了。

本文由 @瑪卡巴卡 原創發布于人人都是産品經理。未經許可，禁止轉載。

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部