上一章我們說了產(chǎn)品設(shè)計方法，接下去我們來說第二點(diǎn)，關(guān)于隱私審批的設(shè)計。上圖中，位處左邊的展現(xiàn)的是我們關(guān)于隱私審計這一模塊功能的歷史情況，右邊是一個新的流程，360的數(shù)據(jù)還算比較合規(guī)，指的是什么？從系統(tǒng)功能開發(fā)歷史來看，我們從很早以前就已經(jīng)有相應(yīng)的審批功能了。所以在任何的時候，如果國家相關(guān)的部門需要過來查你的隱私相關(guān)的問題，我們基本上都不會出現(xiàn)什么紕漏。

簡單介紹一下歷史上關(guān)于隱私數(shù)據(jù)審批的流程?；臼沁@樣的一個情況，先是需要用到隱私數(shù)據(jù)的用戶，這些用戶需要先發(fā)郵件給我們公司內(nèi)部隱私部門的同學(xué)，然后隱私部門的人員需要挨個去審核相關(guān)的數(shù)據(jù)打點(diǎn)采集的詳情方案，判斷要采集哪些范圍內(nèi)的數(shù)據(jù)，是否觸發(fā)隱私事件。

然后，隱私部門的同學(xué)在分析完成以后，會回一封郵件說“同意”或者是“不同意”。如果回復(fù)結(jié)果是“同意”，接著這封郵件就會到我們部門來，由我們部門的人手工去調(diào)整線上的相關(guān)參數(shù)，調(diào)整完后，它的 SDK 就已經(jīng)屬于是被隱私審計控制過的。在其中就會存在哪些東西能采集，或者哪些東西不能采集的這樣一個情況，這就是歷史的情況，會牽扯到線上線下中各種各樣的問題。

隱私審計部門的同學(xué)也跟我們反饋說，其實他們歷史上審批過哪些業(yè)務(wù)或者哪些數(shù)據(jù)，其實他們已經(jīng)很難去核查了，說很多東西已經(jīng)跟蹤不到了。這種情況下，如果哪個業(yè)務(wù)存在問題，需要去翻很久的郵件，這樣會非常的痛苦。此外，業(yè)務(wù)同學(xué)也會有這樣的問題，說他們可能采集過一些數(shù)據(jù)，但是他們也已可能已經(jīng)記不清這些操作了。

因此，基于這樣的一個背景，我們決定把這一套流程做線上留存化了，這樣用戶在需要做數(shù)據(jù)審計的時候，就可以打開我們這個平臺，然后創(chuàng)建相應(yīng)的審批，可以直接去選擇需要省去的內(nèi)置屬性發(fā)送策略，同時他們也可以自己去添加需要審批的自定義的事件，發(fā)起相應(yīng)的審批。這些審批提交之后就會推送到隱私部門，不管審批結(jié)果的反饋是成功還是失敗，都會是在平臺上完成。

對于審批中的內(nèi)容修改也是這樣子的，用戶打開了記錄之后，可以去修改它的內(nèi)置屬性發(fā)送策略，還可以還修改相應(yīng)的制定意見，去申請相應(yīng)的審批。同樣，推到審批部門以后，會得到一個“成功”或者“失敗”的反饋，這個是我們平臺做出的關(guān)于隱私審批功能的一處創(chuàng)新。

我們通過改造以前的隱私審批方式和流程，推出了創(chuàng)新版本2.0。以前在定制審批內(nèi)容和流程的時候，它涉及到的是審批類似開關(guān)的控制，如果這個開關(guān)打開，那么這個事件相關(guān)的數(shù)據(jù)你就能采集了， 同時與你相關(guān)的其它所有事件的數(shù)據(jù)也都能采集。但是如果關(guān)掉這個“開關(guān)”的話，與你相關(guān)的所有事件數(shù)據(jù)又都不能采集，這樣就不夠靈活，會存在一些問題。

因為這個問題，后來我專門去問過隱私部門的同事，我問他們說，咱們有沒有哪個業(yè)務(wù)線的自定義事件的開關(guān)是關(guān)上的，他們告訴我“沒有”，如此一來，隱私審計的管控其實就屬于是有點(diǎn)形同虛設(shè)了，因為大家所授予的權(quán)限都比較大。因此，我們基本就是要制定和重構(gòu)這樣隱私審計相關(guān)模塊，做成了審批流程控制到每一個制定區(qū)間的明細(xì)，這應(yīng)該算作是一個創(chuàng)新。

另一個創(chuàng)新點(diǎn)屬于“添加自定義事件”，是針對員工使用做出的優(yōu)化，之前員工們都是手動去添加所有的自定義事件，然后再去發(fā)起相應(yīng)的審批。優(yōu)化之后，我們現(xiàn)在可以通過平臺自動捕獲到那個相關(guān)的打點(diǎn)事件，同事這些時間的信息會然進(jìn)入到發(fā)現(xiàn)池當(dāng)中去，這樣員工就可以自己通過發(fā)現(xiàn)池去發(fā)起相應(yīng)的隱私審批。

講完隱私審批，還有需要分享的是關(guān)于權(quán)限的創(chuàng)新。為什么我會想講權(quán)限創(chuàng)新？幾乎所有的公司都會有一個內(nèi)部的權(quán)限的設(shè)計，但是，據(jù)了解大多數(shù)公司關(guān)于權(quán)限的設(shè)計，要么是很復(fù)雜，要么是太簡單，不是很好用，不僅用戶用不明白，管理層也用不明白，我們就碰到很多類似這樣的權(quán)限系統(tǒng)，所以我們決定要從根本上去解決這個問題。

