如何解救一款難以持續的SaaS產品
1440
2020-12-01 18:28    文章來源:SaaS產品說 李東林
文章摘要:原來簡單提過這個話題,今天再相對深入的和大家探討下

原來簡單提過這個話題,今天再相對深入的和大家探討下。中國目前絕大多數saas公司都是銷售驅動,客戶需求驅動,很難拒絕定制開發,很容易就做成項目了,除非有很強產品力和業務洞察力的團隊來做,否則慢慢的經過幾年積累,產品就會變得臃腫不堪。

產品一旦變的臃腫,就會碰到很多問題:

維護成本越來越高

用戶體驗越來越差

積累的客戶從資源變成繩索,調整的難度以及工作量越來越大。

這種情況下,應對一些市場新銳的競爭就很被動。而且體驗差了之后客戶會慢慢流失,團隊對此無能為力,從而陷入進退兩難的困境,這也是中國大多數B端產品企業的現狀。

現有產品上重構or另起爐灶新開發一套?這個時候,公司就面臨艱難的抉擇,基本上所有研發團隊都會建議另起爐灶,從研發角度這是更簡單,更高效的方式,不用管原來的惡心代碼,團隊士氣也會更高一些,但從公司的角度,更需要考慮幾個因素:

新系統的開發成本以及開發周期。

一套新的系統從開發到小部分客戶上線使用,再到成熟穩定,是需要相當長的打磨周期的。

老客戶的遷移成本。

這個成本包括在遷移過程中投入的BD、實施、培訓、售后成本,也包括客戶投入的成本。

在并行期間,涉及到一些bug或者需求,需要兩邊都開發的成本。 

人員需要兩套班子,應對不同產品線,開發,實施,培訓,售后都需要兩套,招聘培養擴展的難度都會變大。另外兩條產品線之間產品還高度耦合,溝通工作量大。

一般來說,B端產品的遷移成本極高,客戶要改變使用習慣成本也極高。而且總有一些客戶不愿意遷移,最終不可避免的結局就是長期維護兩套系統。沒有經歷過的人是很難想象這樣的代價和成本的,遷移老客戶,老客戶勞筋動骨;不遷移老客戶,老客戶一定程度受忽視和傷害,影響口碑;

除非客戶非常少,或者可以基本保證比較低成本的全部遷移,筆者很不建議另起爐灶新開發一套,成本極大,除了所有的成本乘以2,還有遷移以及客戶那邊的成本,每一個客戶的遷移以及實施落地可能都是一個復雜的項目。 

所以新開發一套相比在現有產品上重構,成本絕對是指數級的增大。很多公司這樣選擇后,陷入對新產品不夠滿意,老產品也遷移不過去的困境,浪費大量時間和資源,筆者鮮有發現成功案例。

那如果需要去庖丁解牛的重構一套系統,我們應該怎樣來做呢,筆者覺得可以參考以下思路以及原則: 

1: 做好人的準備。

如同我以前一篇文章中說到的,人是事情成功與否的最關鍵要素。要做好庖丁解牛的工作,有幾個角色非常重要,數據庫架構師,解決方案架構師,功能架構師。不一定每個角色都需要一個人,但是一定要有人承擔對應的角色。比如說數據庫是B端產品的基石,一旦錯誤之后調整的成本非常高,數據庫架構師需要是懂數據庫設計技術,對業務發展、業務細節非常了解并有前瞻性的一個人或者多個人來協作。解決方案架構師實際也是需要是懂業務,并對技術有理解的一個人或者多個人。 

B端產品是一個交叉學科,單一的懂業務,懂技術的人都相對好找。既理解業務,也理解技術,并且能夠有機結合的人比較難找,這種人目前在中國屬于稀缺資源。一般來說,這種交叉學科,技術的人去學習業務比業務的人學習技術要容易一些,公司內部要選擇合適的人往這個方向培養。 

如果在短時間內很難有合適的人,也最好有一個外部的顧問來進行一定程度的把關。 

2: 將理想的產品形態大致的設計出來。

要確定產品重構的路徑,需要將產品最終的大致架構,主要是功能架構,系統架構設計出來,另外確定一些核心業務設計的思路以及原則,反復打磨,才能得出比較滿意的答案。知道了終點大概是怎樣的,才能很好的思考最佳的前進路徑。

3: 做好重構優先級的選擇。

對于產品的重構來說,路徑以及優先級的選擇極其重要,能夠找到最合理,最省力的路徑是非常考驗團隊的,這里很難有一個固定的答案,但是有一些原則性的內容可以去遵循:

優先做好地基式的核心架構調整。

