本文作者將分享其對制定產(chǎn)品方案思路和總結(jié)，enjoy~

作為產(chǎn)品經(jīng)理，在我們?nèi)粘９ぷ髦校?jīng)常會接收到各種各樣的需求。面對這些需求，我們當然首先要弄清楚這需求背后的動因，以便挖出真正的“需求”，隨后才是思考如何解決這個需求。這里我們不討論需求分析的問題，而是重點關注如何制定產(chǎn)品方案。只有產(chǎn)品方案定下了，才能推導出交付開發(fā)的產(chǎn)品需求。

當然，對于一些簡單的小需求，是談不上什么產(chǎn)品方案的，因為很清楚地知道做什么改動就可以實現(xiàn)。而我們這里要討論是比較大的需求，所謂大，就是工作量較大，可能是一個全新的需求，而且還需要跨系統(tǒng)協(xié)同。在這種情況下，我們對于需求的實現(xiàn)，則需要考慮產(chǎn)品方案的問題。

為什么要考慮產(chǎn)品方案？因為需求是持續(xù)產(chǎn)生的，而產(chǎn)品也就需要進行持續(xù)迭代。在這種情況下，如果一開始的產(chǎn)品方案沒有經(jīng)過嚴密的思考過程，而是過于隨意的話，很可能到了產(chǎn)品迭代后期就無法繼續(xù)下去了。因為系統(tǒng)變得非常臃腫和混亂，這也是為什么很多系統(tǒng)在經(jīng)過一兩年的發(fā)展就已經(jīng)變得無法維護了，而系統(tǒng)重構就是在這樣的背景下產(chǎn)生的。

也許大家會問，系統(tǒng)無法維護，這不應該是技術團隊的責任嗎？其實不然， 產(chǎn)品需求是源頭，具體的產(chǎn)品需求已經(jīng)在很大程度上決定了技術實現(xiàn)方案。如果產(chǎn)品方案和需求沒有把控好，技術實現(xiàn)的混亂是不可你避免的。

廢話不多說，我們直接拿案例說事。

交代一下背景：我們做的是車抵貸業(yè)務，由門店業(yè)務員對接借款者代為申請借款?，F(xiàn)在有一新需求，業(yè)務員可能有自己的朋友也有這塊的資源，可以介紹客戶過來借款。而這種需求并不少，因此公司決定將其納入正式業(yè)務范疇。為了提高業(yè)務效率，提出了讓這些介紹人可以直接在手機APP上代為提交借款申請，申請成功后系統(tǒng)可以自動計算及結(jié)算提成的需求。

我們業(yè)務員使用的APP叫“單多多”，通常業(yè)務員接待借款客戶時，使用這個APP進行申請信息錄入工作。介紹人現(xiàn)在我們稱之為“經(jīng)紀人”，經(jīng)紀人也需要在單多多上能錄入自己客戶的申請資料。業(yè)務部門希望能快速上線開展業(yè)務，經(jīng)我們產(chǎn)品技術部門簡單評估后提出以臨時方案先行支持業(yè)務開展，正式方案的產(chǎn)研工作同步展開的建議。

那么對于臨時方案，具體又該怎么做呢？

經(jīng)過分析，我們得出此需求的核心要點有如下3點：

1. 經(jīng)紀人需要登錄APP完成借款申請的工作；
2. 在系統(tǒng)或訂單上要體現(xiàn)出業(yè)務員和經(jīng)紀間的邀請關系；
3. 根據(jù)訂單和邀請關系計算出經(jīng)紀人和業(yè)務員在此業(yè)務上的提成。

進一步分析得出：

1. 登錄APP則需要建立與之相應的訂單系統(tǒng)賬號；
2. 賬號在訂單系統(tǒng)中是存在組織機構層級關系的，需要一并設計和構建，而這點恰好可以用于記錄邀請關系，似乎是可以利用的；
3. 對于提成結(jié)算，因為是全新的邏輯，所以不管如何做都需要定制化開發(fā)。

免去過于細化的思考過程，我們直接拿出對應的可選方案。

從上圖列出的3種方案中可以看到，每種方案都各有其優(yōu)缺點，并不存在完美的臨時方案。在這個時侯，我們就會產(chǎn)生困惑，到底該如何選擇？

說了這么一大堆，中心思想終于該閃亮登場了。解決這個問題的方法就是：以終為始。

為了應對業(yè)務需求的緊急性而提出的臨時方案，應該結(jié)合后續(xù)要實現(xiàn)的正式方案一起考慮。最好的結(jié)果是：臨時方案是正式方案的一部分，完成了正式方案的10%的工作。這10%是個虛值，指的是少量的關鍵性工作。

