起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識以終為始：如何一步步制定產品方案
本文作者將分享其對制定產品方案思路和總結，enjoy~
作為產品經理，在我們日常工作中，經常會接收到各種各樣的需求。面對這些需求，我們當然首先要弄清楚這需求背后的動因，以便挖出真正的“需求”，隨后才是思考如何解決這個需求。這里我們不討論需求分析的問題，而是重點關注如何制定產品方案。只有產品方案定下了，才能推導出交付開發的產品需求。
當然，對于一些簡單的小需求，是談不上什么產品方案的，因為很清楚地知道做什么改動就可以實現。而我們這里要討論是比較大的需求，所謂大，就是工作量較大，可能是一個全新的需求，而且還需要跨系統協同。在這種情況下，我們對于需求的實現，則需要考慮產品方案的問題。
為什么要考慮產品方案？因為需求是持續產生的，而產品也就需要進行持續迭代。在這種情況下，如果一開始的產品方案沒有經過嚴密的思考過程，而是過于隨意的話，很可能到了產品迭代后期就無法繼續下去了。因為系統變得非常臃腫和混亂，這也是為什么很多系統在經過一兩年的發展就已經變得無法維護了，而系統重構就是在這樣的背景下產生的。
也許大家會問，系統無法維護，這不應該是技術團隊的責任嗎？其實不然， 產品需求是源頭，具體的產品需求已經在很大程度上決定了技術實現方案。如果產品方案和需求沒有把控好，技術實現的混亂是不可你避免的。
廢話不多說，我們直接拿案例說事。
交代一下背景：我們做的是車抵貸業務，由門店業務員對接借款者代為申請借款。現在有一新需求，業務員可能有自己的朋友也有這塊的資源，可以介紹客戶過來借款。而這種需求并不少，因此公司決定將其納入正式業務范疇。為了提高業務效率，提出了讓這些介紹人可以直接在手機APP上代為提交借款申請，申請成功后系統可以自動計算及結算提成的需求。
我們業務員使用的APP叫“單多多”，通常業務員接待借款客戶時，使用這個APP進行申請信息錄入工作。介紹人現在我們稱之為“經紀人”，經紀人也需要在單多多上能錄入自己客戶的申請資料。業務部門希望能快速上線開展業務，經我們產品技術部門簡單評估后提出以臨時方案先行支持業務開展，正式方案的產研工作同步展開的建議。
那么對于臨時方案，具體又該怎么做呢？
經過分析，我們得出此需求的核心要點有如下3點：
- 經紀人需要登錄APP完成借款申請的工作；
- 在系統或訂單上要體現出業務員和經紀間的邀請關系；
- 根據訂單和邀請關系計算出經紀人和業務員在此業務上的提成。
進一步分析得出：
- 登錄APP則需要建立與之相應的訂單系統賬號；
- 賬號在訂單系統中是存在組織機構層級關系的，需要一并設計和構建，而這點恰好可以用于記錄邀請關系，似乎是可以利用的；
- 對于提成結算，因為是全新的邏輯，所以不管如何做都需要定制化開發。
免去過于細化的思考過程，我們直接拿出對應的可選方案。
從上圖列出的3種方案中可以看到，每種方案都各有其優缺點，并不存在完美的臨時方案。在這個時侯，我們就會產生困惑，到底該如何選擇？
說了這么一大堆，中心思想終于該閃亮登場了。解決這個問題的方法就是：以終為始。
為了應對業務需求的緊急性而提出的臨時方案，應該結合后續要實現的正式方案一起考慮。最好的結果是：臨時方案是正式方案的一部分，完成了正式方案的10%的工作。這10%是個虛值，指的是少量的關鍵性工作。
還有一種情況，就是臨時方案無法做到與正式方案統一，可能是完全不同的兩種做法。在這種情況下，那就要求臨時方案的工作量最小，盡量避免系統開發工作，而且后期的轉換成本較低，不要因為臨時方案產生了大量的垃圾數據且而以清理。因為這是真正的臨時方案，過期作廢。
因此，我們先放下手中的問題，繼續向前思考。
對于正式方案，我們很直觀地能想出來，即在訂單系統的用戶體系中接納經紀人這樣的人員角色，讓經紀人可以像公司業務人員那樣在單多多APP上實現系統登錄且能實現業務操作。同時財務系統及薪酬結算系統完成相應的需求對接。貌似并不復雜。
但是要注意，這個時候我們需要問自己一個問題，這個方案合適嗎？有沒有更好的方案？因為作為正式方案，是需要持續使用的，一旦沒有考慮清楚而輕易地對系統做出不合理的改造時，后續的系統迭代將很難進行。
我們首先要確定一個問題：系統邊界。即哪些事在這個系統上是不應該做的？
我們能確定的是：
- 訂單系統是基礎業務系統；
- 經紀人與公司業務人員是兩個體系；
- 經紀人這種屬性對于系統業務流轉不具有普遍性。
細細思考后，我們就能得出這樣的觀點，訂單系統是服務于所有業務人員的業務操作，是簡單而穩定的。而經紀人與邀請人這種關系的特定需求，并不具有普遍性的，甚至可以與公司的業務人員相區隔。如果經紀人需求邏輯在訂單系統中實現，那便是對基礎系統的侵入。讓一個承載基礎服務的業務系統去承擔特殊業務職責，這顯然是不合適的。
基于這樣的思考，我們可以很快地得出新的方案：為經紀人單獨開發一個APP，比如叫“快經紀”，同時讓此APP后臺建立以經紀人為核心的賬戶體系。而邀請人則作為其一屬性關系，且通過訂單系統接口提交申請時，以其關聯的邀請人作為客戶經理參數進行提交。而最終的薪酬計算，可以在經紀人系統內進行，也可以納入統一的薪酬系統中進行。
這種方案下，訂單系統不用做任何改造。而經紀人業務需求則鎖定在以快經紀APP為核心的系統中進行迭代。這樣做使得各個系統的責任邊界則非常清晰，更利于后續各自的產品迭代。
顯然這種方案是更為合適的。用來作為正式方案基本上確定是可行的。那現在我們再回過頭來看之前制定的臨時方案。從前后方案對比可知，3種臨時方案皆無法與正式方案實現統一，實現路徑并不同向。因此可知其為真正的臨時方案，即不可復用。
這種情況下，很顯然，我們需要考慮的就是最簡單的方案，最低成本的系統實現。從這個角度看，顯然，方案3的客戶經理模式是最為合適的。因為系統無任何改造，賬號創建過程也簡單，后續進行數據清理也更為方便。
至此，我們這個話題討論的整個過程便結束了?，F在，我們來總結一下。
制定產品方案的整個過程，我們可以分為如下幾個步驟進行：
- 羅列出所有可選的快速實現（ 臨時）方案。
- 分析實現成本、優缺點，并記錄。
- 思考后續啟動實現的正式方案。
- 還有沒有更好的方案？（分析系統定位及職責，所添加的邏輯是否具有普適性？盡量避免特殊業務邏輯對基礎業務系統的侵入。最終確定最佳的正式實現方案）
- 反推并敲定臨時方案。（考慮前后方案的一致性及延續性，盡量少做沒有價值的臨時工作）
以上便是我對制定產品方案思路和總結，希望對大家有幫助。
本文由 @星思維 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Pixabay，基于 CC0 協議
- 目前還沒評論，等你發揮！
