读书笔记《To B 产品之美 》二 赵世哲

读书笔记《To B 产品之美 》一 赵世哲
读书笔记《To B 产品之美 》三 赵世哲

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

需求的四要素

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

1. 主体 需求的主体是人或事物。主体分为直接主体和间接主体。
2. 场景 需求的场景指需求产生的条件，包括但不限于环境、时间、地点等，只有满足条件，需求才能成立
3. 目的 需求的目的可能是隐性的。
4. 价值 需求被满足，被满足者得到了价值 ，与此同时作为回馈，需要另一种价值形式补偿给解决方案提供方，这是最基本的价值回馈形式。

需求的获取和管理

需求分为主动需求和被动需求：主动需求是产品经理通过对问题进行诊断或通过机会识别提取出来的；被动需求是客户提出来的，也可以是产品本身发生了异常，从而暴露出来的。

SaaS产品搭建初期和稳步迭代时间，获取和管理方法

搭建初期

获取需求的本质是识别需求、机会或风险，主要通过调研客户、对标标杆企业或产品、数据分析等手段获取需求。

1. 调研客户
2. 对标标杆企业或产品
3. 数据分析

稳步迭代时期

1. 客户反馈的需求
2. 异常问题转化为需求
3. 产品经理主动优化

需求调研和分析

1. 涉众 我们获取需求之后，首先想到的是这些需求涉及哪些人，也就是涉众。
2. 干系人 产品往往涉众众多，我们将其中全程关注产品建设的称作干系人。
3. 客户 客户属于涉众，也是重要的干系人。客户的属性分为4种。
   1）自然属性 产品的客户可能来自不同行业，具备不同的自然属性。
   2）角色属性 无论客户的自然属性如何，在接触SaaS产品时，都是以某一个身份进行作业的。
   3）组织归属属性 一个角色从属于一个组织架构，带有自身利益的权限边界。
   4）活动范围属性 产品功能是为帮助特定的角色完成特定的业务行为而设定的，当客户以某种角色使用产品时，其活动范围 是相对有限且确定的，不是无限开放的。

需求的七步循环

需求实现路线的七步循环.png

1. 需求作为触发点
   需求通过用例模型表示，用例模型是由用例图和用例的详细描述文档组成的。
2. 需求演绎出业务场景
   演绎法是一种从整体以个体的推理，实际上就是要穷举需求背后的场景，也就是业务场景，举一反三。
3. 基于业务场景总结业务域
4. 基于业务或抽象概念模型（业务模型）
   概念模型主要描述的是业务的组绢及运作的结构和逻辑。
5. 业务模型到功能模型
   功能模型是对功能要执行的任务进行直观的表达。
6. 功能模型和功能的实现
   实现功能模型还需要经过撰写产品需求文档、研发、测试等环节。功能实现之后，是否能满足需求，还需要经过验证。

概念模型5个要素

• 实体 客观存在并且可以相互区别的事物，在绘制概念模型之前需要先找到目标实体。
• 属性 实体所具有的某一特性。例如学生可以由学号姓名、性别、籍贯、系、入学时间等属性组成，这些属性组合代表了一个学生。
• 键 能唯一标识一个实体的属性及属性值，也称关键字。
• 实体型 用实体名及属性名的集合来抽象和刻画同类实体。例如学生(学号，姓名，性别，籍贯，系，入学时间)就是一个实体型。
• 联系 主要指实体型之间的关系。

第6章 构建SaaS客户体系

多租户模式

1. 租户是相对于被租用的资源而言的。在SaaS领域中，为客户在SaaS系统中开辟一个专属的功能信息空间，这就是客户使用SaaS系统的基础。
2. 租户模式分为两大类：单租户模式和多租户模式
3. 单租户模式，不同客户使用的应用软件和数据一般通过硬件进行离。
4. 多租户模式，不同客户共用一套基本的产品功能代码，数据等敏感信息需要通过技术手段进行隔离。
5. SaaS服务体系引入租户的概念，主要目的是为客户做资源隔离。
6. 多租户的意义在于降低SaaS服务成本、促进SaaS客户的规模化效应等方面。
7. 多租户数据隔离3种方法：数据库层隔离、数据表现层隔离、字段层面隔离。

数据库层面隔离

数据库层面隔离.png

数据库层面隔离是为每个租户提供独立的数据库，优点：隔离级别高，安全性好，能够满足不同租户的独特需求，出现故障时恢复数据也比较容易。缺点：购置和维护成本高。

数据表层面隔离

数据表层面隔离.png

