讀書筆記《To B 產(chǎn)品之美 》一 趙世哲
讀書筆記《To B 產(chǎn)品之美 》三 趙世哲

第5章 需求分析與模型推演

需求的四要素

需求就是未被滿足的碎片化的期望。

1. 主體 需求的主體是人或事物耿眉。主體分為直接主體和間接主體抚垄。
2. 場景 需求的場景指需求產(chǎn)生的條件唁奢，包括但不限于環(huán)境、時間推沸、地點等，只有滿足條件，需求才能成立
3. 目的 需求的目的可能是隱性的傻粘。
4. 價值 需求被滿足，被滿足者得到了價值 帮掉，與此同時作為回饋弦悉，需要另一種價值形式補償給解決方案提供方，這是最基本的價值回饋形式蟆炊。

需求的獲取和管理

需求分為主動需求和被動需求：主動需求是產(chǎn)品經(jīng)理通過對問題進(jìn)行診斷或通過機會識別提取出來的稽莉；被動需求是客戶提出來的，也可以是產(chǎn)品本身發(fā)生了異常涩搓，從而暴露出來的污秆。

SaaS產(chǎn)品搭建初期和穩(wěn)步迭代時間，獲取和管理方法

搭建初期

獲取需求的本質(zhì)是識別需求昧甘、機會或風(fēng)險良拼，主要通過調(diào)研客戶、對標(biāo)標(biāo)桿企業(yè)或產(chǎn)品充边、數(shù)據(jù)分析等手段獲取需求庸推。

1. 調(diào)研客戶
2. 對標(biāo)標(biāo)桿企業(yè)或產(chǎn)品
3. 數(shù)據(jù)分析

穩(wěn)步迭代時期

1. 客戶反饋的需求
2. 異常問題轉(zhuǎn)化為需求
3. 產(chǎn)品經(jīng)理主動優(yōu)化

需求調(diào)研和分析

1. 涉眾 我們獲取需求之后，首先想到的是這些需求涉及哪些人浇冰，也就是涉眾贬媒。
2. 干系人 產(chǎn)品往往涉眾眾多，我們將其中全程關(guān)注產(chǎn)品建設(shè)的稱作干系人肘习。
3. 客戶 客戶屬于涉眾掖蛤，也是重要的干系人【幔客戶的屬性分為4種蚓庭。
   1）自然屬性 產(chǎn)品的客戶可能來自不同行業(yè)，具備不同的自然屬性仅仆。
   2）角色屬性 無論客戶的自然屬性如何器赞，在接觸SaaS產(chǎn)品時，都是以某一個身份進(jìn)行作業(yè)的墓拜。
   3）組織歸屬屬性 一個角色從屬于一個組織架構(gòu)港柜，帶有自身利益的權(quán)限邊界。
   4）活動范圍屬性 產(chǎn)品功能是為幫助特定的角色完成特定的業(yè)務(wù)行為而設(shè)定的，當(dāng)客戶以某種角色使用產(chǎn)品時夏醉，其活動范圍 是相對有限且確定的爽锥，不是無限開放的。

需求的七步循環(huán)

需求實現(xiàn)路線的七步循環(huán).png

1. 需求作為觸發(fā)點
   需求通過用例模型表示畔柔，用例模型是由用例圖和用例的詳細(xì)描述文檔組成的氯夷。
2. 需求演繹出業(yè)務(wù)場景
   演繹法是一種從整體以個體的推理，實際上就是要窮舉需求背后的場景靶擦，也就是業(yè)務(wù)場景腮考，舉一反三。
3. 基于業(yè)務(wù)場景總結(jié)業(yè)務(wù)域
4. 基于業(yè)務(wù)或抽象概念模型（業(yè)務(wù)模型）
   概念模型主要描述的是業(yè)務(wù)的組絹及運作的結(jié)構(gòu)和邏輯玄捕。
5. 業(yè)務(wù)模型到功能模型
   功能模型是對功能要執(zhí)行的任務(wù)進(jìn)行直觀的表達(dá)踩蔚。
6. 功能模型和功能的實現(xiàn)
   實現(xiàn)功能模型還需要經(jīng)過撰寫產(chǎn)品需求文檔、研發(fā)枚粘、測試等環(huán)節(jié)馅闽。功能實現(xiàn)之后，是否能滿足需求馍迄，還需要經(jīng)過驗證福也。

概念模型5個要素

