實體設計:如何將復雜系統進行抽象架構設計?

4 評論 5380 瀏覽 44 收藏 15 分鐘

本文深入探討了如何從復雜的需求中抽象出核心問題,將復雜的功能抽象成簡潔易用的設計,以及如何將復雜系統進行場景化架構設計。通過具體案例如HR SaaS產品,一步步拆解實體設計的六個步驟。

在SaaS產品的世界里,抽象能力不僅是構建高效解決方案的基石,更是推動創新和滿足用戶需求的關鍵。我們已經探討了如何從復雜的需求中抽象出核心問題,如何將復雜的功能抽象成簡潔易用的設計,以及如何將復雜系統進行場景化架構設計。今天,我們將深入探討一個經常被忽視但同樣重要的領域:實體設計。

實體設計,在SaaS產品中,指的是將抽象的概念轉化為具體、可操作的對象或模塊。它不僅關乎產品的外觀和感覺,更關乎產品如何在實際中運作,以及如何與用戶和其他系統交互。實體設計的好壞,直接影響到產品的用戶體驗、性能和可維護性。

讓我們開始這場實體設計的探索之旅,看看它是如何將抽象的構想轉化為具體的產品價值。

它主要分為六步:

  • 第一步:構建場景化產品架構:基于用戶場景,抽象產品結構
  • 第二步:構建關鍵角色流程:依據角色工作流,抽象產品流程
  • 第三步:提取關鍵實體:從產品架構與流程中提取所有關鍵實體
  • 第四步:關聯實體關系:對不同實體,建立相應的關聯關系
  • 第五步:豐富實體設計:補充缺失實體,完善實體關系和屬性
  • 第六步:場景驗證與調整:根據用戶場景和需求,驗證并調整實體結構的擴展性

咱們還是以HR SaaS產品為例,一步一步拆解,希望對你有所啟發。

第一步:構建場景化產品架構:基于用戶場景,抽象產品結構

實體設計依賴于產品架構設計,兩者共同構成產品架構的完整視圖。

產品架構圖是靜態的,為實體設計提供基礎;實體設計圖則是動態的,實現產品架構的具體化。有關產品架構圖的詳細內容,可以參考“如何將復雜系統進行場景化架構設計”一文。

第二步:構建關鍵角色流程:依據角色工作流,抽象產品流程

HR SaaS的關鍵角色是HR,其次是決策者(即CEO/HRD),再次是業務管理者(即部門/門店負責人),最后是員工。

以考勤業務為例。

我們將創建關鍵角色的主要流程圖,重點關注考勤HR和業務管理者。

建議:為每個角色繪制獨立的流程圖,以便更清晰地理解其工作流程和場景。特別是對新產品伙伴,避免像我一樣偷懶。

第三步:提取關鍵實體:從產品架構與流程中提取所有關鍵實體

這一步的關鍵是基于產品架構和用戶流程圖進行“按圖索驥”,提取所有相關名詞,確保它們相互獨立且不重復。

每個實體應像工種一樣,擁有獨特的名稱和在系統中的明確職責,理想情況下,每個實體負責一個特定的功能。

以考勤業務為例,各個模塊的獨立且不重復實體情況如下:

  • 考勤管理:員工、考勤檔案、考勤確認規則;
  • 排班管理:員工、排班日歷、節假日、班次時間、排班組、排班規則;
  • 假期管理:員工、假期規則、請假記錄、請假審批、假期余額;
  • 加班管理:員工、加班規則、加班審批、加班記錄;
  • 調班管理:員工、調班規則、調班記錄、調班審批;
  • 出差/外出管理:員工、出差/外出規則、出差/外出記錄、出差/外出記錄;
  • 工時管理:員工、工時規則、工時記錄;
  • 設置:考勤周期、考勤機、出勤規則、打卡規則、打卡記錄、補貼規則、補貼記錄、扣款規則、扣款記錄;
  • 班次設置:班次、班次組、循環模版;
  • 報表:員工、字段、日報、月報

第四步:關聯實體關系:對不同實體,建立相應的關聯關系

每個實體作為一個靜態名詞,只有通過賦予其明確的職責和合作關系,才能發揮價值,就像職位一樣,需要明確的分工和與上下級、同級的協作,以產生有效的成果。

實體關系通常分為三類:1對1、1對N、N對N。利用這三種關系,我們可以關聯實體,實現它們之間的協同。

第五步:豐富實體關系:補充缺失實體,完善實體關系和屬性

實體設計的價值是在靈活性、體驗性和擴展性之間進行權衡。實體的獨立性、關鍵屬性設計以及實體間的關系共同塑造了實體架構,影響其效率和適用性。

所以當你在設計實體架構圖時,可通過以下四個方向進行豐富:新增子實體、拆分關鍵實體、完善實體關系、完善實體屬性。

首先是新增子實體

在大框架設計中,深入特定場景流程后,可能發現實體缺失,影響場景的靈活性、擴展性或體驗。

比如假期管理可按類型分為年假、事假、調休等多種假期,按額度分為有余額和無余額,按計算方式分為按工作日或自然日計算。為此,可新增“假期模板”子實體,提供自定義假期。

第二是拆分關鍵實體

比如加班是一個關鍵場景,則可將【加班規則】實體進一步拆分為:計算規則、補償規則、限制規則、舍去規則、使用規則,每個子規則負責一個具體的功能。

或排班也是一個關鍵場景,則也可增加不同維度的實體。

第三是完善實體關系

實體關系的設計對實體架構的擴展性和用戶體驗有直接影響。

