很多企業(yè)在選擇SaaS產品的時候，都會從自身需求出發(fā)，要求進行定制開發(fā)。要不要做呢？這是大部分SaaS產品都會遇到的一個問題。本文作者依據(jù)自身工作實踐，從業(yè)務、需求和設計三個方面，對這個問題進行了分析討論，與大家分享。

一方面迫于營收的壓力，接受定制就會有收入；但另一方面，普適性差的功能一旦多了，后續(xù)維護成本就高。

首先，從整個業(yè)務角度考慮

明確自己是做產品還是項目：

【項目】是客戶的；

【產品】是公司自己的。

【項目】滿足特定人群或者使用者需求，更偏向于個性化；

【產品】滿足特定應用場景或者特定行業(yè)領域的需求，更加具有兼容性。

【項目】側重于時間驅動，因為時間就是成本，滿足交付任務即可；

【產品】側重于功能驅動，更注重體驗。

【項目】是以客戶的需求為驅動，按照客戶的需求進行定制開發(fā)；

【產品】是為了滿足市場某一痛點可產生的，對于產品的性能以及快速迭代擴展的要求更高。

【項目】型公司可以賺到錢，但賺的是“人頭錢”。一般項目公司都是按照工時收費，比如X元/人/天，人/天越多，項目總收入越多。項目越多，需要人越多，人數(shù)不夠往往需要進行項目排期，公司的總收入也是和人頭息息相關。一旦項目太多，人數(shù)不夠，營收就陷入瓶頸，項目就處于停滯延期狀態(tài)。

【產品】型公司賺的是產品的使用費或其他增值費，一個很小的團隊，只要產品足夠好，客戶足夠多，營收往往不可估量，人均創(chuàng)造價值遠大于項目型公司。

再從需求本身考慮

SAAS產品客戶越多，收到的需求越多，個性化需求也就越多，那么到底要不要接受客戶的需求？

首先理解客戶提的到底是需求還是方案

需求：我餓了

方案：我想吃饅頭

當客戶說的是“我想吃饅頭了”一定要繼續(xù)追問到具體原因，只有知道需求了，才能判斷到底要不要實現(xiàn)；

然后判斷需求的適用度

通用需求：適用于大部分客戶，可以做到產品里；

假需求：要說服客戶放棄；

真需求，但通用性很差：個性化需求，其他客戶不存在此類需求，要和客戶商討有沒有更好的處理方法。

最后從產品設計層面考慮

同樣通用型需求，實現(xiàn)方案可以是針對單個客戶定制，也可以做成通用型功能。

在考慮的時候，一定盡量往通用型設計方向考慮，我們接定制開發(fā)的目的

是為了積累對行業(yè)的經驗，完善我們的產品適用度。

假如碰到不知道怎么做成通用型產品的時候：

不妨想想把我們的SaaS產品轉化為平臺PasS產品，或加強API能力，避免未來產品升級對定制開發(fā)部分的影響。

是否可以做出可配置的方案來盡量滿足所有人的個性化需求

舉個簡單的例子，我做思拓云投票的時候，這個一個很簡單的在線投票選舉SaaS軟件，遇到客戶提了一個需求：希望用戶投票前必須關注他們的公眾號，以此來增加公眾號的粉絲量。

同時，也提出了解決方案：客戶投票賬戶的ID和他們提供的公眾號賬號相互綁定，每次用戶投票前調用接口去判斷用戶是否關注他們的公眾號。

拿到這個需求，假如說按項目來做，客戶提的方案是可行的，將對應賬戶ID和公眾號賬號寫死在系統(tǒng)里即可。

如果按照產品來看，這種實現(xiàn)方式只適合一個客戶，不滿足SAAS產品設計的初衷。

那到底要不要做？

做，很明顯這是一個通用型需求，加強我們API能力，如果將投票賬戶ID和公眾號綁定功能做成可授權的。每個賬號可自己去授權綁定不同的微信公眾號，這樣即可滿足所有客戶。

那么從項目轉型到產品需要注意什么？

加強API能力，即便定制，也要只做邊界內的定制，邊界外找成熟產品，沒有就找第三方系統(tǒng)集成商做（某大佬建議）。

合適的時機，定制開發(fā)的比例越高，越要盡早轉型做產品開發(fā)，很多項目性公司都是產品開發(fā)出來后，幾年不更新產品，一直在項目中根據(jù)客戶提的需求改產品功能，復用性極差。到后期就是堆人頭，邊際效應遞減，人均產值下降，而且項目開發(fā)組與銷售部門摩擦越來越大，幾千萬營收就出現(xiàn)瓶頸。

產品和項目不是相互獨立的，是相輔相成的關系，產品的開發(fā)是可以通過一個個項目去完成。通過項目不斷迭代開發(fā)，推進產品版本的更新。要注意的是盡量做通用型需求，產品設計也要考慮普適性。