• 實體 客觀存在并且可以相互區(qū)別的事物，在繪制概念模型之前需要先找到目標(biāo)實體柬姚。
• 屬性 實體所具有的某一特性。例如學(xué)生可以由學(xué)號姓名庄涡、性別量承、籍貫、系穴店、入學(xué)時間等屬性組成撕捍，這些屬性組合代表了一個學(xué)生。
• 鍵 能唯一標(biāo)識一個實體的屬性及屬性值泣洞，也稱關(guān)鍵字忧风。
• 實體型 用實體名及屬性名的集合來抽象和刻畫同類實體。例如學(xué)生(學(xué)號球凰，姓名狮腿，性別，籍貫呕诉，系缘厢，入學(xué)時間)就是一個實體型。
• 聯(lián)系 主要指實體型之間的關(guān)系甩挫。

第6章 構(gòu)建SaaS客戶體系

多租戶模式

1. 租戶是相對于被租用的資源而言的贴硫。在SaaS領(lǐng)域中，為客戶在SaaS系統(tǒng)中開辟一個專屬的功能信息空間，這就是客戶使用SaaS系統(tǒng)的基礎(chǔ)英遭。
2. 租戶模式分為兩大類：單租戶模式和多租戶模式
3. 單租戶模式间护，不同客戶使用的應(yīng)用軟件和數(shù)據(jù)一般通過硬件進(jìn)行離。
4. 多租戶模式挖诸，不同客戶共用一套基本的產(chǎn)品功能代碼汁尺，數(shù)據(jù)等敏感信息需要通過技術(shù)手段進(jìn)行隔離。
5. SaaS服務(wù)體系引入租戶的概念税灌，主要目的是為客戶做資源隔離均函。
6. 多租戶的意義在于降低SaaS服務(wù)成本、促進(jìn)SaaS客戶的規(guī)牧獾樱化效應(yīng)等方面苞也。
7. 多租戶數(shù)據(jù)隔離3種方法：數(shù)據(jù)庫層隔離、數(shù)據(jù)表現(xiàn)層隔離粘秆、字段層面隔離如迟。

數(shù)據(jù)庫層面隔離

數(shù)據(jù)庫層面隔離.png

數(shù)據(jù)庫層面隔離是為每個租戶提供獨立的數(shù)據(jù)庫，優(yōu)點：隔離級別高攻走，安全性好殷勘，能夠滿足不同租戶的獨特需求，出現(xiàn)故障時恢復(fù)數(shù)據(jù)也比較容易昔搂。缺點：購置和維護(hù)成本高玲销。

數(shù)據(jù)表層面隔離

數(shù)據(jù)表層面隔離.png

數(shù)據(jù)表層面隔離就共享數(shù)據(jù)庫，隔離數(shù)據(jù)表摘符。優(yōu)點：在一定程度上實現(xiàn)了邏輯數(shù)據(jù)隔離贤斜，可滿足較高程度的安全性需求，每個數(shù)據(jù)庫可支持更多的租戶逛裤。缺點：恢復(fù)整全數(shù)據(jù)較困難瘩绒，跨租戶統(tǒng)計數(shù)據(jù)實現(xiàn)難度大。

字段層面隔離

字段層面隔離.png

字段層面隔離带族，即所有租戶的數(shù)據(jù)存放在同一個數(shù)據(jù)表中锁荔，給每個表都加上租戶Id，用于標(biāo)識每條數(shù)據(jù)屬于哪個租戶蝙砌。優(yōu)點：數(shù)據(jù)庫支持租戶數(shù)量多阳堕，維護(hù)和購置成本低。缺點是隔離級別低择克，安全性低嘱丢，開發(fā)時需做大量安全開發(fā)工作，需要逐表逐條備份和還原數(shù)據(jù)祠饺。

客戶體系搭建

1.客戶體系的要素

客戶體系的要素.png

2. “三戶”模型

客戶：客戶指通過購買產(chǎn)品或服務(wù)來滿足需求的主體越驻。在SaaS領(lǐng)域，客戶往往是一個企業(yè)的主體。
用戶：指登錄并使用系統(tǒng)的人缀旁。在SaaS領(lǐng)域记劈，用戶從屬于客戶，是系統(tǒng)的操作者并巍。
帳戶：計算機領(lǐng)域所說的帳戶目木，除了部分財務(wù)金融相關(guān)的系統(tǒng)外，一般等同于帳號懊渡。在SaaS領(lǐng)域刽射，帳戶指指的是用戶登錄SaaS系統(tǒng)的帳號。

3. 三戶之間的關(guān)系

三戶之間的關(guān)系.png

