“拒單”在一些電商平臺或者服務(wù)型的平臺是一個(gè)常見的功能，作為產(chǎn)品經(jīng)理，要明白“拒單”這個(gè)需求背后的邏輯，才能更好地進(jìn)行產(chǎn)品設(shè)計(jì)。本文作者對此進(jìn)行了分析，希望對你有幫助。

一個(gè)“產(chǎn)品”或者“需求”會有哪些部分組成呢？

理解這一點(diǎn)對于我們?nèi)プ鲂枨蠓治龊彤a(chǎn)品設(shè)計(jì)非常重要，因?yàn)槲覀兡X子里有全景圖，知道應(yīng)該去思考哪些方面的問題。

而在需求分析和產(chǎn)品設(shè)計(jì)時(shí)，我們要去思考所有相關(guān)部分和環(huán)節(jié)要做的事情。

下面我們就以“拒單”為例，聊一聊當(dāng)需求來敲門時(shí)，如何去全面的思考以及設(shè)計(jì)。

一、“拒單”這個(gè)需求

要先明確的就是在什么場景下產(chǎn)生了這個(gè)需求。

一位保潔阿姨住在通州，突然被派了一個(gè)亦莊的擦玻璃的單子，或者因?yàn)槠渌蛉ゲ涣?，所以需要拒掉這個(gè)單子，拒掉之后，平臺會重新匹配阿姨。

在這個(gè)場景里，阿姨需要能夠表達(dá)自己去不了的意愿，而用戶需要平臺指派阿姨，而平臺的運(yùn)營者為了促成這一單生意讓大家可以滿足各自的需求。這就是在這個(gè)場景下，各方的訴求。

以上就是我們對需求場景的挖掘。

二、對需求做一個(gè)評估

了解的場景之后，我們需要進(jìn)行一個(gè)評估，這個(gè)玩意兒值不值得做，做了會有什么好處，不做會有什么壞處。

任何壞處和好處都跟體量有很大關(guān)系，比如一年就1次場景發(fā)生的概率，那就沒必要評估了，太低頻了，如果頻率很高，我們再去評估這個(gè)場景下需求的意義。

對于有什么壞處，如果阿姨拒不了單，但又去不了，那這一單就可能會異常完結(jié)，在這個(gè)過程中阿姨又不能接新的單子，只能干等著這一單結(jié)束，而用戶也等不到阿姨上門，這一單只能異常完結(jié)；整個(gè)過程中所有人的權(quán)益和體驗(yàn)都得不到保證。

而好處就是壞處的對立面，就不再贅述了，因此，這個(gè)事從場景出發(fā)肯定是要做的。

既然要做，我們再來聊一聊如何從產(chǎn)品層面去實(shí)現(xiàn)這個(gè)需求。

三、對需求做一個(gè)分析

要實(shí)現(xiàn)以上的拒單能力，還有很多問題需要思考，除了用戶、阿姨、運(yùn)營各端的流程以外，還要考慮其他的一些相關(guān)問題。比如：

• 阿姨操作拒單以后的二次派單的觸發(fā)問題
• 阿姨是否有一個(gè)拒單的閾值，頻繁拒單以后是否需要一個(gè)策略去制止這個(gè)過程
• 而用戶是否需要對重新派單做一些干預(yù)或者評價(jià)

等等，圍繞需求的內(nèi)核“拒單”，又會衍生出一系列的問題需要去思考，而每一次思考都可以認(rèn)為是新需求的派生，而新派生的需求就需要有產(chǎn)品或者運(yùn)營等環(huán)節(jié)去承接。

直到不再有新的問題，那么這個(gè)需求才真正分析清楚。

接下來就是針對這些想明白的問題進(jìn)行產(chǎn)品化的設(shè)計(jì)。

四、“拒單”的產(chǎn)品組成

從下圖中可以看出來，任何一個(gè)需求或者功能，都可能由以下這些維度組成：

對于拒單這個(gè)需求同樣也會在以上的各結(jié)構(gòu)層上有所提現(xiàn)。

