記一次構建SaaS平臺項目失敗後的反思

記一次構建SaaS平臺項目失敗後的反思

前言： 筆者從2017年起開始着手將公司現有的軟件系統改形成多租戶模式，以下降整個系統的運營成本。但最後這個項目以失敗了結。今天，我將對這個SaaS項目是如何走向失敗，作一個分析和反思。

此前，咱們花費了兩年的時間研發了一套教學系統，考慮到用戶的數量與營運成本，後期決定將這套單體的應用程序改造爲基於SaaS架構的多租戶應用程序。通過短暫的需求分析後，便開始了重構工做。通過一年的艱苦奮鬥，SaaS化的產品不只用戶不能接受，就連咱們本身也沒法成功運營。其功能的完成度差強人意，運營的成本也沒有比單體應用少，反而運營難度上升了。經過一段時間的整理與思考，總結了這一次SaaS化平臺失敗的緣由。

1、不務實的需求

一個成功的SaaS產品，須要有足夠多的用戶需求樣本數據以及對這些樣本數據深刻的挖掘、分析和抽象，以獲得一份通用的，覆蓋率大的應用場景數據。只有如此，纔可以開發出一款具備普世價值的應用軟件，才能貼合SaaS用戶的實際需求。而在這次的SaaS化產品的過程當中，咱們犯了「閉門造車」的嚴重錯誤，致使這一錯誤產生的緣由是咱們拿到的原始需求不夠，僅僅憑藉一兩個客戶的需求數據，並以此爲藍本展開系統的設計，實現了不少用戶根本不須要的功能，好比用戶只想要一個文檔存儲的功能，咱們實現了一個網盤的功能；又好比說咱們沒有考慮到中學禁止學生使用手機，而咱們的系統功能不少是基於移動端進行設計的，最後致使系統的功能和用戶的需求對不上號。當咱們花了很長時間去實現一個本身認爲很棒的功能時，客戶不承認這樣的設計給了咱們狠狠的一劑耳光，痛並鬱悶着。

客戶需求數據過少，加之主觀上的臆想，致使了系統中充斥着大量華而不實的功能。表面上看，系統的各個功能都比較高大上，但就是這樣高大上的功能，卻和客戶的想法背道而馳。客戶的想法是最實際的，華麗的功能在必定程度上太過於注重「表演」，而沒法真正幫助客戶解決實際的問題。

面對這樣一個問題，就須要在提出一個好的創意時，須要再三的與實際的需求作比對，只有創意與需求可以契合在一塊兒時，創意才能轉化爲有效的功能，才能起到錦上添花的效果。而解決這一個問題，須要將以下的幾個工做落實到實處：

• 一、獲取儘量多的需求樣本數據
• 二、對需求數據進行劃分、得出需求場景
• 三、以場景創建用戶故事，梳理業務邏輯
• 四、以業務邏輯爲單元，評估系統規模，展開系統設計
• 五、創建有效的溝通機制，及時將設計原型與用戶進行溝通，肯定有效需求

下面，經過一張圖來講明如何排除不務實的系統需求：

 

說明：

在第一步中，咱們須要收集不一樣用戶數量，不一樣知識結構、不一樣硬件環境以及不一樣資金支配能力的客戶需求，這樣才能從不一樣的維度去了解客戶的想法和業務痛點。如用戶量大的客戶，更則種系統的總體協能力，以及業務的流程的連貫性和時效性。而用戶量較小的客戶可能則重於系統的高效和便捷程度。對於可支配資金，直接影響着系統在設計時的佈局，如性能的分配和交互的體驗度，以及後期定製收費標準。

第二步、創建場景是爲了把龐雜的需求進行切割，創建科學的需求分類，減輕需求分析的難度和時長。將雜亂的需求按照類別進行深刻分析，挖掘客戶的業務痛點，爲構建起用戶故事提供素材和依據。

第三步中，分析的視角將從局部變爲全局，經過第二步獲得數據，創建起用戶故事，以分析各需求之間的聯繫和各自的主線。

第四部是對需求進行統籌規劃，將需求變成可用的業務邏輯，並對此業務邏輯進行技術可行性和風險評估，最後將此評估結果與客戶需求進行比對和調整，肯定最終的有效需求。