1）客戶和用戶的關(guān)系 用戶側(cè)重“使用”剃执，是業(yè)務(wù)和場景屬性的誓禁。而客戶“側(cè)重”購買，是決策和價值屬性的肾档。
2）用戶和帳戶的關(guān)系 SaaS系統(tǒng)帳戶是標(biāo)識用戶Id的字符串摹恰，對應(yīng)用戶的虛擬身份。帳戶相當(dāng)于用戶的化身怒见，定義俗慈、描述一個帳戶，也就意味著了解一個用戶遣耍。
3）客戶與帳戶的關(guān)系 客戶包含多個用戶闺阱，可以開通多個帳戶，供不同用戶使用舵变。

4. 多組織與多租戶

多組織架構(gòu)重點考慮數(shù)據(jù)層面的隔離酣溃，而多租戶架構(gòu)更多考慮資源層面的隔離。

5. 客戶體系結(jié)構(gòu)

客戶體系結(jié)構(gòu).png

1）客戶注冊
注冊信息經(jīng)過審核后棋傍，系統(tǒng)創(chuàng)建租戶帳號救拉。在租戶建立標(biāo)志著SaaS服務(wù)商和被服務(wù)客戶雙方關(guān)系的建立难审√奔穑客戶注冊通過需要兩步，一訂閱服務(wù)套餐告喊。二用最高權(quán)限帳號完成配置工作麸拄。
2）用戶授權(quán)
為相關(guān)工作人員授權(quán)，與之相關(guān)的就是配置組織機構(gòu)黔姜、員工拢切、用戶帳號、角色秆吵、權(quán)限等淮椰。
3）用戶身份認(rèn)證
用戶身份認(rèn)證發(fā)生在用戶登錄系統(tǒng)時，認(rèn)證用戶身份最簡單的機制就是帳號+密碼+驗證碼登錄。
4）用戶鑒權(quán)
用戶鑒權(quán)認(rèn)證發(fā)生在用戶登錄之后主穗，這時才能獲取用戶的角色信息泻拦。用戶權(quán)限范圍分為兩部分，一是功能權(quán)限忽媒，二是數(shù)據(jù)權(quán)限争拐。
功能權(quán)限：用頁上的功能用戶是否有權(quán)限使用或查看。
數(shù)據(jù)權(quán)限：在頁面和功能相關(guān)情況下晦雨，用訪問的數(shù)據(jù)范圍和字段架曹。
5）用戶操作
用戶操作就是在授權(quán)范圍內(nèi)進(jìn)行增刪改查。

權(quán)限設(shè)計

常見權(quán)限模型

1. ACL模型 訪問控制列表（Access Control List）每個客體都有一個列表闹瞧，列中記錄哪些主體可以對這個客戶進(jìn)行哪些操作绑雄。缺點：主體數(shù)量過多時，配置和維護(hù)工作較復(fù)雜夹抗、易出錯绳慎。
2. DAC模型 自主訪問控制（Discretionary Access Control）在ACL基礎(chǔ)上，允許主體將自己擁有的自主授權(quán)予其它主體漠烧，權(quán)限可以任意傳遞杏愤。缺點：對權(quán)限控制比較分散、
3. MAC模型 強制訪問控制（Mandatory Access Control）實現(xiàn)原理是主體有一個權(quán)限標(biāo)識已脓，客戶也有一個權(quán)限標(biāo)識珊楼，主體能否對客戶進(jìn)行操作，取決于雙方權(quán)限標(biāo)識是否匹配度液。缺點厕宗，控制太嚴(yán)格，實現(xiàn)工作量大堕担，缺乏靈活性已慢。
4. ABAC模型 基于屬性的訪問控制（Attribute-Based Access Control）通過動態(tài)模型來計算一個或一或?qū)傩允欠駶M足某種機制來授權(quán)。缺點霹购，規(guī)則復(fù)雜佑惠。實現(xiàn)難度大，應(yīng)用場景少齐疙。
5. RBAC模型 基于角色的權(quán)限訪控制（Role-Based Access Control）核心在于用戶只和角色關(guān)聯(lián)膜楷，而角色代表權(quán)限，是一系統(tǒng)權(quán)限的集合贞奋。
   RBAC三要素：用戶赌厅，系統(tǒng)中所有的帳戶。角色轿塔，一系列權(quán)限的集合特愿。權(quán)限仲墨，菜單、按鈕揍障、數(shù)據(jù)的增刪改查等詳細(xì)權(quán)限宗收。

1） 基本角色權(quán)限模型RBAC0

RBAC0模型中用戶、角色和權(quán)限的關(guān)系.png

RBAC0是最簡單的用戶亚兄、角色混稽、權(quán)限模型，包含了2種關(guān)系审胚。

