在SaaS行業中，二次定製開發（二開）一直是一個備受爭議的話題。一方面，SaaS產品的標準化是實現規模化和盈利的關鍵，而定製開發往往被視為對這一目標的威脅；另一方面，客戶個性化需求的不斷湧現，又使得二開在實際業務中難以完全避免。
———— / BEGIN / ————
SaaS行業有句名言：“誰做定製開發誰死。”
原因很簡單：SaaS產品標準化是規模化的前提，而規模化才有盈利的可能性，而定製開發是它們的“天敵”。
理論上SaaS應避免定製開發，但現實中完全做到100%標準化幾乎不可能。
今天我們就來聊聊這個話題。
-
SaaS產品為什麼會有二次定製開發（簡稱二開）需求？
-
SaaS產品是否要支援二開？
-
用什麼樣的產品原則或標準判斷哪些接，哪些不接？
為避免對概念認知不同而產生的不必要分歧，我們先給二開下個定義（對齊雙方對概念認知的一致性，也是二開時的前提）。
什麼是二開？
百度百科的定義是：
二次開發，簡單說就是在現有的軟體上進行定製修改，功能的擴充套件，然後達到自己想要的功能，一般來說都不會改變原有系統的核心。
一句話總結就是：在現有標準化產品上，根據某家（或某些）客戶需求定製開發對應功能，以滿足其訴求的，都屬於二開範疇。
二開的需求範圍是廣義的，一切與你現有標準化產品優先順序不匹配，而客戶有強烈訴求的需求，都可定義為二開需求，可能是個性需求，或無法滿足的通用需求。
為什麼會有二開需求？
SaaS產品的多租戶特性，加上客戶在行業、規模、階段、管理理念等方面的差異，導致個性化需求多（一般垂直型SaaS產品，大概5%-10%；通用型約10%-30%），而無法及時解決。
客戶囿於沉沒成本等原因，期望SaaS廠商解決，從而產生二開需求。
SaaS企業是否要支援二開？
如果你問10位產品經理，預計11個都會說：我們不接定製研發，除非面臨新籤卡單、續費流失或大客戶等特殊情況。
當特殊情況變成常態後，二開也就成了常態。
例如：
-
客戶A需要介面來統計員工工時成本以影響續簽決策；
-
客戶B要求調整遲到豁免政策作為新籤條件；
-
客戶C希望隱藏員工出勤情況以促進續費；
-
客戶D則因系統功能不匹配而威脅不續費。
它們都是特殊情況，為避免客戶流失，老闆可能就會同意進行二開。一旦開始，二開需求可能會大量增加。
當二開需求佔用資源過剩，無法解決客戶標準化需求後，客戶成功夥伴就會把標準化需求裹上一層“續費/退費”的皮，讓它們成為二開需求。
產研成本是公司的，續費收益是自己的，誰也不比誰傻半分。
作為產品經理，你能阻塞拒絕客戶續費嗎？你能承擔客戶退費嗎？你能阻塞新籤客戶嗎？不能。
哪怕你再不願意，接受二開需求就是現實。
真就這樣了嗎？
好像還能做點什麼，畢竟作為解決方案的提供者，面對任何問題，都需要有解決方案。
首先（也是最重要的）是制定產品原則。
當一件事或一個問題出現頻次高（如二開需求多），且無法窮舉時，最佳策略就是制定原則。
第一，資源分配原則。
產研資源分配中，二次開發需求佔比不超過30%，以保障絕大多數資源用於標準化產品建設。
理想情況下無需二開定製需求，但現實中往往不可避免。因此，關鍵在於有效控制資源投入，確保二開不成為主戰場，佔用過多產研資源，陷入惡性迴圈，削弱SaaS產品的競爭力。
比如你有20人產研團隊，每月總資源是435人日（按21.75人日/月），每季度1305人日。為控制二開需求，平均每月投入不應超130人日，平均每季度不應超390人日。
第二，二開需求接受原則。
原則1：如果需求具有通用性（對所有客戶有潛在價值），且客戶願意付費，且不會增加額外運營服務成本，那麼即使目前只有某個客戶使用，也可以考慮進行二次開發。
比如客戶希望在現有專案工時填報功能的基礎上，增加專案階段管控、工時填報校驗以及批次填報工時功能；
或客戶希望在現有單人申請加班的基礎上，增加一個連續上班超過6天則不允許申請加班的校驗功能；
它們都屬於通用（含潛在通用性），且是老客戶，且願意付費，而又不增加運維成本。
原則2：對於不願付費的老客戶（簽約2年以上）或新簽約客戶，如果需求可以透過外掛形式實現且不影響其他客戶，且開發工作量不超過15人日，則也可以採取免費、需增購或折扣等方式進行二開。
比如客戶希望有一個獨立的報表，能夠快速檢索並展示員工在上班途中請假或外出時是否有兩次打卡的情況。
或客戶希望定製一個每日情況表，顯示員工每日的工時情況、當月總工時，以及是否連續出勤超過6天等資訊。
它們都屬目標行業老客戶需求，且可用外掛實現，而不影響其他客戶使用，以及開發量在10人日以內。
第三，二開需求優先順序原則。
在符合資源分配原則和需求接受原則的基礎上，需求優先順序規則是：付費二開（通用）> 付費二開（潛在通用） > 標準化需求（通用/高頻/阻塞） > 免費二開（外掛） > 免費二開（功能）> 其他需求（低頻/小體驗）。
什麼叫通用？一是符合標準化產品的能力或其分支擴充套件類能力；二是符合某行業/群體客戶的需求。
比如智慧對班（根據打卡自動匹配出勤班次）、批次安排加班、綜合工時等，都屬於通用型需求；
什麼叫潛在通用？在通用的前提下，增加一個維度：是否現在已有多數（至少5家以上）客戶的需求？是，則通用；否則，則潛在通用。
其次是構建機制流程，確保產品原則有效落地。
先成立需求規劃“私董會”，可從產品、技術、客戶成功、銷售、實施等角色中，選擇3-5人專家團隊，對最終產品規劃負責。
第二是構建二開流程評估機制。從提需求到評估、到訂單、到需求確認、到研發、到交付的全流程。
比如二開需求文件化，確保所有資訊有效記錄；
需求確認郵件化，確保客戶需求與解決方案一致性；
訂單線上化，確保二開訂單付款流程的有效稽核（含技術稽核、行政稽核等）。
———— / E N D / ————
本文來自微信公眾號：產品方法論集散地，作者：邢小作
👇 想第一時間掌握AI動態、工具乾貨？掃碼加入共學交流群，一起偷跑不掉隊！
———— / 推薦閱讀 / ————