前言： 筆者從2017年起開始著手將公司現(xiàn)有的軟件系統(tǒng)改造成多租戶模式，以降低整個(gè)系統(tǒng)的運(yùn)營成本。但最后這個(gè)項(xiàng)目以失敗告終。今天，我將對這個(gè)saas項(xiàng)目是如何走向失敗，做一個(gè)分析和反思。

此前，我們花費(fèi)了兩年的時(shí)間研發(fā)了一套教學(xué)系統(tǒng)，考慮到用戶的數(shù)量與營運(yùn)成本，后期決定將這套單體的應(yīng)用程序改造為基于saas架構(gòu)的多租戶應(yīng)用程序。經(jīng)過短暫的需求分析后，便開始了重構(gòu)工作。經(jīng)過一年的艱苦奮斗，saas化的產(chǎn)品不僅用戶不能接受，就連我們自己也無法成功運(yùn)營。其功能的完成度差強(qiáng)人意，運(yùn)營的成本也沒有比單體應(yīng)用少，反而運(yùn)營難度上升了。通過一段時(shí)間的整理與思考，總結(jié)了這一次saas化平臺失敗的原因。

一、不務(wù)實(shí)的需求

一個(gè)成功的saas產(chǎn)品，需要有足夠多的用戶需求樣本數(shù)據(jù)以及對這些樣本數(shù)據(jù)深入的挖掘、分析和抽象，以得到一份通用的，覆蓋率大的應(yīng)用場景數(shù)據(jù)。只有如此，才能夠開發(fā)出一款具有普世價(jià)值的應(yīng)用軟件，才能貼合saas用戶的實(shí)際需求。而在此次的saas化產(chǎn)品的過程中，我們犯了“閉門造車”的嚴(yán)重錯(cuò)誤，導(dǎo)致這一錯(cuò)誤產(chǎn)生的原因是我們拿到的原始需求不夠，僅僅憑借一兩個(gè)客戶的需求數(shù)據(jù)，并以此為藍(lán)本展開系統(tǒng)的設(shè)計(jì)，實(shí)現(xiàn)了很多用戶根本不需要的功能，比如用戶只想要一個(gè)文檔存儲的功能，我們實(shí)現(xiàn)了一個(gè)網(wǎng)盤的功能；又比如說我們沒有考慮到中學(xué)禁止學(xué)生使用手機(jī)，而我們的系統(tǒng)功能很多是基于移動(dòng)端進(jìn)行設(shè)計(jì)的，最后導(dǎo)致系統(tǒng)的功能和用戶的需求對不上號。當(dāng)我們花了很長時(shí)間去實(shí)現(xiàn)一個(gè)自己認(rèn)為很棒的功能時(shí)，客戶不認(rèn)可這樣的設(shè)計(jì)給了我們狠狠的一劑耳光，痛并郁悶著。

客戶需求數(shù)據(jù)過少，加之主觀上的臆想，導(dǎo)致了系統(tǒng)中充斥著大量華而不實(shí)的功能。表面上看，系統(tǒng)的各個(gè)功能都比較高大上，但就是這樣高大上的功能，卻和客戶的想法背道而馳?？蛻舻南敕ㄊ亲顚?shí)際的，華麗的功能在一定程度上太過于注重“表演”，而無法真正幫助客戶解決實(shí)際的問題。

面對這樣一個(gè)問題，就需要在提出一個(gè)好的創(chuàng)意時(shí)，需要再三的與實(shí)際的需求做比對，只有創(chuàng)意與需求能夠契合在一起時(shí)，創(chuàng)意才能轉(zhuǎn)化為有效的功能，才能起到錦上添花的效果。而解決這一個(gè)問題，需要將如下的幾個(gè)工作落實(shí)到實(shí)處：

• 1、獲取盡可能多的需求樣本數(shù)據(jù)
• 2、對需求數(shù)據(jù)進(jìn)行劃分、得出需求場景
• 3、以場景建立用戶故事，梳理業(yè)務(wù)邏輯
• 4、以業(yè)務(wù)邏輯為單元，評估系統(tǒng)規(guī)模，展開系統(tǒng)設(shè)計(jì)
• 5、建立有效的溝通機(jī)制，及時(shí)將設(shè)計(jì)原型與用戶進(jìn)行溝通，確定有效需求

下面，通過一張圖來說明如何排除不務(wù)實(shí)的系統(tǒng)需求：

說明：