• 用戶和角色是多對一的關(guān)系匈勋，即一個用戶只充當(dāng)一種角色，一種角色可以由多個用戶擔(dān)當(dāng)膳叨。
• 用戶和角色是多對多的關(guān)系洽洁，即一個用戶可同時充當(dāng)多種角色，一種角色可以由多個用戶擔(dān)當(dāng)菲嘴。

2） 角色分級模型RBAC1（角色分層）

RBAC0模型中用戶饿自、角色和權(quán)限的關(guān)系.png

3）角色限制模型RBAC2（約束）

RBAC2是對用戶烛卧、角色和權(quán)限三者增加了一些限制。這些限制可以分為兩類妓局，靜態(tài)職責(zé)分離SSD（Static Separation of Duty）和動態(tài)職責(zé)分離DSD（Dynamic Separation of Duty）
靜態(tài)職責(zé)分離是在用戶和角色的指派階段加入的总放，主要是對用戶和角色進(jìn)行約束。

• 互斥角色：同一個用戶在兩個互斥角色中只能選擇一個好爬。
• 基數(shù)約束：一個用戶擁有的角色是有限制的局雄，一個角色擁有的權(quán)限也是有限制的。
• 先決條件約束：客戶想要獲得高級角色存炮，必須先擁有低級角色炬搭。
  動態(tài)職責(zé)分離是指會話和角色之間的約束，可以動態(tài)約束用戶擁有的角色僵蛛，一個用戶可以擁有兩個角色尚蝌，但在運行時只能激活一個角色迎变。
  
  RBAC2結(jié)構(gòu).png

4）統(tǒng)一權(quán)限模型RBAC3

RBAC3=RBAC1+RBAC2

權(quán)限設(shè)計

1. 定義角色（誰）
   結(jié)合業(yè)務(wù)場景充尉，定義簡單易懂直觀的角色。
2. 定義權(quán)限資源（做什么）
   權(quán)限資源包括功能和數(shù)據(jù)衣形。定義功能權(quán)限時需要明確功能權(quán)限到頁面級別（頁面資源的訪問權(quán)限）還是操作級別（功能是否可用）驼侠，甚至字段級別（字段展示與否）姿鸿。定義數(shù)據(jù)是指根據(jù)角色展示數(shù)據(jù)范圍（條件篩選）。
3. 定義行為（怎么做）
   對數(shù)據(jù)進(jìn)行增刪改查的權(quán)限

場景化登錄與IDaaS

1. 帳號關(guān)聯(lián)登錄方式
   采用某些大的第三方平臺帳號登錄倒源，第一次登錄時在系統(tǒng)內(nèi)部注冊一個帳號苛预，然后關(guān)聯(lián)第三方帳號和本地帳號，系統(tǒng)內(nèi)產(chǎn)生的記錄全部使用該帳號進(jìn)行關(guān)聯(lián)笋熬。
2. 賬號跨組織登錄
   一個員工在不同的組織內(nèi)有不同的身份热某，登錄時驗證帳號，通過則允許進(jìn)行系統(tǒng)胳螟。默人租戶也可以讓用戶手可選擇登錄的租戶昔馋，在不同的租戶下有不同的（相同）的身份和權(quán)限。員工和租戶關(guān)系在租戶下糖耸。如果員工在所有租戶下身份相同秘遏，則身份做為員工的屬性。如果員工在不同的組織下有不同的身份嘉竟，則需要一張員工崗位表邦危，通過表中的租戶ID和員工Id確定員工的身份。
3. IDaaS身份認(rèn)證即服務(wù)（IDentity as a Service）IDaaS是由第三方服務(wù)商構(gòu)建舍扰、運行在云上的身份驗證服務(wù)倦蚪，它向訂閱的企業(yè)客戶、開發(fā)者提供基于云端的用戶身份驗證边苹、訪問管理等服務(wù)审丘。我們可以將IDaaS理解為SaaS化的身份識別和訪問管理。

第7章 構(gòu)建SaaS的安全體系

SaaS帳號安全登錄

1. 登錄時的安全措施

1）使用多因素認(rèn)證 若監(jiān)控到客戶登錄的網(wǎng)絡(luò)IP或設(shè)備MAC地址不是日常使用的勾给，則可以通過短信等方式通知客戶滩报。
2）失敗次數(shù)限制 多次登錄失敗則鎖定帳戶。

2. 登錄后的安全防范

