如何從產品架構層面去設計SAAS產品

作者: leo 分類: 精彩設計 發布時間: 2020-01-20 09:12 ė111次查看 6沒有評論
曾經有面試官給出過這樣一個問題,“如果給你做一個SaaS產品,如何從產品架構層面去設計?

圖1 what
當醫微達聽到這個問題的時候,腹誹了一下,確定這個問題的每個字我都認識,每個詞組單獨拉出來我也能清晰的理解,但是組合起來就有點費解了。所以醫微達委婉的說道:“不好意思,能再解釋一下嗎?”

圖2?sorry
面試官可能看出了疑惑,不知道要回答些什么,然后說,“就是讓你負責做一個SaaS你都會做些什么,比如有哪些模塊?”這么一說,醫微達就懂了,這里要注意,參加面試的朋友遇到開放式命題的時候,第一點要表述的一定是設定場景。這里有兩個好處,第一是盡可能設定自己熟悉的場景,避免犯錯,第二是面試官如果覺得這個場景過于簡單,會給出他想要的場景,這樣就能更加清楚的了解面試官希望你回答的范疇在哪。

醫微達設定的場景是比如說我們做的是一個電商場景的SaaS,這個產品類似于有贊,那么經過了一系列需求收集分析后,針對電商場景,簡單的劃分為前臺用戶端,后臺商家端,平臺管理端等端口。

用戶前臺和用戶后臺

用戶端的核心業務流程就是瀏覽商品>下單>支付>發貨>收貨>評價>訂單完成,商家端的核心業務流程有幾個,分別是用戶管理、商品管理、供應商管理、營銷活動、訂單、支付、快遞、財務、數據報表等等。

面試官聽完之后又問道:“那你是依據什么構建的這個產品框架的呢?或者說基于什么原因這么劃分模塊?”,醫微達回歸到現實工作中,如何劃分這些模塊的依據或者來源大致可以分為:1.競品分析;2.需求分析;3.流程梳理。

三種方法

通過競品分析,我們能知道在一般情況下別人是怎么做的,我們不能說他都是對的,但是必定有其道理,如果只是去看別人有什么你就要有,那這是不可理喻的,要分析他為什么要這么做,找到一個根本原因或者依據,而不是一句“存在即合理”就解釋了。醫微達認為在產品的實際工作中,很多產品經理要做的產品都已經珠玉在前了,重新制造一個輪子并不能說它一定是毫無意義,但是絕大多數企業確實是毫無意義甚至還不如前者。美其名曰借鑒,其實就是抄。當然抄也不是全都照搬,也會根據實際的業務情況、資源配置等等因素去權衡,優化或刪減,從而達到既符合企業定位、滿足市場需求的同時,又能為產品節省資源。

需求分析,這也是醫微達常說的,但是在需求分析的過程中我們可以做很多,其中用戶訪談,是醫微達認為做SaaS或者做定制化產品很常見的。

比如在做財務系統時,與財務總監、會計、出納溝通,甚至還需要與CFO、法務溝通,在了解財務的工作內容的時候,就可以通過他們的一些工作習慣和認知,去定義或劃分功能模塊。這也與尼爾森的“一致性原則”中與用戶預期保持一致性相同,甚至也可以說這是與現實映照。

流程梳理,其實這也是需求分析中的一個必然步驟,之所以拉出來說,是因為在做SaaS的時候,有些業務的模式的創新性導致沒有一般等價物作為參照,我們需要根據實際商業模式去設計適合他的業務流程和規范,并且為之提供切實有效的系統作為商業開展的保障。在梳理整個業務流程的時候,有哪些場景、哪些角色、哪些流程對應的都需要什么,抽象出來,一目了然。

比如審核,一般SaaS產品都會有工作臺,有審核模塊,將用戶可見、參與的審核信息聚合統一處理,并且大一些的SaaS組合產品會將流程引擎與審核中心獨立成SaaS產品給各業務引用,這都是在流程梳理時,通過抽象聚合出來的。

醫微達再次重申這個問題:“如果給你做一個SaaS產品,如何從產品架構層面去設計?”這里面有兩個名詞:SaaS產品,產品架構

那么什么是架構呢?醫微達查了百度詞條顯示:架構,又名軟件架構。軟件架構(software architecture)是一系列相關的抽象模式,用于指導大型軟件系統各個方面的設計。軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段,這些抽象組件被細化為實際的組件,比如具體某個類或者對象。在面向對象領域中,組件之間的連接通常用接口(計算機科學)來實現。