2、技術債務過大

任何應用程序的開發，都須要考慮技術債務問題，即木桶定理。從項目開始提案開始，就犯了技術冒進的錯誤。選擇了技術一系列比較新的技術框架和設計思想，如先後端分離設計，微服務化和容器化等較新的技術棧，以及項目開始實施前沒有作好相關技術的培訓工做，致使項目組成員的技術能力參差不齊，項目推動緩慢，接連踩坑，不少關鍵技術沒有吃透，不少技術問題沒有解決，致使應用系統性能脆弱，部署週期長，運維難度大，直至後面項目擱淺。

出現這樣巨大的技術債務，是過於盲目的跟隨市場技術浪潮，沒有對自身團隊技術能力作一個有效的評估所形成的。新技術當然有它超越現有技術的威力所在，但弊病也很多。首先是學習成本，須要花費大量的時間對整個團隊進行培訓，而培訓並非全部的人都能一個水平，從這開始，木桶的短板就開始產生了。因爲技術掌握不牢固，開發工程中踩坑是避免不了的，這就致使項目進度急劇拉長，技術債務開始累積，最後的結果就是，產品千瘡百孔，沒法使用。

因爲花費的巨大的時間去解決技術問題，從而忽略了一開始的運維問題（更多的是無暇顧及，先把產品搞出來再說）。不少時候，在開發調試階段應用程序沒有出現問題，一旦放到生產環境就開始問題百出。這是由於咱們想固然的認爲，新技術已經把全部的問題都解決了，抱着一種僥倖的心理，在匆忙之間將項目上線，從而忽視那些極爲致命的問題，線上安全問題、性能問題、網絡問題、環境問題、終端適配問題等等。

這些問題歸集到一塊兒，主要問題出在架構師身上，致使能夠終結出這種架構師的幾點特質：

• 一、出方案靠拍腦殼，一錘子買賣。一拍腦殼，就這麼定了，根本沒有考慮後續的問題
• 二、實現過程排胸脯，保證沒有問題。過於自信，致使太過自負。對於架構師而言，沒有問題就是最大的問題
• 三、出問題排大腿，這麼回這樣。等到問題出現了，才恍然大悟，當初爲何沒有想到會這樣
• 四、程序崩潰排桌子，坑爹的框架。沒有認真的選擇合適的技術棧來完成項目，從一開始的設計從肯定了系統的先天性頑疾，並非框架自己的錯。

那麼，該如何避免技術債務過大的問題能？個人建議是杜絕設計上的冒進，不是新技術就必定好。能夠採起小步快走，縮小升級範圍，先將非核心功能進行改造，實現系統平滑過渡到新的技術框架，也讓團隊的成員有一個適應期，避免一次性集中踩雷的風險。與此同時，還需注意另一個問題，系統重構不等於推翻重來。不少人會以爲推翻重來必定會比以前的設計好，在必定程度上能夠將以前系統暴露的問題進行規避，但新的設計又會帶來新的，更多的問題。因此，在進行升級過渡到SaaS產品時，必定要學會利用之後的成熟技術，減小升級的難度和成本，快速多批次的進行升級，這樣，即使出現問題，也能夠將問題控制在一個能夠接受的範圍，不至於蔓延至整個系統，甚至形成應用程序的不可用。

最後就是關於運維的問題，在設計一套系統架構時，必定要提早預估它的運維工做量，若是解決系統的「後顧之憂」，運維所帶來的技術債務不比開發過程的少，以此次項目爲例，應用程序按照業務分紅了若干個服務，每一個服務對應着10到20個不等的運行實例，因爲項目組沒法拿出有效的容器化方案，以及部署環境不支持Docker容器技術，也沒有持續發佈應用實例的環境，最後只能人工手動維護200多個JAR包的運行實例，當出現應用程序不可用，或者宕機問題時，須要人工重啓對應的應用程序，這是一個糟糕的設計，或者說是失敗的設計，對於運維來講，這是一場災難。因爲先天性的不足，加速了產品走向奔潰的邊緣。

3、一口吃成大胖子

