權限是一個公司信息系統的起點。我從入職以來就一直想要對公司后臺的權限系統進行一個梳理（其實是老板要求的），苦于對后臺和公司業務還不夠了解，所以想法一直沒能成型。終于，經過幾個月斷斷續續的琢磨，我趁最近需求數量不多的時候，把權限的調整方案梳理了出來。
這次梳理公司后臺的系統，我在原有權限系統的基礎上引入了 公司組織架構，形成了 動態權限管理模式，使得公司的權限管理更加合理化。目前已經把方案提交給開發進行審核，希望可以最終落實。這里就先向大家匯報一下這幾個月以來梳理權限的成果，給同樣有權限體系設計問題的朋友們一點參考。
要設計權限，首先要對權限 已有的成熟方案有一定認識，其次要 對業務有深入的分析，才可以在業務的基礎上有針對性的設計權限模型。
關于權限成熟方案，我查了很多資料，主要了解了一些關于 RBAC（Role-Based Access Control）權限模型的知識。加上在前司對SharePoint的權限分配方案有一定的了解，權限的知識基本就已經足夠了（不夠也沒有更多了，找到一篇從產品的角度解釋RBAC的文章，值得一讀：請點擊查看）
關于業務需求分析方面，我對公司后臺的權限系統做了梳理。
因為公司對數據的保密要求很高，所以后臺有大量查看項目、查看投資人的細致權限設置，但是 缺乏一致的管理方法，導致經常出現有需求無權限，或調動后權限沒有及時清除的問題。公司后臺主要是按照RBAC設置了權限體系，另外還根據項目服務小組的機制為每個項目單獨設置了權限。后臺RBAC的權限角色中，有部門角色、功能角色、臨時團隊角色等等，相對比較混亂。
現在這套系統面對一些問題：
權限角色太多，分類混亂。有大量臨時建立棄而不用的分組；如果員工調換部門，需要逐個刪除他已有的權限，再逐個賦予新部門的權限；如果部門領導更換，需要對部門內員工的所有成員的審批對象都進行調整。
為了解決上述問題，我嘗試將公司的 組織結構信息引入權限管理的系統。
盡量以部門為單位分配權限，權限角色過多混亂的情況；出現員工部門調動或領導更換，會根據其部門更改自動重新分配權限；對無法按照部門分配的功能采取原有的權限分配模式，通過給不同的員工分配不同的角色實現，保證靈活性。
從上述的思路出發，我定義了新的權限管理需求。新的權限管理分為 部門權限制度和 非部門權限制度兩種：
1、部門權限制度
部門權限分組默認按照組織結構圖。
按照小組設置部門，部門分管理者權限和默認權限兩種，默認權限為部門管理權限的子集。
若組織架構中的小組設置了管理者，則管理者默認擁有管理者權限。除管理者外，所有人加入小組后默認擁有默認權限。
（2）管理者權限包括
部門權限維護類：新建子權限組、默認權限維護、打破權限集成等權限（可以分配給部門領導使用，也可以掌握在超管手中統一分配） 審批類：所有報銷、請假和購票的申請（若小組沒有設置管理者，則小組成員所有審批事宜由上級層級中的管理者負責 ） 職能類：單個部門的全部權限
（2）權限維護類權限詳細介紹
子權限組：部門內可以根據員工設置子權限組，根據子權限組，分配部門權限；默認權限維護：增刪進入部門所默認擁有的權限；打破權限繼承：使某位員工失去默認擁有的權限，為其單獨分配權限。
2、非部門權限制度
組織方法參照原有RBAC權限管理；
超管可以為單個員工或小組開啟非部門權限。
可以為非部門權限設置有效時間段；若員工調轉部門，則所有非部門權限默認失效，需要超管審批以后方可重新生效。
這套規則可以基本解決原來的權限與部門沒有關聯的問題，以及權限分配混亂難以管理的問題。這僅僅只是產品從業務角度梳理出來的需求，具體實現還需要和開發商量以后解決。而且要真正能夠落實實現還需要很漫長的過程。
這次設計方案給我最大的體會就是，設計復雜的功能最有效的手段還是 從具體是使用場景出發，使用場景決定業務邏輯，業務邏輯決定功能邏輯。我在最初設計的時候執著于尋找成熟的權限管理模式套用，后來發現這樣生搬硬套不能提升后臺權限分配的效率。在過后的幾個月工作中，我接觸到了不少分配權限的實際問題，比如不知道分權限給誰，或者分配出去的問題沒有辦法管理的問題。這些問題直接啟發我引入了公司組織架構的概念，也便有了這套方案。
所以， 產品的設計與實現都服務于使用場景，才是真正好的產品，這一點對業務為導向的后臺產品至關重要。與大家分享，也請大家多提意見。