編輯導(dǎo)讀：需求需求，戴在每個產(chǎn)品經(jīng)理頭上的緊箍咒。當(dāng)我們處理完一個又一個的需求后，不禁會問，需求的盡頭是什么？對于這個問題，作者給出了自己的解答，一起來看看吧。

產(chǎn)品經(jīng)理的工作和需求密不可分 ，那么你有沒有思考過一個問題：需求的盡頭是什么？

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

假設(shè)你是R企銷售平臺的產(chǎn)品經(jīng)理，A是R企的產(chǎn)品，并在你負(fù)責(zé)的平臺上銷售?，F(xiàn)在A的產(chǎn)品經(jīng)理找到你，對你提出了一個需求：用戶1通過銷售平臺購買了產(chǎn)品A，不論用戶1是否離職，都不影響訂單的升級續(xù)費等操作，也不影響A的使用。

一、判斷是否是偽需求

首先，我們需要了解產(chǎn)品A的定位和銷售模式。

A是一款項目協(xié)作類的軟件，在銷售平臺上的銷售方式分為兩種：個人和企業(yè)。

• 個人訂單，只有購買人有查看&操作訂單權(quán)限。
• 企業(yè)訂單，購買人以及同企業(yè)的成員都有操作按鈕，也能夠正常使用。

由此我們可以下一個結(jié)論：這是一個偽需求！

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

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

由此，我們抽絲剝繭發(fā)現(xiàn)這是一個真需求！

二、查看競品玩法

確定需求后，我們需要查看頭部的企業(yè)中類似產(chǎn)品的銷售模式，拓寬思路。

1. 阿里云-云效

在阿里云平臺購買云效時，利用企業(yè)id取代用戶id來確認(rèn)訂單信息。因此，如果購買云效的用戶離職，后續(xù)企業(yè)人員仍可使用企業(yè)id進(jìn)行升級、續(xù)費，從根源上避免了離職人轉(zhuǎn)交的需求。

2. 華為云-軟件開發(fā)平臺

軟件開發(fā)平臺并未強(qiáng)制限制購買主體為企業(yè)，是利用用戶id來確認(rèn)訂單信息。

查看購買記錄與軟件開發(fā)平臺頁面，并未發(fā)現(xiàn)訂單轉(zhuǎn)交的按鈕。提交工單詢問后得知，若以個人為主體購買軟件開發(fā)平臺，離職后會導(dǎo)致訂單無法升級續(xù)費，企業(yè)將無法使用軟件開發(fā)平臺。只有將個人賬號做企業(yè)認(rèn)證，或直接以企業(yè)方式購買，無論是否離職都不會對訂單或使用造成影響。顯然，華為云是通過角色來控制權(quán)限，并未做離職人轉(zhuǎn)交的邏輯。

三、梳理解決方案

我們了解了競品玩法后，提出以下三種解決方案。

1. 利用企業(yè)id確認(rèn)訂單信息

在看完競品-阿里云的銷售模式后，你是否覺得醍醐灌頂？我們從起點開始就錯了：既然A是一款項目協(xié)作的軟件，對于此類軟件，支持個人購買明顯不合理。

有了質(zhì)疑，我們再結(jié)合個人購買和企業(yè)購買的場景，仔細(xì)分析區(qū)別。

• S企的采購部購買了產(chǎn)品，但是企業(yè)購買需要上傳公司的營業(yè)執(zhí)照在銷售平臺認(rèn)證，財務(wù)部不愿提供信息或很麻煩。
• 個人工作室買了產(chǎn)品A想二開，無法提供營業(yè)執(zhí)照等信息。
• 這個平臺和產(chǎn)品已經(jīng)運行一段時間了，之前存在一些真實的訂單，我們不方便更改軟件的購買方式。

結(jié)合上述場景，若我們把購買方式貿(mào)然限制為企業(yè)購買，會失去（1）（2）類客戶，并且導(dǎo)致（3）類用戶出問題。華為并未限制個人購買軟件開發(fā)平臺應(yīng)該也是出于這三點的考量。

oh，此路不通！

2. 修復(fù)bug，使企業(yè)內(nèi)非購買人的訂單操作生效

這個方案和軟件開發(fā)平臺的銷售模式相似，即個人訂單個人使用，企業(yè)訂單管理員均可操作。但若A仍保留個人購買的模式，那么個人訂單中，離職后仍可正常使用或升級續(xù)費的需求無法被滿足。

此方案的優(yōu)勢在于改動少，但是不能滿足個人訂單的場景需求。因此也不會采納。

3. 新增個人和企業(yè)訂單的離職人轉(zhuǎn)交功能

優(yōu)點：更貼合用戶習(xí)慣，符合認(rèn)知

缺點：銷售平臺中不僅銷售這一個產(chǎn)品，需要A做特殊的邏輯，銷售平臺的開發(fā)工作量重

