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

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

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

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

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

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

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

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

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

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

我們先來(lái)一起了解一下權(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)品渠道、推廣活動(dòng)、或者是某一張單圖、某一張看板相關(guān)類型的，或者某張數(shù)據(jù)表、數(shù)據(jù)庫(kù)數(shù)據(jù)財(cái)產(chǎn)管理這樣的稱之為資源。后來(lái)的演變過程中，我們發(fā)現(xiàn)用戶開始有了組織的概念，比如說(shuō)你是運(yùn)營(yíng)組的，他是產(chǎn)品組的，功能權(quán)限會(huì)變成一個(gè)角色了?？赡苣闶枪芾韱T，或者是成員，或者是運(yùn)維人員、運(yùn)營(yíng)人員、投放人員，那么對(duì)應(yīng)的權(quán)限就會(huì)針對(duì)某一模塊的功能，做相關(guān)的拆分，對(duì)應(yīng)到相應(yīng)的角色。

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

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

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

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

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

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

這個(gè)是我們內(nèi)部的一個(gè)權(quán)限的改造，改造完之后能夠解決哪些問題？上圖中左邊部分可以看出這個(gè)是我們非常常見的一個(gè)權(quán)限管理系統(tǒng)的一個(gè)界面。我們公司內(nèi)部一些歷史上一些老系統(tǒng)的權(quán)限模塊基本就是長(zhǎng)這樣子。很多管理員都會(huì)找我們咨詢權(quán)限問題，因?yàn)樗麄冋娴牟恢廊绾问褂眠@個(gè)系統(tǒng)，關(guān)于有什么權(quán)限，需要找什么平臺(tái)，這些用戶都需要來(lái)找我們部門的人去幫他們查。

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

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

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

-END-