1）防止登錄后帳號被竊取播急。系統(tǒng)為客戶生成一個token并返回給客戶脓钾，然后將token和該客戶的Id關(guān)聯(lián)存儲∽客戶進(jìn)行增改查刪時可训，必須攜帶該 token。
2）客戶登錄后忘記退出 如果客戶長時間沒有操作捶枢，則系統(tǒng)自動退出握截。

SaaS信息安全

1. 頁面信息脫敏

1） 客戶信息脫敏 將重要信息用* 代替；單位做開關(guān)為客戶配置烂叔。
2） 第三方信息脫敏

2. 數(shù)據(jù)安全

1）多租戶數(shù)據(jù)隔離
2）數(shù)據(jù)備份與恢復(fù)
3）數(shù)據(jù)入站和出站校驗

3. 操作風(fēng)險規(guī)避

1）通過功能設(shè)計規(guī)避操作風(fēng)險
操作風(fēng)險指客戶對SaaS系統(tǒng)的操作失誤谨胞、違規(guī)操作等個人原因?qū)е碌膿p失風(fēng)險。比如單擊變雙擊蒜鸡，輸入特殊字符等胯努。
2）完善的操作日志
操作日志是對客戶在系統(tǒng)中的操作行為和操作數(shù)據(jù)進(jìn)行記錄牢裳。操作日志可分為兩類：客戶操作日志和系統(tǒng)后臺日志。

SaaS技術(shù)安全

1. 系統(tǒng)性能安全

性能問題的根源在于數(shù)據(jù)量大叶沛，解決方案如下：

• 限制數(shù)據(jù)同步的觸發(fā)頻次蒲讯，即通過限制客戶手動操作的頻率，降低觸發(fā)同步的頻率(這在一定程度上可能犧牲了數(shù)據(jù)同步的及時性)灰署。
• 對待處理數(shù)據(jù)進(jìn)行清洗判帮，包括去重、對比溉箕、改變存儲方式等脊另，這是為了擺脫無效數(shù)據(jù)，盡可能降低冗余约巷。
• 增加失敗補償機制和日志偎痛，讓客戶的操作有跡可循，可自行追溯独郎。

2. 分權(quán)管理

分權(quán)管理是指在產(chǎn)研團(tuán)隊人員授權(quán)方面踩麦，嚴(yán)格進(jìn)行員工、角色授權(quán)氓癌，遵循最小授予原則谓谦，將數(shù)據(jù)庫操作權(quán)限與備份權(quán)限分開。

第8章 構(gòu)建SaaS數(shù)據(jù)體系

基礎(chǔ)知識

1. 數(shù)據(jù)模式是數(shù)據(jù)特征的抽象贪婉，是數(shù)據(jù)庫管理的框架反粥。
2. 概念數(shù)據(jù)模型（Conceptual Data Model，CDM）是抽象性最高疲迂，關(guān)注現(xiàn)實世界與數(shù)據(jù)世界的關(guān)系才顿，不關(guān)注數(shù)據(jù)的底層細(xì)節(jié)，為構(gòu)建邏輯數(shù)據(jù)模型奠定基礎(chǔ)尤蒿。概念數(shù)據(jù)模型中郑气，E-R圖、擴充E-R模型腰池、面向?qū)ο竽Ｐ臀沧椤⒅^詞模型等。
   
   E-R模型示意圖.png

E-R模型比較常用示弓，E（Eneity）表示實體讳侨，R（Relationship）表示事物與屬性之間有的關(guān)系，事物與事物之間也有關(guān)系奏属。

3. 邏輯數(shù)據(jù)模型（Login Data Model跨跨，LDM）直接面向數(shù)據(jù)庫的邏輯結(jié)構(gòu)，涉及計算機系統(tǒng)和數(shù)據(jù)庫管理系統(tǒng)拍皮。
4. 物理數(shù)據(jù)模型（Physical Data Model歹叮，PDM）是在邏輯數(shù)據(jù)模型的基礎(chǔ)上，考慮具體的技術(shù)實現(xiàn)因素及硬件因素铆帽，設(shè)計數(shù)據(jù)庫的體系結(jié)構(gòu)咆耿，實現(xiàn)在數(shù)據(jù)庫中存儲數(shù)據(jù)。

關(guān)系型數(shù)據(jù)庫

1. 范式
   1）第一范式 第一范式是指數(shù)據(jù)表中的每一列不能有多個值爹橱，即不能有重復(fù)值萨螺。
   2）第二范式 第二范式是基于滿足第一范式的前提下提出的，主要包括兩點愧驱，一個數(shù)據(jù)表必須有一個主鍵慰技，主鍵可以由一個或多個字段組成，區(qū)分?jǐn)?shù)據(jù)的唯一性组砚；沒有包含在主鍵中的列必須完全依賴于主鍵 吻商，不能只依賴于主鍵的一部分。
   3）第三范式 第三范式要求不能存在非主鍵列A依賴于非主鍵B糟红，且非主鍵列B依賴于主鍵的情況艾帐。

