本文中，筆者將結合自己參與產品重構以及做SaaS產品的實踐，與大家分享一些關于產品架構設計的思考，希望對你有所啟發。

作為一名產品助理，入職后剛好趕上產品重構，我也就“趁機”參與其中，主要負責將撰寫 PRD，與設計和開發對接。

那時的我對 SaaS 產品的理解很淺，甚至說對業務場景、產品定義、需求價值，沒有一套判斷標準和行為準則。但好在自己有一股沖勁，不停地做、不停地問，也就這樣跌跌撞撞地熬過來了。

隨后為了提升 SaaS 產品能力，系統地學習知識，并對以往的工作內容做復盤。一是反思當時產品團隊決策的正確性，二是希望自己能在接下來的工作中做得更好。

接下來，針對「產品架構設計」的這個問題，與你分享我的思考與方式，希望能與你交流。

01 產品架構設計的前提

產品架構設計的第一步，需要保證業務調研的結果，以及產品戰略上的定義是正確的。

對此最直接的方法，就是畫業務流程圖。這不僅可以將你腦中抽象的業務具象化，而且你可以拿著它直接與客戶進行溝通，明確你的理解是否存在偏差。

要知道 SaaS 產品的最大好處，就是需求一定存在于真實的業務中。因此，客戶能根據你的描述，判斷你的理解是否與他們真實的工作相符。不過這里也需要注意遺漏，畢竟一些頻率低的場景對方也是會遺漏的。

接下來，以我負責的 SaaS 產品為例，來介紹一下當時產品架構設計的整體過程。

1. 業務流程圖

我負責的產品主要面向的餐飲加盟行業，是將實體門店巡檢線上化，實現信息化管理。

總得來說是后端 PC 派發任務，前端 App 執行任務。

此圖在細節上做過改動，并不完全代表真實場景

找出最全的業務鏈條，從產品定位、客戶角色、業務流程、階段分布等多個角度繪制業務流程圖。

這樣做的好處是：

1. 對內可以清晰地闡述一條完整的產品鏈路，便于后續開發同事的技術支持；
2. 對外能夠系統化的向客戶展示設計的思路，利于對方指正錯誤。

2. 流程中涉及到的角色

大多數 SaaS 產品面向的不是單個的人，而是由一群具有通用特征的人群，組成的一個組織。

這類通用特征的人群，在現實中用「崗位」劃分，而對應到系統中就會用「角色」來稱呼。

其實本質是一樣的。

我們需要對業務調研結果進行整理，明確角色的描述、種類、工作內容、關注指標、行為邊界等信息。

這是因為系統早期沒有資源做權限模塊的設計，因此我們可以根據這些信息，在系統中預置這些角色的權限，在之后直接調用即可。

但需要注意的是，我們不能僅局限于一家企業，需要調研多家同類企業，做彼此間的交叉驗證以及通用整合。

最后將角色分為「通用類」和「個性類」兩種。

我們需要將精力重點用在通用類角色身上，個性類角色不是重點，甚至可以考慮用通用類角色替代個性類角色。

而具體在系統內的承載方式，可以考慮在人員部分加一個「崗位」字段值，用于承載通用類角色的權限。

一來用戶理解起來容易，二來在后面設計權限功能模塊的時候可以做到很好的替換。

不得不說，即使作為產品助理，心里也得有一張路線圖，需要能夠看到產品的全貌，需要走一步看兩步。

02 架構的設計思路

1. 將場景需求清單拆解到功能

場景需求清單是對實際業務場景的描述，產品經理需要將他們梳理分類，最后呈現出來。

下面是梳理出的 PC 端核心業務場景需求清單，這里重點考驗的是產品經理將需求翻譯成功能的能力。

但實際上，從客戶那里得到的業務場景遠比這個多，但對于公司來說不可能一上來就全部滿足。

因此 SaaS 產品最初的設計同樣遵循 MVP（最小可行化）原則，即完成核心業務場景的閉環。

在此基礎上先能讓客戶用起來，在這個過程中不斷的累加功能、完善服務。

況且客戶在系統上產生數據，實際上就是產生依賴，隨之用戶的替換成本也會一點點的提高。

2. 將功能按不同緯度進行分類整合

通用架構有兩種——「管理通用架構」和「商業通用架構」。

而我負責的產品顯然屬于管理類，因此這里我會先找出符合通用模塊的功能，進行歸類整合，避免重復造輪子。

由于剛開始的業務比較簡單，因此符合度很高，并沒有做過多的拆分。

不過相信你也發現了一個問題，就是數據管理中的這個「簽到數據」，它是從哪來的？

先介紹一下這個業務背景：

某企業的每個督導負責 10 家左右的門店，每天根據任務巡檢門店，除此之外還要處理一些門店的瑣事。

這就會導致督導在當天沒有完成對應門店的巡檢，而上級需要知道他們的行蹤。

對方目前的解決方案，是通過釘釘的簽到來完成。

而對方希望能逐步使用我們的系統完成，同時在一些個性化需求上，比如數據導出方面能夠滿足他們的訴求。

在考慮產品定位、需求 ROI 等信息后，最終選擇開發這個「簽到」功能，并將數據導出部分放在了數據管理里面。

話說回來，SaaS 產品的每一個功能，都是在明確解決一個具體的業務問題。因此在設計架構的時候，我們要注意功能模塊的包容性，而不是單純的累加。

當然還有一種情況，接下來隨著業務的發展，一定會出現不符合通用模塊的功能。

到那時，我會根據業務重要程度和復雜性單獨進行整合，例如任務管理模塊，目前在 App 端允許執行人將任務移交給他他人，但目前 PC 端并沒有記錄。

因此隨著后續的業務發展，會結合整改業務的部分，將任務管理整個抽離出來單獨形成一個模塊做設計。

當然這就是后話了，但我們要知道架構不會一成不變，它會隨著業務復雜程度的提高，慢慢地拓展成長。

3. 梳理模塊之間的邏輯關系

要知道業務是一個鏈條，上下游的銜接一定會產生數據。

因此我們可以將模塊分為兩類，一是存在基礎信息，但不產生數據流的「靜態模塊」，二是產生數據流通的「動態模塊」。

對于上面我提到的模塊，品牌管理、任務管理屬于靜態模塊，數據管理、數據看板屬于動態模塊。

數據從哪來到哪去，會在哪些節點發生變化，這些產品經理也需要做到心中有數。到此，就是我目前產品的架構形態。

寫在最后

這次產品設計的過程雖然存在很多問題，直到現在之前的坑都還沒填完。即使痛苦，但對我來說確實是一次巨大的成長。

而做這次復盤的目的，也是希望之后的我在做產品設計時，能思考的更加全面。

在產品這條道路上，我們很難做到避坑，但有意識地意識到自己的處境，及時調整與止損非常重要。

愿你我都能成為不“坑”的產品人，做出讓用戶滿意的產品。

 
作者：空；公眾號：小木盒產品記

本文由 @空 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Pexels，基于CC0協議