在前臺展現(xiàn)層上有3個(gè)端需要考慮。

1）用戶端要做哪些

用戶發(fā)起擦玻璃的單子，可以看到平臺關(guān)于指派阿姨的實(shí)況，派單中、派單成功、以及阿姨的情況，這個(gè)跟滴滴打車很類似，需要知道是否已經(jīng)指派了司機(jī)，而司機(jī)也有權(quán)利拒單，然后平臺重新指派；這些都是用戶端要思考的內(nèi)容。

2）阿姨端怎么搞

阿姨需要能夠看到平臺派的這個(gè)單子，并且提供給阿姨一個(gè)功能，比如在訂單后面的一個(gè)“拒單”按鈕，點(diǎn)擊按鈕發(fā)起拒單的操作，第二步可能需要填寫一個(gè)拒單的原因，然后拒單成功，或者不允許拒單，以及其他可能的情況。

3）在后臺支撐端需不需要

這個(gè)要看運(yùn)營體系本身，要不要去干預(yù)整個(gè)“拒單”的過程，比如，是不是需要去審核阿姨的拒單申請，或者時(shí)候去對“拒單”記錄做一個(gè)考核評估，打一個(gè)分，或者給阿姨一個(gè)懲罰等一系列操作。

那這些都意味著工作量，所以需要有對應(yīng)的人員去承接這個(gè)職責(zé)。

在服務(wù)層要想清楚很多問題。

前臺的展現(xiàn)依賴底層服務(wù)端的邏輯實(shí)現(xiàn)，比如阿姨拒單操作就是對訂單發(fā)起的一系列動作，或者是對履約發(fā)起的動作，就需要訂單系統(tǒng)或者履約系統(tǒng)給與支持。

同樣，二次派單又是對派單環(huán)節(jié)提出的任務(wù)請求。

那么，這些底層的服務(wù)需要對以上這些給予支持，比如履約系統(tǒng)需要提供給阿姨端一個(gè)“接口”，來接受阿姨的拒單請求。

同樣，派單服務(wù)也需要給履約系統(tǒng)一個(gè)“接口”或者通路，來接受履約系統(tǒng)發(fā)起的重新派單的申請。

而這個(gè)過程中也可能需要風(fēng)控服務(wù)的參與，來規(guī)避阿姨過高的拒單請求，來決定是否對阿姨做出一些限制。

因此，在服務(wù)端，我們可以用這種方式去思考問題，以獲得“拒單”需要的全部新的支持以及對舊服務(wù)體系帶來的變更的要求。

組合起來走遠(yuǎn)一點(diǎn)看看：

以上相關(guān)環(huán)節(jié)思考的差不多時(shí)，我們就把他們放到一起，整體看一看，演練一下，是否實(shí)現(xiàn)了想要的目標(biāo)。

五、組裝和規(guī)整“拒單”的方案

經(jīng)過上面一系列的操作以后，我們逐漸的看清了這個(gè)“拒單”怎么做，他的影響面有多大，需要哪些環(huán)節(jié)參與進(jìn)來。

想明白了這些問題以后就可以進(jìn)行方案的落地設(shè)計(jì)了。

比如前端把原型畫出來，前后的鏈接把流程畫出來，而各個(gè)邏輯的處理把邏輯流程以及各種規(guī)則做出來。

至此，我們將得到一個(gè)包含了多端原型和流程以及各環(huán)節(jié)邏輯、規(guī)則的可執(zhí)行產(chǎn)品方案。

所以以上當(dāng)需求來敲門時(shí)，從場景出發(fā)經(jīng)過一個(gè)設(shè)計(jì)模式，而得到了我們想要的產(chǎn)品方案。

這個(gè)過程我們需要知道哪些方面需要思考，而每個(gè)思考又需要思考哪些方面。

同時(shí)，本文也回答了一些朋友的問題“面對一個(gè)新需求，我不知道該怎么辦”。

那么，就按部就班地這么辦吧！