SaaS數(shù)據(jù)報表

SaaS產(chǎn)品統(tǒng)計報表核心分為三部分：確定分析指標(biāo)、設(shè)計數(shù)據(jù)模型盆偿、進(jìn)行可視化呈現(xiàn)柒爸。

1. 確定分析指標(biāo)
2. 設(shè)計數(shù)據(jù)模型

• 找到引起指標(biāo)變化的根源數(shù)據(jù)
• 找到根源數(shù)據(jù)與指標(biāo)的關(guān)系
• 建立數(shù)據(jù)分析模型
• 建立數(shù)據(jù)結(jié)構(gòu)
• 界面呈現(xiàn)

3. 進(jìn)行可視化呈現(xiàn)

數(shù)據(jù)決策

1. 常見的數(shù)據(jù)決策實現(xiàn)方式
   1）模型驅(qū)動：以算法模型為核心，在客戶端輸入?yún)?shù)事扭，得到預(yù)測結(jié)果或仿真模擬結(jié)果捎稚。
   2）知識驅(qū)動： 也叫作經(jīng)驗驅(qū)動，將專家領(lǐng)域知識（方法論）沉淀在系統(tǒng)里求橄。
   3）數(shù)據(jù)驅(qū)動：通過對數(shù)據(jù)的挖掘分析（通常是時間序列數(shù)據(jù)）獲得數(shù)據(jù)決策今野。

2. 數(shù)據(jù)決策的一般實現(xiàn)步驟
   1） 定義決策主題和參數(shù)
   2） 找準(zhǔn)決策建議的觸發(fā)條件

• 閾值觸發(fā) 數(shù)據(jù)指標(biāo)達(dá)到某個指定的數(shù)值時觸發(fā)。
• 事件觸發(fā) 當(dāng)出現(xiàn)某個狀態(tài)時觸 發(fā)罐农。
• 時間觸發(fā) 指定時間觸發(fā)腥泥，或者達(dá)到一定的時間周期時觸發(fā)。
  3） 確定決策效果
• 定量建議：需要給出具體的數(shù)字或者數(shù)據(jù)清單啃匿。
• 定性建議：需要給出具體的指向目的蛔外。
  核心參數(shù)基本確定，也確定了模型規(guī)則溯乒，就可以將參數(shù)與系統(tǒng)的數(shù)據(jù)打通夹厌，建立整合機制。一旦一個參數(shù)的取值發(fā)生變化裆悄，對應(yīng)輸出的數(shù)據(jù)決策就會變化矛纹。

中臺化數(shù)據(jù)

1. SaaS模式更適合中臺化
   數(shù)據(jù)中臺可以定義為呐伞，基于大數(shù)據(jù)平臺提供數(shù)據(jù)共享和能加復(fù)用的平臺短纵，依據(jù)企業(yè)特有的業(yè)務(wù)模式和組織架構(gòu)，通過有形的產(chǎn)品和實施方法論加以支撐，構(gòu)建一套持續(xù)不斷地把數(shù)據(jù)變成資產(chǎn)開服務(wù)于業(yè)務(wù)的機制幕屹。
   常見的SaaS化數(shù)據(jù)中臺通過集中下層的數(shù)據(jù)存儲、傳輸和計算等能力产艾，向上賦能業(yè)務(wù)決策和創(chuàng)新應(yīng)用医男。
2. 在建設(shè) SaaS 化數(shù)據(jù)中臺之前，需要明確數(shù)據(jù)中臺的核心能力:數(shù)據(jù)整合匯聚蹬癌、分析處理权她、數(shù)據(jù)應(yīng)用和服務(wù)。圍繞數(shù)據(jù)中臺的核心功能逝薪，還需要一系列配套功能的支持隅要，如存儲管理、集群管理董济、離線數(shù)據(jù)管理步清、調(diào)度管理和可視化管理等。

第9章 構(gòu)建SaaS功能體系

SaaS功能體系是指SaaS產(chǎn)品中虏肾，為客戶提供具體的系統(tǒng)能力尼啡、解決明確的業(yè)務(wù)問題的應(yīng)用模塊。SaaS的功能體系分為兩類询微，一類是通用功能崖瞭，另一類是業(yè)務(wù)功能。

通用功能

