SaaS產品如何做好架構搭建?

編輯導語:搭建一個成功的SaaS產品,不僅可以給企業帶來很多好處,還能給客戶帶來更多價值。對於產品經理來說,發展到一定階段後,日常的工作內容往往離不開產品架構設計。這是一個極其細緻的活,需要產品經理有很強的架構能力。那麼,Saas產品如何做好架構搭建?

SaaS產品如何做好架構搭建?

我之前的一篇文章中講到過,一款Saas產品,產品架構搭建的好壞,對結果的影響截然不同。如果Saas產品架構搭建的不好,那麼帶來的直接結果就是:

客戶在完成某一個具體任務的時候,在整個操作的過程中,有一堆不相關的功能出現在客戶的操作頁面裡,導致客戶無法高效率的完成工作;

沒有一個框架性的產品架構指導,後面遇到的新需求,新功能,有可能會被後來的產品經理任意歸類,或者新建一個歸類來解決新問題,最終產品越做越亂;

隨著需求越來越多,需要開發的功能就越來越多,功能的耦合度也越來越高,然後開發難度就進一步增大,經常會面臨重新搭建架構的局面。

反之,如果架構搭建的好,那麼帶來的好處至少有以下幾種:

對客戶來講,看到的頁面都是簡潔的,能高效的完成任務,給客戶帶去價值;

架構搭建的好,客戶用起來好用,就會有更多的客戶願意用,給公司帶來了更多的商業價值。

不用由於架構搭建不合理而帶來的重構煩惱,以後的新需求、新功能基本上都能在架構內找到合適的位置;

公司能夠花費更低的成本來實現不同客戶的不同需求。

可見,架構搭建的好壞,對業務的影響是比較大的。那麼,如何才能把一款Saas產品的產品架構搭建好?

這裡,我們先對架構做一個定義:百度百科對“架構”的定義,裡面有很多技術語言方面的解釋,理解起來也比較麻煩。於是,我根據自己的理解,做了一個新的定義。

架構的定義是指:“根據架構搭建者對業務的理解,找出使用者需求,把使用者需求轉換為對應的功能,把功能按不同維度進行分類整合,並梳理出分類整合好的各個模組之間的邏輯關係,最終形成一個產品來解決某一類問題”,這就是產品架構。

這句定義裡有三個關鍵點:

對業務的理解,找出使用者需求,把使用者需求轉換為對應的功能,把功能按不同維度進行分類整合;

並梳理出分類整合好的各個模組之間的邏輯關係;

最終形成一個產品來解決某一類問題”。

透過對這3個關鍵點的理解與運用,對如何能搭建好一個Sass產品架構,你會有一個整體的認識,接下來我一個一個的講。

一、解決某類問題

先從第三個關鍵點開始聊,對於Saas產品來講,搭建好的產品是用來解決問題的,而且還是某類問題,這個“某類問題”就是戰略問題。

戰略對於產品,或者說對於產品經理來說,最重要的作用就是:知道要做什麼,不做什麼,很清晰或者大概範圍的知道要解決的問題的邊界在哪,然後在這個邊界範圍內去定義產品,設計產品,給客戶帶來價值,從而也給公司帶來商業價值。

關於如何梳理戰略相關的問題,可以參考我之前的一篇文章:《To B業務如何進行戰略梳理?》,這裡我就不細講如何梳理戰略問題了。

二、功能分類整合

戰略問題梳理好以後,接下來就到第二步:透過對業務的理解,找出使用者需求,把使用者需求轉換為對應的功能,把功能按不同維度進行分類整合,如何對Saas業務進行理解?

宏觀上,可以從行業定義的理解、行業的市場規模、行業發展所處階段、外部經營環境的分析(PEST)等維度來理解業務;

中觀上,可以從產業鏈上下游分析,企業競爭格局的分析、資源集中度、進入門檻的分析、標杆企業商業模式分析、Saas競品分析等維度來理解業務;

微觀上,可以從服務企業經營的業務,相關角色,工作流等角度來理解業務。

關於對業務理解的問題,我這裡講了一個思考框架。更詳細的業務理解問題,改天我會單獨寫一篇文章來深度講解,如何找使用者需求?

方法有很多,比如:

可以透過使用者訪談的形式找需求;

可以透過使用者調查的方式找需求;

可以透過深入一線,觀察、學習的方式找需求;

可以透過會議溝通的方式來找需求;

可以透過競品分析的方式來找需求等等。

關於找需求具體更詳細的理解,可以參考我之前的一篇文章:《B端產品需求的3個層次,你都瞭解嗎?》、《B端產品如何進行業務全場景的需求梳理?》。

如何把使用者需求轉換為對應的功能?使用者需求和軟體需求的區別是什麼?使用者需求對應的軟體功能是什麼?文章中都有講到。

如何把功能按不同維度進行分類整合?

這裡就是在做分類整合時的核心思想就是,一個大分類裡要用來解決一類問題。

比如,一款給餐飲商家用的Saas系統,後臺包括的功能模組有:商品、訂單、資料、營銷、店鋪、財務等模組,不管是現在還是未來,遇到商品需求功能,就要把功能歸類到商品模組;遇到營銷需求功能,就要把需求歸類到營銷模組;而不是沒有標準,亂放。

透過對業務的理解,找到了使用者需求,並把使用者需求轉換為功能,並對功能進行分類整合後,最終就會得到了一個功能結構圖。

例如,下圖就是某景區Saas產品透過以上方法梳理得到的功能結構圖:

