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

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

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

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

一、判斷是否是偽需求

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

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

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

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

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

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

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

二、查看競品玩法

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

1. 阿里云-云效

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

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

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

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

三、梳理解決方案

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

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

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

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

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

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

oh，此路不通！

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

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

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

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

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

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

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

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

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

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

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

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

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

但，真的這么簡單嗎？

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

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

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

但，真的這么簡單嗎？

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

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

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

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

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

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

1. 流程圖思考法

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

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

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

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

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

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

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