数据表层面隔离就共享数据库，隔离数据表。优点：在一定程度上实现了逻辑数据隔离，可满足较高程度的安全性需求，每个数据库可支持更多的租户。缺点：恢复整全数据较困难，跨租户统计数据实现难度大。

字段层面隔离

字段层面隔离.png

字段层面隔离，即所有租户的数据存放在同一个数据表中，给每个表都加上租户Id，用于标识每条数据属于哪个租户。优点：数据库支持租户数量多，维护和购置成本低。缺点是隔离级别低，安全性低，开发时需做大量安全开发工作，需要逐表逐条备份和还原数据。

客户体系搭建

1.客户体系的要素

客户体系的要素.png

2. “三户”模型

客户：客户指通过购买产品或服务来满足需求的主体。在SaaS领域，客户往往是一个企业的主体。
用户：指登录并使用系统的人。在SaaS领域，用户从属于客户，是系统的操作者。
帐户：计算机领域所说的帐户，除了部分财务金融相关的系统外，一般等同于帐号。在SaaS领域，帐户指指的是用户登录SaaS系统的帐号。

3. 三户之间的关系

三户之间的关系.png

1）客户和用户的关系 用户侧重“使用”，是业务和场景属性的。而客户“侧重”购买，是决策和价值属性的。
2）用户和帐户的关系 SaaS系统帐户是标识用户Id的字符串，对应用户的虚拟身份。帐户相当于用户的化身，定义、描述一个帐户，也就意味着了解一个用户。
3）客户与帐户的关系 客户包含多个用户，可以开通多个帐户，供不同用户使用。

4. 多组织与多租户

多组织架构重点考虑数据层面的隔离，而多租户架构更多考虑资源层面的隔离。

5. 客户体系结构

客户体系结构.png

1）客户注册
注册信息经过审核后，系统创建租户帐号。在租户建立标志着SaaS服务商和被服务客户双方关系的建立。客户注册通过需要两步，一订阅服务套餐。二用最高权限帐号完成配置工作。
2）用户授权
为相关工作人员授权，与之相关的就是配置组织机构、员工、用户帐号、角色、权限等。
3）用户身份认证
用户身份认证发生在用户登录系统时，认证用户身份最简单的机制就是帐号+密码+验证码登录。
4）用户鉴权
用户鉴权认证发生在用户登录之后，这时才能获取用户的角色信息。用户权限范围分为两部分，一是功能权限，二是数据权限。
功能权限：用页上的功能用户是否有权限使用或查看。
数据权限：在页面和功能相关情况下，用访问的数据范围和字段。
5）用户操作
用户操作就是在授权范围内进行增删改查。

权限设计

常见权限模型

1. ACL模型 访问控制列表（Access Control List）每个客体都有一个列表，列中记录哪些主体可以对这个客户进行哪些操作。缺点：主体数量过多时，配置和维护工作较复杂、易出错。
2. DAC模型 自主访问控制（Discretionary Access Control）在ACL基础上，允许主体将自己拥有的自主授权予其它主体，权限可以任意传递。缺点：对权限控制比较分散、
3. MAC模型 强制访问控制（Mandatory Access Control）实现原理是主体有一个权限标识，客户也有一个权限标识，主体能否对客户进行操作，取决于双方权限标识是否匹配。缺点，控制太严格，实现工作量大，缺乏灵活性。
4. ABAC模型 基于属性的访问控制（Attribute-Based Access Control）通过动态模型来计算一个或一或属性是否满足某种机制来授权。缺点，规则复杂。实现难度大，应用场景少。
5. RBAC模型 基于角色的权限访控制（Role-Based Access Control）核心在于用户只和角色关联，而角色代表权限，是一系统权限的集合。
   RBAC三要素：用户，系统中所有的帐户。角色，一系列权限的集合。权限，菜单、按钮、数据的增删改查等详细权限。

1） 基本角色权限模型RBAC0

RBAC0模型中用户、角色和权限的关系.png

RBAC0是最简单的用户、角色、权限模型，包含了2种关系。

• 用户和角色是多对一的关系，即一个用户只充当一种角色，一种角色可以由多个用户担当。
• 用户和角色是多对多的关系，即一个用户可同时充当多种角色，一种角色可以由多个用户担当。

2） 角色分级模型RBAC1（角色分层）

RBAC0模型中用户、角色和权限的关系.png
RBAC1是在RBAC0实现，在角色中引入了继承的概念。给角色分成几个等级，每个等级对应权限不同，从而实现更细粒度的权限管理。

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