在第一步中，我們需要收集不同用戶數(shù)量，不同知識結(jié)構(gòu)、不同硬件環(huán)境以及不同資金支配能力的客戶需求，這樣才能從不同的維度去了解客戶的想法和業(yè)務(wù)痛點(diǎn)。如用戶量大的客戶，更則種系統(tǒng)的整體協(xié)能力，以及業(yè)務(wù)的流程的連貫性和時(shí)效性。而用戶量較小的客戶可能則重于系統(tǒng)的高效和便捷程度。對于可支配資金，直接影響著系統(tǒng)在二、技術(shù)債務(wù)過大

任何應(yīng)用程序的開發(fā)，都需要考慮技術(shù)債務(wù)問題，即木桶定理。從項(xiàng)目開始提案開始，就犯了技術(shù)冒進(jìn)的錯(cuò)誤。選擇了技術(shù)一系列比較新的技術(shù)框架和設(shè)計(jì)思想，如前后端分離設(shè)計(jì)，微服務(wù)化和容器化等較新的技術(shù)棧，以及項(xiàng)目開始實(shí)施前沒有做好相關(guān)技術(shù)的培訓(xùn)工作，導(dǎo)致項(xiàng)目組成員的技術(shù)能力良莠不齊，項(xiàng)目推進(jìn)緩慢，接連踩坑，很多關(guān)鍵技術(shù)沒有吃透，很多技術(shù)問題沒有解決，導(dǎo)致應(yīng)用系統(tǒng)性能脆弱，部署周期長，運(yùn)維難度大，直至后面項(xiàng)目擱淺。

出現(xiàn)這樣巨大的技術(shù)債務(wù)，是過于盲目的跟隨市場技術(shù)浪潮，沒有對自身團(tuán)隊(duì)技術(shù)能力做一個(gè)有效的評估所造成的。新技術(shù)固然有它超越現(xiàn)有技術(shù)的威力所在，但弊病也不少。首先是學(xué)習(xí)成本，需要花費(fèi)大量的時(shí)間對整個(gè)團(tuán)隊(duì)進(jìn)行培訓(xùn)，而培訓(xùn)并不是所有的人都能一個(gè)水平，從這開始，木桶的短板就開始產(chǎn)生了。由于技術(shù)掌握不牢固，開發(fā)工程中踩坑是避免不了的，這就導(dǎo)致項(xiàng)目進(jìn)度急劇拉長，技術(shù)債務(wù)開始累積，最后的結(jié)果就是，產(chǎn)品千瘡百孔，無法使用。

由于花費(fèi)的巨大的時(shí)間去解決技術(shù)問題，從而忽略了一開始的運(yùn)維問題（更多的是無暇顧及，先把產(chǎn)品搞出來再說）。很多時(shí)候，在開發(fā)調(diào)試階段應(yīng)用程序沒有出現(xiàn)問題，一旦放到生產(chǎn)環(huán)境就開始問題百出。這是因?yàn)槲覀兿氘?dāng)然的認(rèn)為，新技術(shù)已經(jīng)把所有的問題都解決了，抱著一種僥幸的心理，在匆忙之間將項(xiàng)目上線，從而忽視那些極為致命的問題，線上安全問題、性能問題、網(wǎng)絡(luò)問題、環(huán)境問題、終端適配問題等等。

這些問題歸集到一起，主要問題出在架構(gòu)師身上，導(dǎo)致可以終結(jié)出這種架構(gòu)師的幾點(diǎn)特質(zhì)：

• 1、出方案靠拍腦袋，一錘子買賣。一拍腦袋，就這么定了，根本沒有考慮后續(xù)的問題
• 2、實(shí)現(xiàn)過程排胸脯，保證沒有問題。過于自信，導(dǎo)致太過自負(fù)。對于架構(gòu)師而言，沒有問題就是大的問題
• 3、出問題排大腿，這么回這樣。等到問題出現(xiàn)了，才恍然大悟，當(dāng)初為什么沒有想到會(huì)這樣
• 4、程序崩潰排桌子，坑爹的框架。沒有認(rèn)真的選擇合適的技術(shù)棧來完成項(xiàng)目，從一開始的設(shè)計(jì)從確定了系統(tǒng)的先天性頑疾，并不是框架本身的錯(cuò)。