致使項目最終走向失敗還有另一個重要的緣由，一口吃太多，嚼不爛。在肯定需求的過程當中，對於每個租戶提出的需求，咱們採起了儘量知足的方法，致使整個系統過於臃腫，雜亂，就比如一個萬花筒。

按照這樣一種方式，平臺須要具有多端接入的能力，如PC、平板、智能手機等，以知足不一樣租戶的要求，但最終咱們連PC端都沒有實現好。好高騖遠，每每就是走向失敗的開始；量體裁衣，纔是作系統設計的硬道理。體系太過於龐大，團隊的技術能力沒法覆蓋一會兒覆蓋到這麼大的面，並且核心的功能還未接受市場的檢驗，就同時要知足適配多端的能力，這無疑是在開玩笑，最終將會獲得一個爛尾工程。即使項目完成，充其量也就是一個軟件中的「玩具」。

所以，在軟件開發之初，切忌好大喜功，一會兒將所有的功能都歸入到實現的範圍，須要識別出哪些是必須功能，哪些是核心功能，哪些是擴展功能。須要分清楚產品的願景與產品實現的本質區別。願景是對產品生態鏈的展望，而技術實現須要實事求是，根據現有的技術水平和用戶需求，作出一個折中的方案，任何設計都有妥協，沒有一步到位的軟件產品，也沒有最好的軟件產品，只有經過一步步的優化設計，一步步的升級技術，才能作出更好的軟件產品。這一點在研發SaaS平臺時尤其重要，你不可能同時知足多個租戶的需求，你須要甄別出最具表明性和最有價值的那一部分租戶，你的研發方向也須要向這一部分租戶靠攏，下面經過一張圖來講明構建一個SaaS平臺時，需求佔比應該如何分配：

 

爲何會有這樣的一個配比？首先，可以創造價值的租戶，是可以向你進行付費使用軟件的租戶，對於這一部分租戶提出的需求，你能夠以定製軟件的態度去對待，對於他們提出的要求，你須要想辦法去實現。而具備發展潛力的租戶，是那些有可能成爲你付費用戶的羣體，你須要研究產品的核心功能是什麼？，以及什麼樣的核心功能才能打動他們。而具備表明性的租戶是指那些可以提出比較創新的，具備一市場價值的需求的羣體，他們是產品發展的創新所在，能夠考慮爲這一部分羣體單獨擴展出他們想要的功能，以觀察市場的對平臺的反應。最後是基礎租戶，他們的需求都具備普世性，須要考慮必定量的通用功能爲其服務。

4、業務於產品先行

最後，談談技術以外的一些見解。大部分的團隊都會犯這樣一個錯誤：當產品開發完成以後，再去尋找市場。咱們在這個項目中，也犯了一樣的錯誤。能夠思考這樣一個問題，用戶的需求隨着時間的推移在發生改變，若是你不緊跟市場的動向，及時調整本身的產品功能，而是拿到一份需求後就開始閉門造車，當你的產品開發完時，就已經被淘汰了。爲了不產品沒有市場，業務就必須限於產品動起來。經過不斷的獲取用戶的需求，提取有價值的需求數據，及時調整產品的方向，才能縮短產品功能與用戶需求之間的差距。業務先行，在間接的幫助平臺設計者完善和充實現有的功能，及時的發現平臺隱藏的問題，並對此作出調整，在交付產品前儘量的規避可能出現的故障，提升平臺的服務能力。

總結

對於今天的軟件設計者來講，讓軟件使用者來適應你所設計的產品的時代已經不復存在。你須要主動的調整本身，從內到外多角度的看待問題，才能幫助你出色的完成軟件的設計。在技術上，須要沉着冷靜，實事求是的分析所面對的問題，須要懂得如何把控技術風險；科學有序的開展軟件設計工做，斷不可不顧現實狀況，盲目跟風，技術冒進以及惟技術論的路子對待軟件設計。在業務上，須要實時跟進需求的變化，具有敏銳的眼光去發現用戶的痛點和難點，可以快速的對用戶需求的變動作出合理、科學的反應。

文章轉自：https://www.toutiao.com/i6699138217674801667/

做者：ramostear