RBAC2是对用户、角色和权限三者增加了一些限制。这些限制可以分为两类，静态职责分离SSD（Static Separation of Duty）和动态职责分离DSD（Dynamic Separation of Duty）
静态职责分离是在用户和角色的指派阶段加入的，主要是对用户和角色进行约束。

• 互斥角色：同一个用户在两个互斥角色中只能选择一个。
• 基数约束：一个用户拥有的角色是有限制的，一个角色拥有的权限也是有限制的。
• 先决条件约束：客户想要获得高级角色，必须先拥有低级角色。
  动态职责分离是指会话和角色之间的约束，可以动态约束用户拥有的角色，一个用户可以拥有两个角色，但在运行时只能激活一个角色。
  RBAC2结构.png

4）统一权限模型RBAC3

RBAC3=RBAC1+RBAC2

权限设计

1. 定义角色（谁）
   结合业务场景，定义简单易懂直观的角色。
2. 定义权限资源（做什么）
   权限资源包括功能和数据。定义功能权限时需要明确功能权限到页面级别（页面资源的访问权限）还是操作级别（功能是否可用），甚至字段级别（字段展示与否）。定义数据是指根据角色展示数据范围（条件筛选）。
3. 定义行为（怎么做）
   对数据进行增删改查的权限

场景化登录与IDaaS

1. 帐号关联登录方式
   采用某些大的第三方平台帐号登录，第一次登录时在系统内部注册一个帐号，然后关联第三方帐号和本地帐号，系统内产生的记录全部使用该帐号进行关联。
2. 账号跨组织登录
   一个员工在不同的组织内有不同的身份，登录时验证帐号，通过则允许进行系统。默人租户也可以让用户手可选择登录的租户，在不同的租户下有不同的（相同）的身份和权限。员工和租户关系在租户下。如果员工在所有租户下身份相同，则身份做为员工的属性。如果员工在不同的组织下有不同的身份，则需要一张员工岗位表，通过表中的租户ID和员工Id确定员工的身份。
3. IDaaS身份认证即服务（IDentity as a Service）IDaaS是由第三方服务商构建、运行在云上的身份验证服务，它向订阅的企业客户、开发者提供基于云端的用户身份验证、访问管理等服务。我们可以将IDaaS理解为SaaS化的身份识别和访问管理。

第7章 构建SaaS的安全体系

SaaS帐号安全登录

1. 登录时的安全措施

1）使用多因素认证 若监控到客户登录的网络IP或设备MAC地址不是日常使用的，则可以通过短信等方式通知客户。
2）失败次数限制 多次登录失败则锁定帐户。

2. 登录后的安全防范

1）防止登录后帐号被窃取。系统为客户生成一个token并返回给客户，然后将token和该客户的Id关联存储。客户进行增改查删时，必须携带该 token。
2）客户登录后忘记退出 如果客户长时间没有操作，则系统自动退出。

SaaS信息安全

1. 页面信息脱敏

1） 客户信息脱敏 将重要信息用* 代替；单位做开关为客户配置。
2） 第三方信息脱敏

2. 数据安全

1）多租户数据隔离
2）数据备份与恢复
3）数据入站和出站校验

3. 操作风险规避

1）通过功能设计规避操作风险
操作风险指客户对SaaS系统的操作失误、违规操作等个人原因导致的损失风险。比如单击变双击，输入特殊字符等。
2）完善的操作日志
操作日志是对客户在系统中的操作行为和操作数据进行记录。操作日志可分为两类：客户操作日志和系统后台日志。

SaaS技术安全

1. 系统性能安全

性能问题的根源在于数据量大，解决方案如下：

• 限制数据同步的触发频次，即通过限制客户手动操作的频率，降低触发同步的频率(这在一定程度上可能牺牲了数据同步的及时性)。
• 对待处理数据进行清洗，包括去重、对比、改变存储方式等，这是为了摆脱无效数据，尽可能降低冗余。
• 增加失败补偿机制和日志，让客户的操作有迹可循，可自行追溯。

2. 分权管理

分权管理是指在产研团队人员授权方面，严格进行员工、角色授权，遵循最小授予原则，将数据库操作权限与备份权限分开。

第8章 构建SaaS数据体系

基础知识

1. 数据模式是数据特征的抽象，是数据库管理的框架。
2. 概念数据模型（Conceptual Data Model，CDM）是抽象性最高，关注现实世界与数据世界的关系，不关注数据的底层细节，为构建逻辑数据模型奠定基础。概念数据模型中，E-R图、扩充E-R模型、面向对象模型、谓词模型等。
   E-R模型示意图.png