翻譯成一個詞就是高屋建瓴,大白話就是從整體上,將軟件高度抽象成組件,通過架構圖直觀的去表達所規劃軟件的各個組件以及各個組件之間的關系,并傳達軟件的業務流程、數據流轉。在老王看來,從商業的角度來說,制定一個商業模式也算是一次架構,從企業角度來說,部門的設立與調整也是一次架構。看一下醫微達畫的一個架構圖,想來能有一個較為清楚的認知了。

圖7 三層架構圖

那么產品架構是什么呢?這里我們只討論互聯網以及軟件產品經理的思考,從整體上規劃產品,將具象化的產品功能或業務高度抽象并清晰的表達,從產品設計上高度契合軟件架構所要達到的效果。軟件架構的非功能性特征包括:可靠性;易用性;可擴展性;強壯性;靈活性;性能等等。那么,在做產品規劃與設計時,也必須時刻關注這些非功能性特征。

在我們了解了這些之后,再來看這道題就變成了:從整體上規劃、設計一個SaaS產品,將具象化的產品功能或業務高度抽象并清晰的表達。雖然分析到這個地步了,但是貌似也沒有拿出一個實際有效的答案,屬實有點尷尬。在老王看來,這個時候畫一個產品架構圖來就最好了,但是面試嘛,更多的是口頭表述,那醫微達就拋磚引玉一下吧。

“針對這個問題,我想首先擬定一個場景,我們假定要做一個電商SaaS產品,那么作為SaaS產品,一般是要具有一些行業通用性,假設我們已經做過了用戶調研、競品分析、需求分析,得出了以下幾個需求:1.用戶購買商品;2.商家管理商品并且需要給用戶發貨;3.用戶收到貨物會評價等等。”

“那么,在經過上述分析之后,我們可以得到一些內容:這個產品至少有三個角色,用戶,商戶,公司,也就至少有三個終端,我們分為用戶前臺、商戶后臺、公司運營平臺。那么前臺都需要些什么呢,需要商品展示、支付、訂單查詢、評價,甚至是商品的分類和搜索,未來可能還有會員體系等等。”

“商戶后臺,根據需求,需要用戶管理、商品管理、訂單管理、評價管理、供應商管理,未來還會有營銷、財務、數據、倉儲、物流等等等等,這些模塊或者系統來支撐商戶后臺。公司運營平臺也會有客戶管理、訂單管理、財務管理等等一系列模塊或系統。”

“以上其實就是一種產品架構,這是從功能模塊來劃分的,當業務進一步做大的時候,技術得到了一定的發展,就需要從產品、服務和技術層面去規劃產品架構,這個就類似于編程中的MVC框架,對應的產品表現層、服務邏輯層、數據服務層。”(這里大家的叫法和用法都有所區別,不過都是對應MVC中的model-view-controller這種結構)

“至于劃分依據,有幾個方面:1.競品分析,根據該領域頭部玩家的經驗,在其基礎上去優化沉淀自有品牌的優勢;2.需求分析,在于客戶或行業資深專家的溝通中,不難發現一些行業規律,依照行業規律劃分也是符合用戶行為習慣的;3.流程梳理,在梳理的過程中根據流程的必要性,以降低耦合為目的去劃分和提煉必要的模塊和功能。”

醫微達相信大部分產品經理其實很少正經做產品架構,日常的工作更多的是接到需求,分析需求,然后設計產品。但殊不知又時刻與產品架構保持聯系,因為你的每一次新增、改動都會影響整個產品的架構。醫微達建議可以試著做一個產品架構,不一定從無到有,也不一定要面面俱到,只要將現有的產品或者模塊遵照MVC的三層關系,去抽象并且清晰的表達你所做的產品與其他產品或模塊的對應關系和一來關系,就可以了。

0

本文永久鏈接: http://www.allfriendz.com/17622.html

發表評論

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

微信二維碼
全國分支機構
  • 電話:400-888-9746
  • 郵箱:醫微達郵箱地址
  • 網址:www.e-wangbao.com
  • QQ:2021627922
  • 青島總部地址:青島市北區開封路88號百洋科技園6樓
  • 上海地址:上海長寧區長寧路1027號3308室
  • 北京地址:北京市東城區東長安街1號東方廣場E1-21層

醫微達攻略 |  微營銷分享 |  案例分享 |  服務資費 |  了解醫微達 |  友情鏈接

在线观看国产高清免费不卡