2021-02-07 分類: 網站建設
前言: 筆者從2017年起開始著手將公司現有的軟件系統改造成多租戶模式,以降低整個系統的運營成本。但最后這個項目以失敗告終。今天,我將對這個saas項目是如何走向失敗,做一個分析和反思。
此前,我們花費了兩年的時間研發了一套教學系統,考慮到用戶的數量與營運成本,后期決定將這套單體的應用程序改造為基于saas架構的多租戶應用程序。經過短暫的需求分析后,便開始了重構工作。經過一年的艱苦奮斗,saas化的產品不僅用戶不能接受,就連我們自己也無法成功運營。其功能的完成度差強人意,運營的成本也沒有比單體應用少,反而運營難度上升了。通過一段時間的整理與思考,總結了這一次saas化平臺失敗的原因。
一、不務實的需求
一個成功的saas產品,需要有足夠多的用戶需求樣本數據以及對這些樣本數據深入的挖掘、分析和抽象,以得到一份通用的,覆蓋率大的應用場景數據。只有如此,才能夠開發出一款具有普世價值的應用軟件,才能貼合saas用戶的實際需求。而在此次的saas化產品的過程中,我們犯了“閉門造車”的嚴重錯誤,導致這一錯誤產生的原因是我們拿到的原始需求不夠,僅僅憑借一兩個客戶的需求數據,并以此為藍本展開系統的設計,實現了很多用戶根本不需要的功能,比如用戶只想要一個文檔存儲的功能,我們實現了一個網盤的功能;又比如說我們沒有考慮到中學禁止學生使用手機,而我們的系統功能很多是基于移動端進行設計的,最后導致系統的功能和用戶的需求對不上號。當我們花了很長時間去實現一個自己認為很棒的功能時,客戶不認可這樣的設計給了我們狠狠的一劑耳光,痛并郁悶著。
客戶需求數據過少,加之主觀上的臆想,導致了系統中充斥著大量華而不實的功能。表面上看,系統的各個功能都比較高大上,但就是這樣高大上的功能,卻和客戶的想法背道而馳。客戶的想法是最實際的,華麗的功能在一定程度上太過于注重“表演”,而無法真正幫助客戶解決實際的問題。
面對這樣一個問題,就需要在提出一個好的創意時,需要再三的與實際的需求做比對,只有創意與需求能夠契合在一起時,創意才能轉化為有效的功能,才能起到錦上添花的效果。而解決這一個問題,需要將如下的幾個工作落實到實處:
下面,通過一張圖來說明如何排除不務實的系統需求:
說明:
在第一步中,我們需要收集不同用戶數量,不同知識結構、不同硬件環境以及不同資金支配能力的客戶需求,這樣才能從不同的維度去了解客戶的想法和業務痛點。如用戶量大的客戶,更則種系統的整體協能力,以及業務的流程的連貫性和時效性。而用戶量較小的客戶可能則重于系統的高效和便捷程度。對于可支配資金,直接影響著系統在二、技術債務過大
任何應用程序的開發,都需要考慮技術債務問題,即木桶定理。從項目開始提案開始,就犯了技術冒進的錯誤。選擇了技術一系列比較新的技術框架和設計思想,如前后端分離設計,微服務化和容器化等較新的技術棧,以及項目開始實施前沒有做好相關技術的培訓工作,導致項目組成員的技術能力良莠不齊,項目推進緩慢,接連踩坑,很多關鍵技術沒有吃透,很多技術問題沒有解決,導致應用系統性能脆弱,部署周期長,運維難度大,直至后面項目擱淺。
出現這樣巨大的技術債務,是過于盲目的跟隨市場技術浪潮,沒有對自身團隊技術能力做一個有效的評估所造成的。新技術固然有它超越現有技術的威力所在,但弊病也不少。首先是學習成本,需要花費大量的時間對整個團隊進行培訓,而培訓并不是所有的人都能一個水平,從這開始,木桶的短板就開始產生了。由于技術掌握不牢固,開發工程中踩坑是避免不了的,這就導致項目進度急劇拉長,技術債務開始累積,最后的結果就是,產品千瘡百孔,無法使用。
由于花費的巨大的時間去解決技術問題,從而忽略了一開始的運維問題(更多的是無暇顧及,先把產品搞出來再說)。很多時候,在開發調試階段應用程序沒有出現問題,一旦放到生產環境就開始問題百出。這是因為我們想當然的認為,新技術已經把所有的問題都解決了,抱著一種僥幸的心理,在匆忙之間將項目上線,從而忽視那些極為致命的問題,線上安全問題、性能問題、網絡問題、環境問題、終端適配問題等等。
這些問題歸集到一起,主要問題出在架構師身上,導致可以終結出這種架構師的幾點特質:
那么,該如何避免技術債務過大的問題能?我的建議是杜絕設計上的冒進,不是新技術就一定好。可以采取小步快走,縮小升級范圍,先將非核心功能進行改造,實現系統平滑過渡到新的技術框架,也讓團隊的成員有一個適應期,避免一次性集中踩雷的風險。與此同時,還需注意另外一個問題,系統重構不等于推翻重來。很多人會覺得推翻重來一定會比之前的設計好,在一定程度上可以將之前系統暴露的問題進行規避,但新的設計又會帶來新的,更多的問題。所以,在進行升級過渡到saas產品時,一定要學會利用以后的成熟技術,減少升級的難度和成本,快速多批次的進行升級,這樣,即便出現問題,也可以將問題控制在一個可以接受的范圍,不至于蔓延至整個系統,甚至造成應用程序的不可用。
最后就是關于運維的問題,在設計一套系統架構時,一定要提前預估它的運維工作量,如果解決系統的“后顧之憂”,運維所帶來的技術債務不比開發過程的少,以這次項目為例,應用程序按照業務分成了若干個服務,每個服務對應著10到20個不等的運行實例,由于項目組無法拿出有效的容器化方案,以及部署環境不支持Docker容器技術,也沒有持續發布應用實例的環境,最后只能人工手動維護200多個JAR包的運行實例,當出現應用程序不可用,或者宕機問題時,需要人工重啟對應的應用程序,這是一個糟糕的設計,或者說是失敗的設計,對于運維來說,這是一場災難。由于先天性的不足,加速了產品走向奔潰的邊緣。
三、一口吃成大胖子
導致項目最終走向失敗還有另外一個重要的原因,一口吃太多,嚼不爛。在確定需求的過程中,對于每一個租戶提出的需求,我們采取了盡可能滿足的方法,導致整個系統過于臃腫,雜亂,就好比一個萬花筒。
按照這樣一種方式,平臺需要具備多端接入的能力,如PC、平板、智能手機等,以滿足不同租戶的要求,但最終我們連PC端都沒有實現好。好高騖遠,往往就是走向失敗的開始;量體裁衣,才是做系統設計的硬道理。體系太過于龐大,團隊的技術能力無法覆蓋一下子覆蓋到這么大的面,而且核心的功能還未接受市場的檢驗,就同時要滿足適配多端的能力,這無疑是在開玩笑,最終將會得到一個爛尾工程。即便項目完成,充其量也就是一個軟件中的“玩具”。
因此,在軟件開發之初,切忌好大喜功,一下子將全部的功能都納入到實現的范圍,需要識別出哪些是必須功能,哪些是核心功能,哪些是擴展功能。需要分清楚產品的愿景與產品實現的本質區別。愿景是對產品生態鏈的展望,而技術實現需要實事求是,根據現有的技術水平和用戶需求,做出一個折中的方案,任何設計都有妥協,沒有一步到位的軟件產品,也沒有最好的軟件產品,只有通過一步步的優化設計,一步步的升級技術,才能做出更好的軟件產品。這一點在研發saas平臺時尤為重要,你不可能同時滿足多個租戶的需求,你需要甄別出最具代表性和最有價值的那一部分租戶,你的研發方向也需要向這一部分租戶靠攏,下面通過一張圖來說明構建一個saas平臺時,需求占比應該如何分配:
為什么會有這樣的一個配比?首先,能夠創造價值的租戶,是能夠向你進行付費使用軟件的租戶,對于這一部分租戶提出的需求,你可以以定制軟件的態度去對待,對于他們提出的要求,你需要想辦法去實現。而具有發展潛力的租戶,是那些有可能成為你付費用戶的群體,你需要研究產品的核心功能是什么?,以及什么樣的核心功能才能打動他們。而具有代表性的租戶是指那些能夠提出比較創新的,具有一市場價值的需求的群體,他們是產品發展的創新所在,可以考慮為這一部分群體單獨擴展出他們想要的功能,以觀察市場的對平臺的反應。最后是基礎租戶,他們的需求都具有普世性,需要考慮一定量的通用功能為其服務。
四、業務于產品先行
最后,談談技術之外的一些看法。大部分的團隊都會犯這樣一個錯誤:當產品開發完成之后,再去尋找市場。我們在這個項目中,也犯了同樣的錯誤。可以思考這樣一個問題,用戶的需求隨著時間的推移在發生改變,如果你不緊跟市場的動向,及時調整自己的產品功能,而是拿到一份需求后就開始閉門造車,當你的產品開發完時,就已經被淘汰了。為了避免產品沒有市場,業務就必須限于產品動起來。通過不斷的獲取用戶的需求,提取有價值的需求數據,及時調整產品的方向,才能縮短產品功能與用戶需求之間的差距。業務先行,在間接的幫助平臺設計者完善和充實現有的功能,及時的發現平臺隱藏的問題,并對此做出調整,在交付產品前盡可能的規避可能出現的故障,提高平臺的服務能力。
總結
對于今天的軟件設計者來說,讓軟件使用者來適應你所設計的產品的時代已經不復存在。你需要主動的調整自己,從內到外多角度的看待問題,才能幫助你出色的完成軟件的設計。在技術上,需要沉著冷靜,實事求是的分析所面對的問題,需要懂得如何把控技術風險;科學有序的開展軟件設計工作,斷不可不顧現實情況,盲目跟風,技術冒進以及唯技術論的路子對待軟件設計。在業務上,需要實時跟進需求的變化,具備敏銳的眼光去發現用戶的痛點和難點,能夠快速的對用戶需求的變更做出合理、科學的反應。
當前題目:一次架構SaaS平臺項目失敗的經驗總結
分享網址:http://m.newbst.com/news37/99637.html
成都網站建設公司_創新互聯,為您提供外貿網站建設、建站公司、手機網站建設、自適應網站、定制網站、面包屑導航
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯
猜你還喜歡下面的內容