E-R模型比较常用，E（Eneity）表示实体，R（Relationship）表示事物与属性之间有的关系，事物与事物之间也有关系。

3. 逻辑数据模型（Login Data Model，LDM）直接面向数据库的逻辑结构，涉及计算机系统和数据库管理系统。
4. 物理数据模型（Physical Data Model，PDM）是在逻辑数据模型的基础上，考虑具体的技术实现因素及硬件因素，设计数据库的体系结构，实现在数据库中存储数据。

关系型数据库

1. 范式
   1）第一范式 第一范式是指数据表中的每一列不能有多个值，即不能有重复值。
   2）第二范式 第二范式是基于满足第一范式的前提下提出的，主要包括两点，一个数据表必须有一个主键，主键可以由一个或多个字段组成，区分数据的唯一性；没有包含在主键中的列必须完全依赖于主键 ，不能只依赖于主键的一部分。
   3）第三范式 第三范式要求不能存在非主键列A依赖于非主键B，且非主键列B依赖于主键的情况。

SaaS数据报表

SaaS产品统计报表核心分为三部分：确定分析指标、设计数据模型、进行可视化呈现。

1. 确定分析指标
2. 设计数据模型

• 找到引起指标变化的根源数据
• 找到根源数据与指标的关系
• 建立数据分析模型
• 建立数据结构
• 界面呈现

3. 进行可视化呈现

数据决策

1. 常见的数据决策实现方式
   1）模型驱动：以算法模型为核心，在客户端输入参数，得到预测结果或仿真模拟结果。
   2）知识驱动： 也叫作经验驱动，将专家领域知识（方法论）沉淀在系统里。
   3）数据驱动：通过对数据的挖掘分析（通常是时间序列数据）获得数据决策。

2. 数据决策的一般实现步骤
   1） 定义决策主题和参数
   2） 找准决策建议的触发条件

• 阈值触发 数据指标达到某个指定的数值时触发。
• 事件触发 当出现某个状态时触 发。
• 时间触发 指定时间触发，或者达到一定的时间周期时触发。
  3） 确定决策效果
• 定量建议：需要给出具体的数字或者数据清单。
• 定性建议：需要给出具体的指向目的。
  核心参数基本确定，也确定了模型规则，就可以将参数与系统的数据打通，建立整合机制。一旦一个参数的取值发生变化，对应输出的数据决策就会变化。

中台化数据

1. SaaS模式更适合中台化
   数据中台可以定义为，基于大数据平台提供数据共享和能加复用的平台，依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论加以支撑，构建一套持续不断地把数据变成资产开服务于业务的机制。
   常见的SaaS化数据中台通过集中下层的数据存储、传输和计算等能力，向上赋能业务决策和创新应用。
2. 在建设 SaaS 化数据中台之前，需要明确数据中台的核心能力:数据整合汇聚、分析处理、数据应用和服务。围绕数据中台的核心功能，还需要一系列配套功能的支持，如存储管理、集群管理、离线数据管理、调度管理和可视化管理等。

第9章 构建SaaS功能体系

SaaS功能体系是指SaaS产品中，为客户提供具体的系统能力、解决明确的业务问题的应用模块。SaaS的功能体系分为两类，一类是通用功能，另一类是业务功能。

通用功能

1. 功能列表

1）是否展示这个字段 原则是非必要不展示无用字段。
2）表格内容过长 省略或者换行
3）字段顺序 一般重要的字段在前边
4）字段注释 通常需要在可能出现歧义的字段项上加注释

2. 导入功能

导入功功能的工作量主要是数据校验上
1）前置校验 主要包括模板文件格式和表头校验导人数据行数校验、文件必填字段和格式校验、本文档重复校等。前置校验是基于导人文件就可以完成的校验，通常由前端完成。
2）后置校验主要包括对拟导入的数据表中已有数据的重复性校验、拟导入的数据与系统的兼容性校验等。后置校验通常由后端完成前置校验通过的数据，才能进入后置校验，从而降低系统运算的工作量。
校验不通过的原因需要汇报
1）汇报校验不通过的原因 无论前置校验还是后置校验任一步校验失败后，都要阻断执行，并汇报失败原因。
2）汇报导人结果即使校验通过，也可能会有一些不可控因素(主要是系统运行问题)导致导人失败，这种情况也需要汇报。一般将全部失败结果集中汇报。失败结果文件通常是系统基于模板生成的，在前端提供下载入口。若导人成功，则汇报成功结果，向客户传递更加准确的信息。
导入数据后的异步执行
导入数据后若执行的运算量比较大，那么通常要考虑异步执行。这种方案需要配套设计异频执行结果查看页面。

