編輯導讀：To B產品因為面向的客戶是企業(yè)，其業(yè)務多且復雜，對產品的定制化需求較高。但是作為一個標準化的產品，定制化越多，整合融入的系統(tǒng)、功能越多、系統(tǒng)也越來繁雍笨重。那么，如何在滿足用戶定制化的需求下，避免產品變得笨重呢？本文作者對此給出了一些建議，與你分享。

一、明晰：ToB 的商業(yè)模式

ToB 的全稱是“To Business”，即面向企業(yè)。企業(yè)往往擁有比較復雜的業(yè)務，且個性化很強，通常需要他們自掏腰包來解決自己的困難。這就會要求所購買的產品必須能夠滿足自己的全部需求，產品價格要跟產品價值（滿足需求）相匹配。當 B 端客戶需要你的某個功能時，你可以編各種各樣的理由來搪塞他或者說正在開發(fā)中，但不可以說你沒有，否則會給人一種很不專業(yè)的感覺（側面反映產品不成熟、積累案例少、不能快速響應信息化建設。所以對于大部分 ToB 產品，不存在直接拿 MVP 去賣的情況。因為客戶需要你能給出對某一項業(yè)務完整的解決方案（思路），哪怕是低保真產品原型或 PPT ，都比一個沒做好的 MVP 更具說服力。

問題：定制化越多、功能越繁雍笨重

ToB的產品目前最流行的模式是高度靈活、自由可配置；公司設計研發(fā)出一套所謂能夠涵蓋行業(yè)80%標準化的系統(tǒng)流程，在用戶購買之后采用根據(jù)客戶不同需求做配置，滿足用戶需求。這是一個理想狀態(tài)，現(xiàn)實中，每個企業(yè)、學校、機構的實際業(yè)務不同，使用者關心的業(yè)務和流程不盡相同，就出現(xiàn)很多的需求無法通過配置滿足的現(xiàn)實需求狀況。由此定制化開發(fā)的模式就被各廠商放到了桌面。

定制化開發(fā)過程中會有新的流程、功能被挖掘，這些確實能解決現(xiàn)實行業(yè)中的出現(xiàn)的一些個性化、特殊化的實際問題；但是如果不加辨別，認為只要能夠解決行業(yè)問題的方案就應該納入系統(tǒng)，進而考慮把每個客戶需求進行整合，彌補現(xiàn)有系統(tǒng)的不足，設計研發(fā)出“大而全”的系統(tǒng)，對于想做平臺或者壟斷行業(yè)利潤的廠商，具有巨大的誘惑力。

這樣一來，定制化越多，整合融入的系統(tǒng)、功能越多、系統(tǒng)也越來繁雍笨重；造成系統(tǒng)萬能，卻又沒有什么賣點，對內公司人員怨聲載道，對外給人系統(tǒng)拼拼湊湊的印象，在市場沒有什么競爭力，什么都有，什么都不強，又冗余難用；盡管付出這么大的代價，事實上這樣的系統(tǒng)依然無法覆蓋用戶所有需求，因為你永遠不知道下一個客戶需要什么？

二、系統(tǒng)臃腫問題實質與避免建議

系統(tǒng)臃腫問題實質：

• 多模塊多頁面信息存在大量重復（即有些字段信息沒必要每個地方都顯示，具體看需求）；
• 功能點堆砌，即可能存在需求但是沒有場景化。即有些功能點應該是連貫性和，應該是一步接一步的（如買火車票：提交完訂單后，下一步當然是付款， 你總不能讓這兩個功能分開放吧？）
• 存在部分“低需求功能點”，有些功能點現(xiàn)在基本沒怎么用還留在系統(tǒng)中。
• 系統(tǒng)業(yè)務組織架構、功能權限、數(shù)據(jù)權限等模型不能支撐現(xiàn)在的業(yè)務發(fā)展（這是最蛋疼的，基本是最大系統(tǒng)的問題），導致每次增加新功能點時只能在邏輯上寫死，沒有任何邏輯和程序上的擴展性。

解決問題建議：

先梳理下現(xiàn)在的公司業(yè)務流程和組織架構（找公司各部門負責人多問問）；

根據(jù)上面四點對系統(tǒng)現(xiàn)在的業(yè)務流程、組織架構、功能模塊、功能點進行梳理，找出存在問題的地方，分別列出問題表單和問題點；

拿著問題表單和問題點去調研各個部門的負責人和使用者，看看反饋結果；并順便調研現(xiàn)在的業(yè)務需求和流程場景細節(jié)（多問問未來可能存在的業(yè)務需求-有助于考慮邏輯擴展性和全面性）；

然后根據(jù)調研考慮3套方案：

1. 不動系統(tǒng)組織架構、功能權限、數(shù)據(jù)權限的基礎上，對各個功能模塊考慮解決方案（即如何解決系統(tǒng)現(xiàn)在存在的問題？），然后列出優(yōu)缺點。
2. 重做系統(tǒng)組織架構、功能權限、數(shù)據(jù)權限的基礎上，對各個功能模塊考慮解決方案（即如何解決系統(tǒng)現(xiàn)在存在的問題？），然后列出優(yōu)缺點。（基本上動這個可以考慮重新設計了）
3. 考慮重新設計的方案：從組織架構、功能權限、數(shù)據(jù)權限、業(yè)務流程、各個功能模塊等全方位考慮，以及特殊事件處理方案。（列出優(yōu)缺點）

大體方案方向出來后找研發(fā)和項目評估下大概的難度和工期，不用估計太準，只要個大概就行。然后評估下現(xiàn)在的時間、資源等是否允許？ROI是否值得？

最后找各部門負責人+老板+項目+研發(fā)開會說下事情（最后讓老板老大們決定，你絕對不要做決定，你只給方案不做決定，讓他們選）

PS1：原則就是：看見表象（臃腫和邏輯混亂）—-去調研+梳理+分析出本質原因—-給出多個解決方案并評估優(yōu)缺點—-讓大佬選擇方案。

PS2：要是你自己決定重新做，我敢保證你一定踩無數(shù)坑+背無數(shù)鍋，每天過得跟孫子似的；我們產品應該是功能要做好，鍋要少接。

本文由 @Cloudzhang 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

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