1. 功能列表

1）是否展示這個字段 原則是非必要不展示無用字段撑毛。
2）表格內(nèi)容過長 省略或者換行
3）字段順序 一般重要的字段在前邊
4）字段注釋 通常需要在可能出現(xiàn)歧義的字段項上加注釋

2. 導(dǎo)入功能

導(dǎo)入功功能的工作量主要是數(shù)據(jù)校驗上
1）前置校驗 主要包括模板文件格式和表頭校驗導(dǎo)人數(shù)據(jù)行數(shù)校驗书聚、文件必填字段和格式校驗、本文檔重復(fù)校等藻雌。前置校驗是基于導(dǎo)人文件就可以完成的校驗雌续，通常由前端完成。
2）后置校驗主要包括對擬導(dǎo)入的數(shù)據(jù)表中已有數(shù)據(jù)的重復(fù)性校驗胯杭、擬導(dǎo)入的數(shù)據(jù)與系統(tǒng)的兼容性校驗等驯杜。后置校驗通常由后端完成前置校驗通過的數(shù)據(jù)，才能進(jìn)入后置校驗做个，從而降低系統(tǒng)運算的工作量鸽心。
校驗不通過的原因需要匯報
1）匯報校驗不通過的原因 無論前置校驗還是后置校驗任一步校驗失敗后，都要阻斷執(zhí)行居暖，并匯報失敗原因顽频。
2）匯報導(dǎo)人結(jié)果即使校驗通過，也可能會有一些不可控因素(主要是系統(tǒng)運行問題)導(dǎo)致導(dǎo)人失敗太闺，這種情況也需要匯報糯景。一般將全部失敗結(jié)果集中匯報。失敗結(jié)果文件通常是系統(tǒng)基于模板生成的，在前端提供下載入口蟀淮。若導(dǎo)人成功最住，則匯報成功結(jié)果，向客戶傳遞更加準(zhǔn)確的信息怠惶。
導(dǎo)入數(shù)據(jù)后的異步執(zhí)行
導(dǎo)入數(shù)據(jù)后若執(zhí)行的運算量比較大涨缚，那么通常要考慮異步執(zhí)行。這種方案需要配套設(shè)計異頻執(zhí)行結(jié)果查看頁面甚疟。

3. 單據(jù)號生成器

設(shè)計單號生成器時通常需要考慮幾下幾點：
1）單據(jù)號需要具有唯一性
2）單據(jù)號應(yīng)具有語義性
3）單據(jù)號足夠短
4）開發(fā)簡單仗岖，能復(fù)用或減少維護(hù)成本

4. 埋點設(shè)計

1）確認(rèn)事件和變量
事件指產(chǎn)品中的操作逃延，變量指描述事件的屬性览妖。
2）明確事件的觸發(fā)時機
盡量選擇貼近業(yè)務(wù)的統(tǒng)計口徑。我們可以采用MECE（MutuallyExclusive,Collectively Exhaustive相互獨立揽祥，完全窮盡）的原則讽膏，不要重復(fù)列舉，但要包含所有入口拄丰。
3）規(guī)范命名
4）明確優(yōu)先級

5. 幫助中心

幫助中心是SaaS產(chǎn)品的重要工具府树，搭建幫助中心就相當(dāng)于向客戶提從了一個自助服務(wù)平臺。

• 客戶訪問幫助中心自行尋找答案料按，大大減輕客服人員的售后壓力奄侠。幫助中心有助于提高客戶學(xué)習(xí)產(chǎn)品使用方的積極性，同時加深對產(chǎn)品的了解载矿。
• 幫助中心作為產(chǎn)品知識庫垄潮，為新員工培訓(xùn)提供了素材可以減輕培訓(xùn)壓力，縮短培訓(xùn)周期闷盔。
• 幫助中心作為智能助手弯洗，可以實現(xiàn)24小時無差別服務(wù)幫助中心包含產(chǎn)品的介紹、指南逢勾、上新等板塊牡整，便于品品牌推廣。
  業(yè)務(wù)功能

搭建幫助中心

1）配套的知識庫
將幫助中主作為產(chǎn)品的配套知識庫
2）嵌入SaaS產(chǎn)品功能
將幫助中心作為SaaS產(chǎn)品的一部分
3）第三方幫助中心制作工具

業(yè)務(wù)功能

業(yè)務(wù)功能就是與客戶的業(yè)務(wù)相匹配的功能溺拱，這些功能往往為行業(yè)或員工提供便捷的工具逃贝，提升業(yè)務(wù)運行效率，最終達(dá)到提升人效迫摔，降低公司成本等作用秋泳。