SaaS產品如何做好架構搭建?

PS:為了方便理解,以上一二級模組細節內容有所刪減。

三、模組之間的邏輯關係

透過上一部分,我們已經找到了要做的功能,並把功能進行了分類整合,形成了一個又一個的模組。此時還不算完成產品架構的整體思考,因為一個又一個的產品模組獨立著,沒有連線在一起的效果就是:並不能發生什麼效果。

只有把各個模組有效的連線在一起才能實現目標,解決問題。這時,需要梳理出分類整合好的各個模組之間的邏輯關係;如何梳理各個模組之間的邏輯關係?

可以用資料流轉過程來梳理,還是以文章中提到的景區Saas產品為例:

景區想要賣票,那首先應該在門票管理模組上傳門票,管理門票;

上傳的門票資訊會進入店鋪中,供遊客檢視、購買;

遊客透過店鋪購買完門票以後,就會生成訂單資訊,進入訂單模組;生成財務資訊,進入財務模組;生成資料資訊,進入資料模組。

最後,透過資料連線,就能把各模組之間的邏輯關係梳理清楚了,最終形成的產品架構圖如下:

SaaS產品如何做好架構搭建?

PS:為了方便理解,以上的邏輯思考圖,有所刪減。

這裡補充個話題聊一下:“關於搭建產品架構時,我們是否有相似的解決方案可以參考?”

雖然說,每家公司的每條業務根據行業、機會、自身能力等情況的不同,梳理出來的戰略基本上都不一樣,搭建出來的產品架構也就不一樣。

但是,我們把這些所有的不一樣,給抽象思考,分類整合一下,基本上可以發現所有公司做的Saas產品,基本上都屬於兩大類(以下分類目的,是梳理出產品要解決的問題大概屬於什麼型別,然後我們在搭建產品架構時,可以找到類似的解決方案來參考):

PS:隨著創業公司業務的發展,這兩大類會有合二為一的情況存在,也就是Saas產品裡包含了多個垂直行業的多個業務場景的多個解決方案。

1. 業務垂直型

業務垂直,可以這樣理解,Saas產品要解決的問題是一家公司商業系統中的某個系統,也可以這樣講,要解決的問題是一家公司價值鏈的某個環節問題。

可能理解起來比較抽象,這裡我舉兩個例子講講。

比如:在製造行業,一家公司的商業系統會是這樣的,研究開發——採購——製造——營銷——銷售——服務;在廣告行業,一家公司的商業系統會是這樣的,購買媒體——開發客戶——商品企劃書——企劃銷售——廣告製作——實施、評論。

這兩個案例就是製造行業和廣告行業商業系統情況的一個介紹(或者是製造行業和廣告行業價值鏈相關環節的一個介紹)。做Saas創業的公司,會把整個大的商業系統中的某一個或多個小系統單獨提取出來,給出相應的Saas產品解決方案,這就是業務垂直型。

現在比較通用的業務垂直型Saas產品,解決的業務問題,大概都有:

如果,你解決的是業務垂直型相關的業務,那麼每一個業務垂直型相關的問題,你都可以找到相關的書籍、競品等來看,看看類似的產品是如何搭建架構的,可以學習,參考。

2. 行業垂直型

行業垂直型,就是你公司Saas產品要解決的問題是某個垂直行業相關的問題。

比如:

解決行業垂直型問題時,可以透過以下兩個框架去思考:行業產業鏈+企業價值鏈。

首先進行行業產業鏈的思考,可以得出的結果是,能清楚的知道公司要解決產業鏈裡哪個經營主體的業務問題。知道要解決哪個經營主體的問題後,接下來要思考的是,要解決經營主體哪個或者哪幾個價值鏈環節的問題。

比如,你想進入的是旅遊這個垂直行業,首先你進行產業鏈分析,整個旅遊產業鏈,大概可以分為4個環節:上游供應商(包括景區、酒店等等)——渠道商——媒介和營銷平臺——使用者。

透過各種分析、評估後,你決定要幫助經營主體景區解決業務相關的問題。接著,你進一步思考,需要幫助景區解決什麼業務問題呢?

這時就要梳理出景區的價值鏈包含的有哪些模組,經過梳理,你得出大概包括:生產、營銷、銷售、服務、人力資源管理、財務管理等等。

再透過各種分析,你決定幫助景區解決銷售、營銷和服務環節的問題,最終設計出Saas產品來解決景區銷售、營銷和服務環節的問題。如何解決銷售、營銷、服務問題,你可以透過找到相關的書籍、競品來參考,看看類似的產品是如何搭建架構的,可以學習,參考。

這裡總結一下:就是不管是做業務垂直型的Saas產品,還是行業垂直型的Saas產品,它終究都要回到價值鏈的某個環節裡去思考,思考要幫助企業解決什麼業務問題。

然後針對這樣的業務,參考比較成熟的產品是如何搭建架構的,我們可以去參考、借鑑。最後,關於Saas產品如何最好架構搭建的問題就講到這裡了,希望對你有所幫助。

#專欄作家#

豐憲飛,微信公眾號:小飛哥筆記,個人微信:f1506620495。人人都是產品經理專欄作家。某網際網路創業公司合夥人兼產品總監,多個專案“從0到1”專案負責人,擅長戰略、運營、產品的整體規劃及落地執行。

本文原創釋出於人人都是產品經理,未經允許,禁止轉載。

題圖來自Unsplash, 基於CC0協議。

頂部