那么，該如何避免技術(shù)債務(wù)過大的問題能？我的建議是杜絕設(shè)計(jì)上的冒進(jìn)，不是新技術(shù)就一定好。可以采取小步快走，縮小升級范圍，先將非核心功能進(jìn)行改造，實(shí)現(xiàn)系統(tǒng)平滑過渡到新的技術(shù)框架，也讓團(tuán)隊(duì)的成員有一個(gè)適應(yīng)期，避免一次性集中踩雷的風(fēng)險(xiǎn)。與此同時(shí)，還需注意另外一個(gè)問題，系統(tǒng)重構(gòu)不等于推翻重來。很多人會(huì)覺得推翻重來一定會(huì)比之前的設(shè)計(jì)好，在一定程度上可以將之前系統(tǒng)暴露的問題進(jìn)行規(guī)避，但新的設(shè)計(jì)又會(huì)帶來新的，更多的問題。所以，在進(jìn)行升級過渡到saas產(chǎn)品時(shí)，一定要學(xué)會(huì)利用以后的成熟技術(shù)，減少升級的難度和成本，快速多批次的進(jìn)行升級，這樣，即便出現(xiàn)問題，也可以將問題控制在一個(gè)可以接受的范圍，不至于蔓延至整個(gè)系統(tǒng)，甚至造成應(yīng)用程序的不可用。

最后就是關(guān)于運(yùn)維的問題，在設(shè)計(jì)一套系統(tǒng)架構(gòu)時(shí)，一定要提前預(yù)估它的運(yùn)維工作量，如果解決系統(tǒng)的“后顧之憂”，運(yùn)維所帶來的技術(shù)債務(wù)不比開發(fā)過程的少，以這次項(xiàng)目為例，應(yīng)用程序按照業(yè)務(wù)分成了若干個(gè)服務(wù)，每個(gè)服務(wù)對應(yīng)著10到20個(gè)不等的運(yùn)行實(shí)例，由于項(xiàng)目組無法拿出有效的容器化方案，以及部署環(huán)境不支持Docker容器技術(shù)，也沒有持續(xù)發(fā)布應(yīng)用實(shí)例的環(huán)境，最后只能人工手動(dòng)維護(hù)200多個(gè)JAR包的運(yùn)行實(shí)例，當(dāng)出現(xiàn)應(yīng)用程序不可用，或者宕機(jī)問題時(shí)，需要人工重啟對應(yīng)的應(yīng)用程序，這是一個(gè)糟糕的設(shè)計(jì)，或者說是失敗的設(shè)計(jì)，對于運(yùn)維來說，這是一場災(zāi)難。由于先天性的不足，加速了產(chǎn)品走向奔潰的邊緣。

三、一口吃成大胖子

導(dǎo)致項(xiàng)目最終走向失敗還有另外一個(gè)重要的原因，一口吃太多，嚼不爛。在確定需求的過程中，對于每一個(gè)租戶提出的需求，我們采取了盡可能滿足的方法，導(dǎo)致整個(gè)系統(tǒng)過于臃腫，雜亂，就好比一個(gè)萬花筒。

按照這樣一種方式，平臺需要具備多端接入的能力，如PC、平板、智能手機(jī)等，以滿足不同租戶的要求，但最終我們連PC端都沒有實(shí)現(xiàn)好。好高騖遠(yuǎn)，往往就是走向失敗的開始；量體裁衣，才是做系統(tǒng)設(shè)計(jì)的硬道理。體系太過于龐大，團(tuán)隊(duì)的技術(shù)能力無法覆蓋一下子覆蓋到這么大的面，而且核心的功能還未接受市場的檢驗(yàn)，就同時(shí)要滿足適配多端的能力，這無疑是在開玩笑，最終將會(huì)得到一個(gè)爛尾工程。即便項(xiàng)目完成，充其量也就是一個(gè)軟件中的“玩具”。

因此，在軟件開發(fā)之初，切忌好大喜功，一下子將全部的功能都納入到實(shí)現(xiàn)的范圍，需要識別出哪些是必須功能，哪些是核心功能，哪些是擴(kuò)展功能。需要分清楚產(chǎn)品的愿景與產(chǎn)品實(shí)現(xiàn)的本質(zhì)區(qū)別。愿景是對產(chǎn)品生態(tài)鏈的展望，而技術(shù)實(shí)現(xiàn)需要實(shí)事求是，根據(jù)現(xiàn)有的技術(shù)水平和用戶需求，做出一個(gè)折中的方案，任何設(shè)計(jì)都有妥協(xié)，沒有一步到位的軟件產(chǎn)品，也沒有最好的軟件產(chǎn)品，只有通過一步步的優(yōu)化設(shè)計(jì)，一步步的升級技術(shù)，才能做出更好的軟件產(chǎn)品。這一點(diǎn)在研發(fā)saas平臺時(shí)尤為重要，你不可能同時(shí)滿足多個(gè)租戶的需求，你需要甄別出最具代表性和最有價(jià)值的那一部分租戶，你的研發(fā)方向也需要向這一部分租戶靠攏，下面通過一張圖來說明構(gòu)建一個(gè)saas平臺時(shí)，需求占比應(yīng)該如何分配：