比如出勤方案與排班規則可以設計為N對N的靈活關系,也可以是N對1的簡化關系。N對N關系提供最大靈活性,允許每個出勤方案獨立關聯多個排班規則;而N對1關系將排班規則視為整體,犧牲靈活性以簡化配置。

相關案例與示意圖,可見:功能設計2:如何將復雜的功能抽象成簡潔易用的設計?

第四是完善實體屬性

關鍵屬性的設計對實體架構的擴展性和用戶體驗,也有直接影響。

比如適用范圍作為規則/方案的關鍵屬性,決定了哪些人適用于哪些規則??梢栽O計每個規則有獨立的適用范圍以增加靈活性,或者讓關鍵實體如出勤方案擁有適用范圍,其他規則實體共享,從而簡化規則的管理。

相關案例與示意圖,可見:KISS原則:SaaS產品設計最重要的原則(上)

第六步:場景驗證與調整:根據用戶場景和需求,驗證并調整實體結構的擴展性

當實體架構設計完成后,避免考慮不周全的情況,以我的經驗的話,就會用目前可以想象到的所有場景來進行“驗證”。

這就像是一個思想實驗一樣,你把整理好的(目前)所有已知場景,分別代入到你的實體設計中進行驗證。

一般驗證三部分:體驗性、靈活性、擴展性。

第一是體驗性

基于用戶流程,進行完整場景式的演繹,看看在現有流程中,是否體驗足夠好。

比如考勤HR在配置各類規則時,我們可以有兩種不同思路:

  • 思路1是每個規則相互獨立,相互之間無關聯。比如打卡規則、出勤規則、加班規則等,都有自己不同的適用范圍,互不影響;
  • 思路2是每個規則組合使用,由一個中間實體(即考勤方案)進行統一管理,共享同一個適用范圍。

從用戶體驗角度,思路2優于思路1。這類似于與客戶對接時,思路2只需對接一人,而思路1則需對接多人,顯然更繁瑣。

第二是靈活性

確保系統能適應不同客戶場景,保持用戶操作自由度。 在HR考勤管理中,除了執行考勤規則,還需對分區域/部門的員工考勤數據進行糾錯、歸檔和確認。例如,北京總部員工由張三管理,而成都、武漢、重慶等分公司員工由李四管理。每月確認出勤后,數據交給王五進行工資發放。

  • 思路1:考勤方案兼職多能,同時負責權限劃分。例如,北京總部員工使用考勤方案A,由張三管理;成都、武漢、重慶員工使用考勤方案B,由李四管理。
  • 思路2:考勤組專職專能??记诜桨竷H負責規則制定,數據管理由考勤組獨立負責。例如,北京總部員工屬于考勤組1,由張三管理;成都、武漢、重慶員工屬于考勤組2,由李四管理。

從自由度看,思路2在自由度和效率上優于思路1,類似于職場中的專職專崗,職責明確,工作安排靈活。

第三是擴展性

如果體驗性和靈活性無法兼得,需考慮當前架構設計的可擴展性,確保以最小成本進行后期擴展,避免前期成本低但后期難以擴展的方案。

排班管理是考勤的核心功能之一,不同行業/企業需求各異。例如,制造業排班可能按時間規律性交替或按任務量調整;復雜度高時,員工只需選擇白班或夜班。門店連鎖行業則常見小時工不固定上班時間,正式員工常支援、調店/調班。

延伸場景包括按人員排班、按任務排班、按小時排班,支援調班、調店調班等,以及自動規律性排班和指定周期內自動復雜排班。

如果當前實體關系架構,不支持快速擴展,則需考慮調整。

總結一下

本文主要分享了如何將構想轉化為具體的實體架構設計,介紹了設計的六步:

第一步:構建場景化產品架構:基于用戶場景,抽象產品結構。關鍵動作是基于用戶場景繪制全景產品架構圖;方法論是【以終為始,全面設計;以始為終,最小閉環】。

第二步:構建關鍵角色流程:依據角色工作流,抽象產品流程。關鍵動作是明確產品的所有服務角色,根據產品階段確定角色優先級,并繪制關鍵角色流程圖;

第三步:提取關鍵實體:從產品架構與流程中提取所有關鍵實體。關鍵動作是找出產品架構與角色流程中的所有關鍵名詞;

第四步:關聯實體關系:對不同實體,建立相應的關聯關系。關鍵動作是把所有關鍵名詞用三種關系(即1對1/1對多/多對對)進行關聯,讓它們相互實現協同;

第五步:豐富實體設計:補充缺失實體,完善實體關系和屬性。關鍵動作是查缺補漏實體關系,該加則加,該刪則刪;

第六步:場景驗證與調整:根據用戶場景和需求,驗證并調整實體結構的擴展性。關鍵動作是收集足夠需求場景,進行逐一驗證,并在體驗性、靈活性與擴展性之間進行權衡取舍。

專欄作家

邢小作,微信公眾號:邢小作之家,人人都是產品經理專欄作家。一枚在線教育的產品,關注互聯網教育,喜歡研究用戶心理。

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

題圖來自 Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 專業

    來自廣東 回復
    1. 專業不敢說,更多是從自己實際工作進行總結和分享,也期待更多碰撞跟交流

      來自北京 回復
  2. 你可以參考下togaf的設計模式,雖然比較重。有一點想要說明下:
    1.實體作為UML中的語言,和DDD中的概念模型,togaf中的業務對象的概念比較接近。但是這幾種方法中,規則不屬于實體、概念模型或者業務對象。規則屬于通用的方法。

    來自浙江 回復
    1. 感謝推薦,空的時候了解下你說的togaf

      來自北京 回復