3. 单据号生成器

设计单号生成器时通常需要考虑几下几点：
1）单据号需要具有唯一性
2）单据号应具有语义性
3）单据号足够短
4）开发简单，能复用或减少维护成本

4. 埋点设计

1）确认事件和变量
事件指产品中的操作，变量指描述事件的属性。
2）明确事件的触发时机
尽量选择贴近业务的统计口径。我们可以采用MECE（MutuallyExclusive,Collectively Exhaustive相互独立，完全穷尽）的原则，不要重复列举，但要包含所有入口。
3）规范命名
4）明确优先级

5. 帮助中心

帮助中心是SaaS产品的重要工具，搭建帮助中心就相当于向客户提从了一个自助服务平台。

• 客户访问帮助中心自行寻找答案，大大减轻客服人员的售后压力。帮助中心有助于提高客户学习产品使用方的积极性，同时加深对产品的了解。
• 帮助中心作为产品知识库，为新员工培训提供了素材可以减轻培训压力，缩短培训周期。
• 帮助中心作为智能助手，可以实现24小时无差别服务帮助中心包含产品的介绍、指南、上新等板块，便于品品牌推广。
  业务功能

搭建帮助中心

1）配套的知识库
将帮助中主作为产品的配套知识库
2）嵌入SaaS产品功能
将帮助中心作为SaaS产品的一部分
3）第三方帮助中心制作工具

业务功能

业务功能就是与客户的业务相匹配的功能，这些功能往往为行业或员工提供便捷的工具，提升业务运行效率，最终达到提升人效，降低公司成本等作用。

1. SaaS产品中的业务承担

1）优化业务流程
在搭建产品流程时，一方面需要审视当前的业务流程，另一方面需要考虑未来的业务走向，提前考虑流程可能延伸点。
2）提升员工效率
3）促进资源转化
4）优化用户体验
产品的体验分为两类，UI体验和操作体验。操作体验直接影响到用户体验。
5）降低成本

2. 业务场景下的离线应用

1）离线应用面临的问题

• 支持本地存储机制
• 数据一致性
• 减少传输量及以保障数据安全

2）离线应用机制的闭环

离线应用的基本机制.png

3）离线应用的面面支持和数据库支持
离线应用需要解决本地存储 问题。数据库需要在客户计算机上运行，浏览器可以使用脚本调用本地轻便 型数据库来实现。
4）离线查询和离线更新
实现离线查询需要提前（在有网络的时候）将服务器端的数据下载到本地，对于SaaS应用则只下载当前租户的系统和业务数据即可。离线更新的业务对象涉及租户之外 关联数据。
5）增量数据
增量数据就是某个时刻或检查点之后的新增的数据
6）多客户冲突策略

• 覆盖策略:后提交者覆盖先提交者的内容，以的内容为最终结果。
• 丢弃策略:后提交者在提交前发现有人已经提交将自己的数据丢弃，在系统里仍然保留先提交者的内容。
• 提醒方案:当发生冲突时，将冲突信息提交给客户，由客户确定是覆盖还是丢弃。

SaaS产品功能设计自查

1. 数量上限下限自查

1）文本长度的限制
表单录入项需限制长度，一方面是因为数据有长度限制，另一方面是为了避免客户将无秩序的信息带入系统。
2）数值型字段限制
对于金额、尺寸、库存、跨度等本身就是数值型的字段，在限制的时候需要考虑实际的范围。
3）业务层面的数量限制

2. 命名和文案

1）提示文案
提示客户操作错误，不如给出建议，降低解释成本。
2）按钮命名
命名按钮时建议使用“动词+名词”的结构顺序。
3）提示类型与情景适配
提示的方式有对话框、气泡浮框、toast（吐丝）等，可根据需要提示内容的重要性进行选择。基于情景，还需要进行色彩强调。
4）注释说明
SaaS产品的功能有时候也很复杂，需要加以解释，并保证整体美观。

3. 离岸作业

对于一些需要离开系统作业的环节，需要考虑操作人员离开系统之后，可能发生系统信息状态变化导致的冲突。

4. 数据快照

数据快照用于记录之前发生事件时的信息，区别于当前的实时信息。

5. 数据传输的同步、异步和返回超时

第10章 SaaS产品页面和交互设计

略

这章太简单了都是基础知识，直接跳过