圖片來源：poco
定製化的話題筆者覺得是一個非常重要的話題，二個月之前就想寫，只是一直沒有抽出時間。定製化問題是中國SaaS公司面臨的一個普遍性的重大問題，筆者接下來會分三四篇文章分如下幾個部分來說明如何解決定製化的問題。
-
為什麼一定要消滅定製化
-
為什麼可以徹底消滅定製化
-
怎樣消滅定製化，解決定製化過程中的一些原則。
-
剛開始MVP階段，對不同客戶需求沒有全面的把握，怎樣做標準產品
-
如果一家公司已經已經有大量定製化，該怎樣庖丁解牛來做標準化產品
在創業的早期，很多時候我們為了生存，為了拿單，我們在壓力之下做了很多需求，這些需求的設計如果控制的不是很好，比較固化。後面其他的客戶很難使用，要改動也很難，慢慢就成為獨立的版本，慢慢積累下來，定製化就會越來越多。
當定製化越來越多之後，會發現如下幾個問題：
-
多個版本，加上正常的人員流失，維護工作量以及難度越來越大。
-
定製化的版本基本很難持續疊代，用戶體驗很難做得非常好。
-
一些定製化的版本都很難跟著主流版本進行升級，成為頑疾。
-
定製化越多，公司的，無論是產研，售後，還是客戶成功的負擔越來越大，可複製性也變差。當公司營收超過一定金額，比如說5000萬之後，公司的發展變得肉眼可見的越來越慢。
-
定製化做久了，團隊耦合度越來越高，壓力越來越大，團隊會越來越疲憊，氛圍變差。
另外一個問題，就是定製開發的功能不能復用，邊際成本很高，慢慢定製開發的功能算下來可能都是虧錢的。
定製化應該是一個產品可持續發展，一家軟體公司可持續發展的最大罪魁禍首，該問題的解決越早期越好。否則到了後期，整個公司的發展就積重難返了，君不見大量90年代，00年代成立的企業管理軟體公司現在還陷在定製化這個泥潭裡面，動彈不得，發展不了，也不能速死。
我們現在大量名義上的SaaS公司實際上還是在走歷史的老路而已，很難可持續發展。
針對SaaS公司，我一個朋友提了一個標準化產品的ARR指標，我覺得非常正確，大家可以參考，作為公司的一個戰略指標。
當然，團隊沒有標準化產品的能力，接一些項目作為生意，也是無可厚非。
還有一部分，前期團隊能力還不夠，先通過一些大客戶項目活下來，後面升級團隊儘快轉型到標準化產品，追求長期可持續發展也可以（其實前期如果可以找到一個高手即使只是幫忙把把標準化產品的關，就可以節省大量的時間和金錢，越早越好）。
要基於自己團隊的情況做具體的選擇和判斷，但是要知道詩和遠方在哪裡。
第二個問題，為什麼可以徹底消滅定製化，因為很多人都不是專業人士，我儘量先來通俗的類比論證一下。
我們一直聽到一種說法，中國現狀因為有很多的定製化，所以PaaS有其空間，業界似乎都認可PaaS可以來解決SaaS定製化的問題。
那好，我們可不可以先這樣來思考，既然PaaS可以解決定製化的問題，我們再收斂一下，是否可以通過一個垂直的PaaS來解決定製化的問題，比如說HR行業可以做一個垂直的HR PaaS平台，做CRM的可以做一個CRM PaaS平台來解決定製化問題，等等。
好像是可以的，那我們再來深入一下，如果HR領域做一個HR PaaS是可以來解決問題的，那我們在做人力資源管理領域是否還是可以抽象出很多共通的功能，不同公司肯定會有一些不同的需求，我們把可以抽象出的共通功能做成SaaS產品的標準功能，另外通過配置化來解決一些客戶之間不同的需求。
這裡可以打一個比方，比如說不同客戶的需求總和的形狀不一樣，但是總是會有一些重合的地方，這些重合的地方都是產品需要標準化下來的功能，其他不一樣的地方，產品所做的事情是用一個最小的形狀，可以將這些不同的需求形狀裝進去，還要努力做到無法做減法。
這樣說來，我們只需要一個配置型更強的行業SaaS來解決問題.
在這裡，筆者給大家講一個真實的故事，一個花了數十億美金的故事。曾經有一家公司，一家全球性的人力資源的龍頭企業，這家公司在全球近百個國家都有業務。
由於每個國家，國家裡面不同公司的人力資源管理都會有一些差別，特別是一些政策性的功能，比如說休假，考勤，薪酬這塊，所以不同國家都需要開發不同的人力資源系統來支持該地區的業務。
這樣做下來，總公司發現：
-
不同國家之間開發的人力資源系統很多功能還是類似或者重複，開支很大，浪費了很多人力物力。
-
管理起來難度很大，不同國家產研水平不一樣，開發出來的效果差異也很大。
-
不同團隊開發出來的產品的界面以及風格差異很大，不利於公司統一的品牌。
所以這家公司做了一個事情，收購了一家專注於給HR領域做PaaS平台的公司，上面有一些固化的模塊，比如說人事管理，比如說招聘，培訓，績效的一些功能，一些跟國家區域關係很大的政策性功能，比如說福利，薪酬，休假等管理，可以在這個平台上面配置開發，這樣做有幾個好處：
-
很多共通的功能在平台上面固化了，不用重複開發，大幅度的減少整體開發工作量。
-
不同國家開發出來東西風格統一。
在執行的時候，這個平台公司配合協同全球不同國家的產研團隊進行本地化系統的開發和落地。但是在全球化落地的過程中，也帶來了幾個問題：
-
全球化跨語種，跨時區的溝通難度比較大。
-
共通固化的功能，因為考慮不周，很多時候對具體國家的支持還是不是太友好，需要在此基礎上面做一些開發，這些東西的改動基本上控制在PaaS平台團隊手裡，他們統一來進行調整，然後開放給不同的國家。
-
那些需要自己配置開發的模塊，不同國家因為團隊水平不一樣，執行出的結果差異很大，還有些國家還遲遲上不了線。
最後的情況是，一部分國家系統上了線，一部分國家也是遲遲上不了線，當然大部分國家的產研團隊會將鍋讓那家PaaS平台公司來背。
鑑於這個情況，總部覺得固化很多功能，在這個基礎上面滿足全球不同國家的需求還是很難，需要更加的靈活化。另外覺得收購的那個團隊工程師還是太弱，技術上面響應太慢。
因為經費充足，於是又立了一個新項目，招募組建了一個世界頂尖的工程師技術團隊，砸了超過10億美金，去做一個純粹的PaaS平台，裡面沒有多少固化的功能，基本上可以基於配置型開發，整個開發出來的頁面效果也是非常炫酷。
結果是，這個項目做了幾年，花了超過十億美金，然後各個國家基於這個系統去配置開發自己國家的系統，最後似乎沒有什麼國家的系統成功上線了。
如果我們再來復盤一下這個項目，二條路都很難（實際上從來做好的產品從來沒有容易走的道路，因為難所以走一條開始看起來容易的路，後面往往是更難）
如果讓筆者做選擇，筆者覺得第一種方案實際是更好的方案。
實際上在平台上面給的空間越小，成功的可能性越大，否則不同團隊，能力千差萬別，出來的效果肯定很不可控，系統能夠越固化的情況下面滿足客戶的需求，那樣成功率會高很多，而且產品的體驗會更可控。
還有，系統配置型越強，越靈活，交付難度越大，SaaS公司的業務複製型越差。
所以如果筆者決策，筆者會選擇第一種方案的基礎上面可以繼續收斂，還需要做更多的標準化，給不同國家團隊可以發揮的空間越小，越容易成功。這裡面配置型的靈活度把握非常重要，不多不少，恰到好處，說起來容易，實際做起來是非常艱難的。
當然，國內只是面向中國地區的不同客戶，整體難度要比開發一個全球性的產品來說要簡單很多。
做SaaS就要努力解決標準化產品的問題，解決定製化的問題。PaaS有PaaS自己的用途，期待PaaS來解決SaaS的標準化問題筆者感覺有點畫蛇添足，將問題更加複雜化。