1. SaaS產(chǎn)品中的業(yè)務(wù)承擔(dān)

1）優(yōu)化業(yè)務(wù)流程
在搭建產(chǎn)品流程時，一方面需要審視當(dāng)前的業(yè)務(wù)流程攒菠，另一方面需要考慮未來的業(yè)務(wù)走向迫皱，提前考慮流程可能延伸點。
2）提升員工效率
3）促進(jìn)資源轉(zhuǎn)化
4）優(yōu)化用戶體驗
產(chǎn)品的體驗分為兩類，UI體驗和操作體驗卓起。操作體驗直接影響到用戶體驗和敬。
5）降低成本

2. 業(yè)務(wù)場景下的離線應(yīng)用

1）離線應(yīng)用面臨的問題

• 支持本地存儲機制
• 數(shù)據(jù)一致性
• 減少傳輸量及以保障數(shù)據(jù)安全

2）離線應(yīng)用機制的閉環(huán)

離線應(yīng)用的基本機制.png

3）離線應(yīng)用的面面支持和數(shù)據(jù)庫支持
離線應(yīng)用需要解決本地存儲 問題。數(shù)據(jù)庫需要在客戶計算機上運行戏阅，瀏覽器可以使用腳本調(diào)用本地輕便 型數(shù)據(jù)庫來實現(xiàn)昼弟。
4）離線查詢和離線更新
實現(xiàn)離線查詢需要提前（在有網(wǎng)絡(luò)的時候）將服務(wù)器端的數(shù)據(jù)下載到本地，對于SaaS應(yīng)用則只下載當(dāng)前租戶的系統(tǒng)和業(yè)務(wù)數(shù)據(jù)即可奕筐。離線更新的業(yè)務(wù)對象涉及租戶之外 關(guān)聯(lián)數(shù)據(jù)舱痘。
5）增量數(shù)據(jù)
增量數(shù)據(jù)就是某個時刻或檢查點之后的新增的數(shù)據(jù)
6）多客戶沖突策略

• 覆蓋策略:后提交者覆蓋先提交者的內(nèi)容，以的內(nèi)容為最終結(jié)果离赫。
• 丟棄策略:后提交者在提交前發(fā)現(xiàn)有人已經(jīng)提交將自己的數(shù)據(jù)丟棄芭逝，在系統(tǒng)里仍然保留先提交者的內(nèi)容。
• 提醒方案:當(dāng)發(fā)生沖突時渊胸，將沖突信息提交給客戶旬盯，由客戶確定是覆蓋還是丟棄。

SaaS產(chǎn)品功能設(shè)計自查

1. 數(shù)量上限下限自查

1）文本長度的限制
表單錄入項需限制長度翎猛，一方面是因為數(shù)據(jù)有長度限制胖翰，另一方面是為了避免客戶將無秩序的信息帶入系統(tǒng)。
2）數(shù)值型字段限制
對于金額切厘、尺寸萨咳、庫存、跨度等本身就是數(shù)值型的字段疫稿，在限制的時候需要考慮實際的范圍培他。
3）業(yè)務(wù)層面的數(shù)量限制

2. 命名和文案

1）提示文案
提示客戶操作錯誤，不如給出建議而克，降低解釋成本靶壮。
2）按鈕命名
命名按鈕時建議使用“動詞+名詞”的結(jié)構(gòu)順序。
3）提示類型與情景適配
提示的方式有對話框员萍、氣泡浮框腾降、toast（吐絲）等，可根據(jù)需要提示內(nèi)容的重要性進(jìn)行選擇碎绎◇θ溃基于情景，還需要進(jìn)行色彩強調(diào)筋帖。
4）注釋說明
SaaS產(chǎn)品的功能有時候也很復(fù)雜奸晴，需要加以解釋，并保證整體美觀日麸。

3. 離岸作業(yè)

對于一些需要離開系統(tǒng)作業(yè)的環(huán)節(jié)寄啼，需要考慮操作人員離開系統(tǒng)之后逮光，可能發(fā)生系統(tǒng)信息狀態(tài)變化導(dǎo)致的沖突。

4. 數(shù)據(jù)快照

數(shù)據(jù)快照用于記錄之前發(fā)生事件時的信息墩划，區(qū)別于當(dāng)前的實時信息涕刚。

5. 數(shù)據(jù)傳輸?shù)耐健惒胶头祷爻瑫r

第10章 SaaS產(chǎn)品頁面和交互設(shè)計

略

這章太簡單了都是基礎(chǔ)知識乙帮，直接跳過