馬丁跟你說

作為產品經理，在我們日常工作中，經常會接收到各種各樣的需求。面對這些需求，我們當然首先要弄清楚這需求背後的動因，以便挖出真正的“需求”，隨後才是思考如何解決這個需求。這裡我們不討論需求分析的問題，而是重點關注如何制定產品方案。只有產品方案定下了，才能推導出交付開發的產品需求。

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

為什麼要考慮產品方案？因為需求是持續產生的，而產品也就需要進行持續反覆運算。在這種情況下，如果一開始的產品方案沒有經過嚴密的思考過程，而是過於隨意的話，很可能到了產品反覆運算後期就無法繼續下去了。因為系統變得非常臃腫和混亂，這也是為什麼很多系統在經過一兩年的發展就已經變得無法維護了，而系統重構就是在這樣的背景下產生的。

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

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

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

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

那麼對於臨時方案，具體又該怎麼做呢？

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

1. 經紀人需要登錄APP完成借款申請的工作；
2. 在系統或訂單上要體現出業務員和經紀間的邀請關係；
3. 根據訂單和邀請關係計算出經紀人和業務員在此業務上的提成。

進一步分析得出：

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

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

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

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

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

還有一種情況，就是臨時方案無法做到與正式方案統一，可能是完全不同的兩種做法。在這種情況下，那就要求臨時方案的工作量最小，儘量避免系統開發工作，而且後期的轉換成本較低，不要因為臨時方案產生了大量的垃圾資料且而以清理。因為這是真正的臨時方案，過期作廢。

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

對於正式方案，我們很直觀地能想出來，即在訂單系統的使用者體系中接納經紀人這樣的人員角色，讓經紀人可以像公司業務人員那樣在單多多APP上實現系統登錄且能實現業務操作。同時財務系統及薪酬結算系統完成相應的需求對接。貌似並不複雜。

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

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

我們能確定的是：

1. 訂單系統是基礎業務系統；
2. 經紀人與公司業務人員是兩個體系；
3. 經紀人這種屬性對於系統業務流轉不具有普遍性。

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

基於這樣的思考，我們可以很快地得出新的方案：為經紀人單獨開發一個APP，比如叫“快經紀”，同時讓此APP後臺建立以經紀人為核心的帳戶體系。而邀請人則作為其一屬性關係，且通過訂單系統介面提交申請時，以其關聯的邀請人作為客戶經理參數進行提交。而最終的薪酬計算，可以在經紀人系統內進行，也可以納入統一的薪酬系統中進行。

這種方案下，訂單系統不用做任何改造。而經紀人業務需求則鎖定在以快經紀APP為核心的系統中進行反覆運算。這樣做使得各個系統的責任邊界則非常清晰，更利於後續各自的產品反覆運算。

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

這種情況下，很顯然，我們需要考慮的就是最簡單的方案，最低成本的系統實現。從這個角度看，顯然，方案3的客戶經理模式是最為合適的。因為系統無任何改造，帳號創建過程也簡單，後續進行資料清理也更為方便。

至此，我們這個話題討論的整個過程便結束了。現在，我們來總結一下。

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

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

以上便是我對制定產品方案思路和總結，希望對大家有幫助。