還有一種情況，就是臨時方案無法做到與正式方案統(tǒng)一，可能是完全不同的兩種做法。在這種情況下，那就要求臨時方案的工作量最小，盡量避免系統(tǒng)開發(fā)工作，而且后期的轉(zhuǎn)換成本較低，不要因為臨時方案產(chǎn)生了大量的垃圾數(shù)據(jù)且而以清理。因為這是真正的臨時方案，過期作廢。

因此，我們先放下手中的問題，繼續(xù)向前思考。

對于正式方案，我們很直觀地能想出來，即在訂單系統(tǒng)的用戶體系中接納經(jīng)紀人這樣的人員角色，讓經(jīng)紀人可以像公司業(yè)務人員那樣在單多多APP上實現(xiàn)系統(tǒng)登錄且能實現(xiàn)業(yè)務操作。同時財務系統(tǒng)及薪酬結(jié)算系統(tǒng)完成相應的需求對接。貌似并不復雜。

但是要注意，這個時候我們需要問自己一個問題，這個方案合適嗎？有沒有更好的方案？因為作為正式方案，是需要持續(xù)使用的，一旦沒有考慮清楚而輕易地對系統(tǒng)做出不合理的改造時，后續(xù)的系統(tǒng)迭代將很難進行。

我們首先要確定一個問題：系統(tǒng)邊界。即哪些事在這個系統(tǒng)上是不應該做的？

我們能確定的是：

1. 訂單系統(tǒng)是基礎業(yè)務系統(tǒng)；
2. 經(jīng)紀人與公司業(yè)務人員是兩個體系；
3. 經(jīng)紀人這種屬性對于系統(tǒng)業(yè)務流轉(zhuǎn)不具有普遍性。

細細思考后，我們就能得出這樣的觀點，訂單系統(tǒng)是服務于所有業(yè)務人員的業(yè)務操作，是簡單而穩(wěn)定的。而經(jīng)紀人與邀請人這種關系的特定需求，并不具有普遍性的，甚至可以與公司的業(yè)務人員相區(qū)隔。如果經(jīng)紀人需求邏輯在訂單系統(tǒng)中實現(xiàn)，那便是對基礎系統(tǒng)的侵入。讓一個承載基礎服務的業(yè)務系統(tǒng)去承擔特殊業(yè)務職責，這顯然是不合適的。

基于這樣的思考，我們可以很快地得出新的方案：為經(jīng)紀人單獨開發(fā)一個APP，比如叫“快經(jīng)紀”，同時讓此APP后臺建立以經(jīng)紀人為核心的賬戶體系。而邀請人則作為其一屬性關系，且通過訂單系統(tǒng)接口提交申請時，以其關聯(lián)的邀請人作為客戶經(jīng)理參數(shù)進行提交。而最終的薪酬計算，可以在經(jīng)紀人系統(tǒng)內(nèi)進行，也可以納入統(tǒng)一的薪酬系統(tǒng)中進行。

這種方案下，訂單系統(tǒng)不用做任何改造。而經(jīng)紀人業(yè)務需求則鎖定在以快經(jīng)紀APP為核心的系統(tǒng)中進行迭代。這樣做使得各個系統(tǒng)的責任邊界則非常清晰，更利于后續(xù)各自的產(chǎn)品迭代。

顯然這種方案是更為合適的。用來作為正式方案基本上確定是可行的。那現(xiàn)在我們再回過頭來看之前制定的臨時方案。從前后方案對比可知，3種臨時方案皆無法與正式方案實現(xiàn)統(tǒng)一，實現(xiàn)路徑并不同向。因此可知其為真正的臨時方案，即不可復用。

這種情況下，很顯然，我們需要考慮的就是最簡單的方案，最低成本的系統(tǒng)實現(xiàn)。從這個角度看，顯然，方案3的客戶經(jīng)理模式是最為合適的。因為系統(tǒng)無任何改造，賬號創(chuàng)建過程也簡單，后續(xù)進行數(shù)據(jù)清理也更為方便。

至此，我們這個話題討論的整個過程便結(jié)束了?，F(xiàn)在，我們來總結(jié)一下。

制定產(chǎn)品方案的整個過程，我們可以分為如下幾個步驟進行：

1. 羅列出所有可選的快速實現(xiàn)（ 臨時）方案。
2. 分析實現(xiàn)成本、優(yōu)缺點，并記錄。
3. 思考后續(xù)啟動實現(xiàn)的正式方案。
4. 還有沒有更好的方案？（分析系統(tǒng)定位及職責，所添加的邏輯是否具有普適性？盡量避免特殊業(yè)務邏輯對基礎業(yè)務系統(tǒng)的侵入。最終確定最佳的正式實現(xiàn)方案）
5. 反推并敲定臨時方案。（考慮前后方案的一致性及延續(xù)性，盡量少做沒有價值的臨時工作）

以上便是我對制定產(chǎn)品方案思路和總結(jié)，希望對大家有幫助。

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

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