做重構最核心的是將數據庫架構,產品功能架構,頁面架構做正確。數據庫也好,功能也好,頁面架構也好,實際上就是找到最合理的方式,就是在用戶體驗以及產品的生長性之間找到平衡點。一般來說,讓用戶用足夠少的頁面看到足夠多關心的內容對于體驗是最好的,但是產品是生長的,架構分類沒有分好,最后功能或者頁面也會非常擁擠,不能擴展,所以需要找到體驗和生長性之間最佳的平衡點。

     一些核心的數據庫表,核心的功能架構需要盡量優先的去調整,在錯誤的數據庫,錯誤的功能架構上做的內容都是無用功,還是要重新來過。

  優先做好核心或者特別爛的功能的重構

一些高頻使用的核心模塊,或者特別爛的功能要優先去重構,這種重構對用戶的價值也是最大的,客戶有足夠的動力來進行配合。

優先做好新需求量大的模塊重構。

產品不是靜態的,我們在做產品重構的時候,一定會面臨外部大量的需求還在不斷的涌進來,對于新需求很多的功能模塊,與其在錯誤的功能基礎上面花大量的時間做新需求,還不如重新來做一下。實際上所謂的重構,很多時候都是一個個模塊,一個個功能進行重寫,將大的風險用敏捷,庖丁解牛的方式去分解掉。 

4: 追求極致,不要重蹈覆轍,每次重構的機會都是一次重生的機會。

這個不用多說,每次重構一個模塊,都是一次重生的機會。我們不能用一個坑去填另外一個坑,至少要做到85分以上的設計才開始動手,不要一味的追求速度。 

5: 盡最大努力的做減法,每一次成功的減法都是一次勝利。

對于臃腫系統的重構,在重構重寫過程中,一定要想盡一切辦法做減法。模塊的減法,功能的減法,甚至一個字段的顯示,一個檢索條件,減到極致,好的重構一定伴隨著大量的減法。 

從客戶角度,每次重構之后的升級對于已經熟悉歷史系統的人來說,都是一次折磨,折磨的次數多了客戶是容易崩潰的。從用戶的體驗和口碑的角度,在迭代安排上面有如下的一些建議事項:

1: 每次迭代升級,讓客戶不斷的有甜頭可嘗。

每次迭代升級,重構后的新版本體驗需要大大超過原來的版本,或者有能夠解決客戶痛點的新功能,用戶才有動力升級。在設計安排每次迭代計劃的時候,要充分的考慮用戶升級的動力,否則會碰到很多阻力。

2: 遷移升級過程,盡量做到客戶無感知,免培訓,減少客戶的投入成本。

每次重構之后的升級經常會伴隨數據遷移,這個負擔不要給到客戶,實施團隊幫助客戶完成,另外每次重構后的功能要做到基本上不需要培訓,客戶也可以基本上不用投入實施培訓的成本。 

3: 做好灰度測試,先要確認新的功能可行再進行全量的發布。

每次大的重構,都需要一定時間的灰度測試周期,讓一些典型客戶先將重構的模塊用一下,確保沒有問題之后再進行全量發布,這樣可以盡量少的折騰客戶。每一次折騰,都會帶來不信任以及后面的不配合,產品口碑變差。 

4: 新客戶只開放必要的功能,減少后續遷移的成本。

這是一個小的tips,對于老產品中一些做的不好的非必要功能,在重構的過程中,通過權限處理,就不要開放給不斷增加的新客戶了,免得后面還增加遷移的成本。

重構很難;簡潔很難;人生很難;不過大部分人只有經歷過足夠多難題之后才能找到內心的從容,過好平淡的生活。


版權聲明:

凡本網內容請注明來源:T媒體(http://www.279457.tw)”的所有原創作品,版權均屬于易信視界(北京)信息科技有限公司所有,未經本網書面授權,不得轉載、摘編或以其它方式使用上述作品。

本網書面授權使用作品的,應在授權范圍內使用,并按雙方協議注明作品來源。違反上述聲明者,易信視界(北京)信息科技有限公司將追究其相關法律責任。

標簽:

評論

(^ω^)MG艺伎故事首页 南宁麻将计分规则 山西十一选五平台 2020年香港最快特马结果 一分赛车的技巧公式图解 离线单机三缺一麻将 贵州麻将的玩法和规则 闲来麻将游戏 宝马线路测试一mg 广西11选5一定牛 河南快3和值中奖金额 为什么我买五分彩提现不了 最火娱乐棋牌捕鱼 闲来麻将下载安装 宁夏十一选五任选 海南4+1技巧 北京快中彩计划软件手机版