為什么會(huì)有這樣的一個(gè)配比？首先，能夠創(chuàng)造價(jià)值的租戶，是能夠向你進(jìn)行付費(fèi)使用軟件的租戶，對于這一部分租戶提出的需求，你可以以定制軟件的態(tài)度去對待，對于他們提出的要求，你需要想辦法去實(shí)現(xiàn)。而具有發(fā)展?jié)摿Φ淖鈶?，是那些有可能成為你付費(fèi)用戶的群體，你需要研究產(chǎn)品的核心功能是什么？，以及什么樣的核心功能才能打動(dòng)他們。而具有代表性的租戶是指那些能夠提出比較創(chuàng)新的，具有一市場價(jià)值的需求的群體，他們是產(chǎn)品發(fā)展的創(chuàng)新所在，可以考慮為這一部分群體單獨(dú)擴(kuò)展出他們想要的功能，以觀察市場的對平臺的反應(yīng)。最后是基礎(chǔ)租戶，他們的需求都具有普世性，需要考慮一定量的通用功能為其服務(wù)。

四、業(yè)務(wù)于產(chǎn)品先行

最后，談?wù)劶夹g(shù)之外的一些看法。大部分的團(tuán)隊(duì)都會(huì)犯這樣一個(gè)錯(cuò)誤：當(dāng)產(chǎn)品開發(fā)完成之后，再去尋找市場。我們在這個(gè)項(xiàng)目中，也犯了同樣的錯(cuò)誤?？梢运伎歼@樣一個(gè)問題，用戶的需求隨著時(shí)間的推移在發(fā)生改變，如果你不緊跟市場的動(dòng)向，及時(shí)調(diào)整自己的產(chǎn)品功能，而是拿到一份需求后就開始閉門造車，當(dāng)你的產(chǎn)品開發(fā)完時(shí)，就已經(jīng)被淘汰了。為了避免產(chǎn)品沒有市場，業(yè)務(wù)就必須限于產(chǎn)品動(dòng)起來。通過不斷的獲取用戶的需求，提取有價(jià)值的需求數(shù)據(jù)，及時(shí)調(diào)整產(chǎn)品的方向，才能縮短產(chǎn)品功能與用戶需求之間的差距。業(yè)務(wù)先行，在間接的幫助平臺設(shè)計(jì)者完善和充實(shí)現(xiàn)有的功能，及時(shí)的發(fā)現(xiàn)平臺隱藏的問題，并對此做出調(diào)整，在交付產(chǎn)品前盡可能的規(guī)避可能出現(xiàn)的故障，提高平臺的服務(wù)能力。

總結(jié)

對于今天的軟件設(shè)計(jì)者來說，讓軟件使用者來適應(yīng)你所設(shè)計(jì)的產(chǎn)品的時(shí)代已經(jīng)不復(fù)存在。你需要主動(dòng)的調(diào)整自己，從內(nèi)到外多角度的看待問題，才能幫助你出色的完成軟件的設(shè)計(jì)。在技術(shù)上，需要沉著冷靜，實(shí)事求是的分析所面對的問題，需要懂得如何把控技術(shù)風(fēng)險(xiǎn)；科學(xué)有序的開展軟件設(shè)計(jì)工作，斷不可不顧現(xiàn)實(shí)情況，盲目跟風(fēng)，技術(shù)冒進(jìn)以及唯技術(shù)論的路子對待軟件設(shè)計(jì)。在業(yè)務(wù)上，需要實(shí)時(shí)跟進(jìn)需求的變化，具備敏銳的眼光去發(fā)現(xiàn)用戶的痛點(diǎn)和難點(diǎn)，能夠快速的對用戶需求的變更做出合理、科學(xué)的反應(yīng)。

當(dāng)前題目：一次架構(gòu)SaaS平臺項(xiàng)目失敗的經(jīng)驗(yàn)總結(jié)
分享網(wǎng)址：http://jinyejixie.com/news37/99637.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、建站公司、手機(jī)網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、定制網(wǎng)站、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)