本文從真實的業務場景出發，談談如何完成從定製開發到通用性產品方案的確定。
筆者在《To B 行業的 MVP：定製開發》一文中簡單介紹了產品經理如何處理客戶的定製開發需求。也就是在處理客戶提出的需求時，理清以下六個關鍵性問題：
- 是否真正理解客戶提出的新需求；
- 新需求與現有系統的關係；
- 新需求的實現是否會影響現有系統的運行；
- 是否需要把新功能規划到產品的下一代升級中；
- 新功能能否獨立成一個單元模塊；
- 新功能能否獨立成一條產品線。
本文結合以上六個問題，從真實的業務場景出發，談談如何完成從定製開發到通用性產品方案的確定。
一、從客戶需求中歸納出市場需求
在產品圈內有一個老生常談的話題——“如何識別客戶的真實需求”，這個問題最常見的回答思路是：知道客戶是誰，他們要做什麼事，接著才是根據用戶標簽、業務場景等進行具體分析。
做需求分析時，識別客戶真實需求是我們的首要目的，為了實現這個目的，需要解決以上四個問題；在解決問題的過程中，會收集到很多信息；在這些信息中，產品經理不僅僅需要提取出真實需求，還要得出跟市場和公司戰略相關的結論。
這是小白產品經理與資深產品經理最大的區別，資深產品經理能夠時刻保持對市場和公司發展的關註，在接到需求的那一刻，能夠馬上想到自己要驗證什麼問題，所以可以快速回答這個需求能不能做，面臨的難點是什麼。
開始舉例
AD 公司購買了我方的一款財務軟件，客戶在業務交流中反映：影響 AD 公司收支平衡的最大不確定因素是合同賬款統計的滯後性；由於集團無法及時收到子公司的報表彙總，導致報表合併與匯算工作滯後，不能即時反映集團財務狀況；因此希望實現收款類合同賬款的快速統計與彙總功能。
從這些溝通中我們發現，AD 公司項目的需求方主要是財務人員，他們只關註財務問題，尤其希望能快速收到下級部門的數據統計報表。但我們知道，最快速的方法不是讓“報表”與“報表”之間形成聯動，而是把觸角伸到合同的具體數據，讓財務“管”到業務上（業內稱為“業財融合”）。
這就涉及到了商務方面的事情：AD 公司的業務部門並沒有提出合同管理需求，並且該項目在 AD 公司的責任方是財務部，占用的是財務部的預算；我方產品部無法與 AD 公司的業務部門取得聯繫。
針對這次需求討論，我們得出了這些結論（簡單描述）：
- 項目的需求方是財務部，他們提出要做收款合同的財務數據彙總和統計分析功能；
- 業務部門沒有提出合同管理的需求，客戶不會為真正的合同管理模塊買單；
- 合同管理在 ERP 系統內是不可缺少的一個環節；
- 該客戶會是合同管理軟件的潛在客戶（因為他們已經定製了合同管理中最重要的財務彙總和分析模塊）
二、產品規劃vs公司戰略：我們的邊界在哪裡
當公司決定為客戶進行定製開發後，就意味著這項“小型產品”即將成為公司產品線上的一個成員。如何才能提高投入產出比，讓這個“成員”更好地發揮自己的價值呢？
我們需要在設計之初就考慮到這款產品一生的命運，也就是上文說的：是否需要把新功能規划到產品的下一代升級中，新功能能否獨立成一個單元模塊，新功能能否獨立成一條產品線等等。
在規劃產品生命線時，最容易陷入的誤區就是一個勁兒地往裡塞功能，相信很多產品都有體會。每個人的想法都很不錯，也確實會有相應的目標客戶，但一不小心就會把產品設計成一個四不像，甚至是根本沒法做。
既然做加法容易出錯，那就做減法。在考慮到公司整體的產品佈局和市場需求後，要給產品限定一個範圍；比如說，堅決不做某某行業的此類業務，某項功能實現困難，短期內堅決不考慮等等（開個玩笑，只要客戶粑粑錢給到位什麼都做）。
舉例繼續
通過與 AD 公司需求方的討論，我們列出了在定製開發中要實現的功能清單，這裡用 UML 用例圖來表述：
通過這個用例圖可以發現，其實這個定製開發對完整的合同管理軟件來說，相對還是比較簡單的（產品設計角度），連常用控制功能都沒有，只需要掛一條審批流程即可，剩下的關鍵部分就是統計分析。
因為客戶的需求就這麼簡單，“我只想知道截至目前還有多少合同沒有收款，應收、欠收等數據的比例是怎樣的”，“我想通過合同台賬，直接生成財務報表”。
理清客戶的需求併進行公司內部彙報後，BOSS決定借助這次定製開發的機會，做一款通用型合同管理軟件，要能夠覆蓋合同管理的整個生命周期。於是產品部開會討論，做出SWOT分析：
隨後，經過一系列的市場調研、競品分析，我方產品部與開發部討論後做出以下決定：
- 數據庫設計要考慮多種類型合同的信息錄入，考慮不同類型合同的信息組成差異；
- 保證合同財務管理模塊的獨立性，二期項目可能單獨開發項目管理模塊，與財務模塊相關聯；
- 考慮與公司財務產品的數據對接，能夠將合同財務數據直接推送到財務系統，生成財務報表。
這三個決定分別涵蓋 3 個方面：
- 一是數據庫設計，對 ToB 產品來說，能把數據庫設計好，產品就算成功一半；
- 二是產品未來的規劃，盡可能保證已開發部分的獨立性，方便後續進行二次開發；
- 三是與現有產品的結合，使之盡可能成為一種可打包售賣的行業解決方案。
（記筆記！）
三、Do It ！
明確客戶的需求和自身的邊界後，接下來就要開始設計了。
這時還要再考慮最後一種可能性：你家開發需要升級原來的技術方案嗎？前後端框架要更換嗎？市場部門有沒有什麼特殊要求（比如在線申請試用）？
之所以提出這些問題，是因為現在 SaaS 真的太火了，傳統軟件企業想涉足，確實有可能要更換一些技術方案。
關於如何根據需求設計一款產品，本文就不多說了，這類廢話網上比較多。
下一篇我會寫一點關於產品設計不太常見的廢話。
作者：產品路漫漫；微信公眾號：產品路漫漫
本文由 @產品路漫漫 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議