我們先來一起了解一下權(quán)限在是干啥的，它本質(zhì)上是在解決用戶和是權(quán)限之間的一種關(guān)聯(lián)關(guān)系，也就是給哪些人綁定到哪些權(quán)限上去。權(quán)限本身要能夠去拆分成“功能權(quán)限”和“資源權(quán)限”。

功能權(quán)限，指的是類似于是菜單操作或者是資產(chǎn)改善相關(guān)的東西；資源權(quán)限是與產(chǎn)品渠道、推廣活動、或者是某一張單圖、某一張看板相關(guān)類型的，或者某張數(shù)據(jù)表、數(shù)據(jù)庫數(shù)據(jù)財產(chǎn)管理這樣的稱之為資源。后來的演變過程中，我們發(fā)現(xiàn)用戶開始有了組織的概念，比如說你是運(yùn)營組的，他是產(chǎn)品組的，功能權(quán)限會變成一個角色了。可能你是管理員，或者是成員，或者是運(yùn)維人員、運(yùn)營人員、投放人員，那么對應(yīng)的權(quán)限就會針對某一模塊的功能，做相關(guān)的拆分，對應(yīng)到相應(yīng)的角色。

我們發(fā)現(xiàn)資源依然留在原地，假設(shè)我是個投放人員，有 A 游戲的投放的權(quán)限，沒有 B 游戲的投放權(quán)限，你也是投放人員，但是你有B游戲的投放權(quán)限，可有A游戲的投放權(quán)限，我們都是投放人員，所以我們的角色是一樣的，但是我們對應(yīng)的資源是不一樣的，這就就屬于是最老版的RBAC的原型。我不確定這個概念是什么出現(xiàn)的，反正我在十年前做第一個產(chǎn)品的時候，就是做的公司的權(quán)限系統(tǒng)，那時候我就已經(jīng)把公司的權(quán)重做成了第二個級別，那個時候沒有 RBAC，這些東西基本比我做相關(guān)的東西要晚至少 5 年左右才出現(xiàn)。

再后來我們慢慢發(fā)現(xiàn)，其實資源相關(guān)的配置，涉及到的點(diǎn)非常的多，如果一個一個去做那么工作量就會比較多，所以就涉及到一個“分享”的概念。目前市面上的很多產(chǎn)品能夠去做到，類似于某個員工能夠把相應(yīng)的資源做一些分享的還是比較少。比如，我們可能常見市面上的一些友盟、神策的數(shù)據(jù)看板，都會使用分享的設(shè)置給他 同事，同事在數(shù)據(jù)表、數(shù)據(jù)源也有配置有一些權(quán)限分享相關(guān)的功能相關(guān)，這說明這些公司在權(quán)限研發(fā)這一塊是做的比較好的。

基于這些，我們基于 RBAC 把資源相關(guān)的東西給抽離出來，然后做相關(guān)的分享功能，這也是對系統(tǒng)的升級操作。

接下去我們據(jù)說說說改造了哪些內(nèi)容?；诠緝?nèi)部的情況，首先我們會分析組織角色和分享需要改造的原因，公司內(nèi)部有 100 多個團(tuán)隊，部門太多了，這樣就很難通過一些簡單的組織設(shè)置就能夠完整的區(qū)分，因此我們這個組織就很有可能會有團(tuán)隊的概念在里面，也會有各種各樣的小組的概念，所以我們就做成了團(tuán)隊以及團(tuán)隊角色。

另外，因為我們內(nèi)部的產(chǎn)品應(yīng)用也非常多，有上百個吧，所以需要在應(yīng)用層面再做一個區(qū)分，我們就會有相應(yīng)的應(yīng)用跟應(yīng)用角色的一個拆分。

最后是有相應(yīng)的分享和組織分享的區(qū)分。這樣，對于某一塊內(nèi)容或者是資源，不僅僅可以分享給個人，同樣也可以分享給某一個小組。

這個是我們內(nèi)部的一個權(quán)限的改造，改造完之后能夠解決哪些問題？上圖中左邊部分可以看出這個是我們非常常見的一個權(quán)限管理系統(tǒng)的一個界面。我們公司內(nèi)部一些歷史上一些老系統(tǒng)的權(quán)限模塊基本就是長這樣子。很多管理員都會找我們咨詢權(quán)限問題，因為他們真的不知道如何使用這個系統(tǒng)，關(guān)于有什么權(quán)限，需要找什么平臺，這些用戶都需要來找我們部門的人去幫他們查。

他們也看不到相關(guān)的用戶列表，時間久了之后根本就不知道他們給誰開通過權(quán)限?？吹阶筮叺牟藛雾?，你發(fā)現(xiàn)功能非常多，用戶自己都不知道怎么去申請什么權(quán)限。然后權(quán)限的名詞概念也很多，用戶基本看不懂都代表著哪些意思。

針對這樣的問題我們對平臺做了創(chuàng)新的優(yōu)化，實現(xiàn)了團(tuán)隊、應(yīng)用、分享權(quán)限的可視化的管理需求，滿足了管理員可以隨時查看、改動和刪除的需求。而且，管理權(quán)限邏輯非常簡單，一看就會，一點(diǎn)就通。從目前的使用情況來看，我們的用戶來使用這個平臺上手真的是非?？?。

再看圖中右下部分的樹形結(jié)構(gòu)，會有一個團(tuán)隊管理、團(tuán)隊成員的管理。同時可以給團(tuán)隊配置相關(guān)的角色，在運(yùn)營和應(yīng)用的過程中，也會有相應(yīng)的成員改查角色一個流程，可以分享看板、單圖、數(shù)據(jù)報表等等資源上的東西，這個是我們做完改造之后的樣子，目前應(yīng)該是用戶使用起來非常的簡單，而且是審計非常容易，因為你可以隨時去查看，去管理，這個是我們的權(quán)限的創(chuàng)新。

-END-