優(yōu)點：銷售平臺無需做特殊邏輯，僅提供修改接口即可

缺點：A的開發(fā)工作量重

兩種方案都各有利弊，根據(jù)實際的項目情況，A較之銷售平臺可提供更多的技術(shù)資源，因此選擇方式（2）。

四、冰山露出來的只是一角，潛伏在冰山下的才是一個優(yōu)秀的產(chǎn)品經(jīng)理需要看到的

到現(xiàn)在為止，你是否發(fā)現(xiàn)了流程的不合理處？

1. 企業(yè)訂單中，所有成員都有操作權(quán)限？

顯然不合理，應(yīng)該限制企業(yè)管理員才能以企業(yè)方式購買，如非企業(yè)管理員的用戶只支持個人購買。

但，真的這么簡單嗎？

結(jié)合離職人轉(zhuǎn)交的功能，若企業(yè)管理員將訂單轉(zhuǎn)交給了企業(yè)成員，那么就存在非企業(yè)管理員可以再次以企業(yè)方式購買產(chǎn)品。因此，我們不僅需要在購買時做角色校驗，還需在再次購買和升級續(xù)費時校驗。

2. 個人訂單和企業(yè)訂單的續(xù)費問題

對于A這個產(chǎn)品，我們保留了個人訂單和企業(yè)訂單兩種購買方式，這就涉及到一個場景：第一年C以個人方式購買了產(chǎn)品，第二年C以企業(yè)方式購買，發(fā)現(xiàn)沒有升級續(xù)費的優(yōu)惠價，且A的使用有效期沒有疊加。為了避免這個問題，我們需要對已購買過A的用戶的購買方式做限制，即若C以個人方式購買過產(chǎn)品，后續(xù)C也僅支持個人購買。

但，真的這么簡單嗎？

首先，如何定義已購買的用戶？是提交訂單后，還是付款后算購買。如果提交訂單后就算購買，那么用戶發(fā)現(xiàn)購買方式選擇錯誤取消訂單后，卻發(fā)現(xiàn)無法修改購買方式；如果付款后算購買，那么用戶先提交一個個人訂單不付款，再提交一個企業(yè)訂單后，接著支付兩個訂單。那么就會存在一個用戶既有個人訂單又有企業(yè)訂單，限制無效。好像走進(jìn)了一個死胡同。不妨跳出這兩個方案來看，加一些別的限制組成方案C：付款后就算購買，但是用戶若有未付款訂單，則不允許再提交新的訂單。

其次，結(jié)合離職人轉(zhuǎn)交的功能，針對同一款產(chǎn)品，可能存在一個用戶既有個人訂單又有企業(yè)訂單的情況。比如，用戶1以個人方式購買了A，后續(xù)用戶2將企業(yè)訂單轉(zhuǎn)交給用戶1。因此，再轉(zhuǎn)交前還需加被轉(zhuǎn)交人的校驗邏輯。

五、總結(jié)啟發(fā)

需求的盡頭是什么？還是需求，不過這個需求是從冰山下挖出來的更深層次的需求。

所以我們思考一個需求，他不應(yīng)是一個點，而是一條線，更復(fù)雜的時候是一個面或多個面。

以銷售平臺為例，對于用戶來說，只是在A上增加了一個轉(zhuǎn)交的按鈕，但是銷售平臺的功能一環(huán)扣一環(huán)，關(guān)聯(lián)性非常強(qiáng)，需要產(chǎn)品看到更多，以下兩種方法可以輔助我們思考。

1. 流程圖思考法

當(dāng)我們在設(shè)計離職轉(zhuǎn)交時，可以畫一個簡單的流程圖來幫助我們梳理上游和下游，關(guān)鍵的節(jié)點標(biāo)注所需的數(shù)據(jù)。

比如，訂單結(jié)算需要用戶信息，那么需要銷售平臺和A做用戶打通或用戶綁定，才能支持離職轉(zhuǎn)交操作；訂單結(jié)算需要個人/企業(yè)實名信息，若A未提供，則銷售平臺需要在每一次提交訂單時做實名校驗，增加去實名的跳轉(zhuǎn)引導(dǎo)；轉(zhuǎn)交后可能涉及到退款，而退款僅支持原路退回，那么我們需要在用戶支付時或轉(zhuǎn)交時添加提示。

2. 權(quán)限矩陣思考法

只考慮訂單數(shù)據(jù)流轉(zhuǎn)過程是遠(yuǎn)遠(yuǎn)不夠的，因為訂單還涉及到多個角色，多種狀態(tài)。

不同角色在訂單的不同狀態(tài)下，可操作的按鈕不一致，例如企業(yè)成員僅能在訂單狀態(tài)為生效中時使用產(chǎn)品而無法查看訂單詳情，而企業(yè)管理員應(yīng)從未授權(quán)時就能夠查看訂單詳情了。

本文由 @瑪卡巴卡 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。