《不枯燥的B端产品实战课》

:::info 💡 根据 遗忘曲线：如果没有记录和回顾，6天后便会忘记75%的内容
读书笔记正是帮助你记录和回顾的工具，不必拘泥于形式，其核心是：记录、翻看、思考 :::

思维导图

用思维导图，结构化记录本书的核心观点。

读后感

观点1

产品经理需要具有结构化思维，和强大的逻辑分析能力

观点2

最基本的基础素养要有，里面有很多专业术语能确实帮助到我。

观点3

读完该书后，受益的核心观点与说明…

书摘

• 该书的金句摘录…

  认知篇

第1章 B端产品的本质

1.1 体现组织管理意志的数字化工具

B2B产品既包括内部管理系统，也包括能直接带来商业价值的商业化产品。

B端产品的本质是体现组织管理意志的数字化工具。

B端产品的分类只有一种——工具，即为了解决特定领域的问题，帮助人们更好地完成工作的辅助工具。

1.2 B端产品的分类

从运维部署角度来看，B端产品可以分为公有云、私有云、混合云和本地部署四种类型。

私有云是为某一个客户单独构建的云服务，B端产品的开发公司将应用和数据存储在客户指定的地方。根据客户指定地方的不同，私有云又可以分为内部私有云和外部私有云两种。

使用混合云，一个机构可以将次要的应用和数据部署在公有云上，充分利用公有云在扩展性和成本上的优势，同时将任务关键型应用和数据放在私有云中，保证其安全性。

本地部署是指产品的应用、数据都存储在一台计算机中，这台计算机不与其他任何服务器、计算机相连。

应用。判断应用所在的环境与谁交互，云环境是与浏览器交互的，所以在云环境下，我们所设计的功能要看浏览器是否支持；本地环境既可以与浏览器交互，也可以与操作系统、硬件交互，所以下载到本地的应用可实现的功能更多。

通常所说的SaaS产品其实就是将本地部署变为云部署的产品服务。

IaaS（Infrastructure as a Service），叫作“基础设施即服务”，简称IaaS。这里的基础设施多指硬件设备，如服务器、交换机等。

通过IaaS，企业可以将所有硬件采购和人员维护的事情都交由第三方专业公司管理，直接采取云端租用的方式，成本低、高效灵活。这种通过云端租用基础设施服务的方式就是IaaS。

除了降低成本、提升效率两种最常见的核心价值，B2B产品还有增强管控、降低风险等价值。

1.3 B端产品的演进

B端产品的演进路径中有四个主要阶段：定制化、商业化、多元化和平台化。

定制化阶段是B端产品发展的第一个阶段，也是必经的阶段。

定制化阶段的产品价值是解决某一组织内特定场景的问题，满足该组织的业务需求，但此时的产品无法直接产生商业价值，是公司的成本中心

此时的产品不仅要能满足特定且明确场景下的需求，还要具有一定的灵活性，以适应更多组织的情况，满足不同客户的需求。

产品在定制化阶段发展得足够成熟。判断产品是否足够成熟有以下几个标准。[插图]　产品已能够较好地满足主要业务需求，且功能基本完善。[插图]　产品稳定性良好，无重大Bug。[插图]　产品体验良好。[插图]　产品有独特优势。

B端产品客户使用和转移产品的成本很高

定制化阶段的产品就是商业化产品的MVP版本

B端产品的多元化包括业务多元化、行业多元化、部署多元化和终端多元化。

产品从原来单一行业解决方案向多行业解决方案发展。

产品从支持单一网络环境的部署模式，到支持多网络环境的部署模式。

如CRM系统，其用户多是销售人员，需要经常外出，所以对B端产品的移动端的要求更高。

例如，用户平常习惯用印象笔记记录信息，若你的产品在某些场景下需要这些信息，那么最好的方案应该是使产品可以与印象笔记对接，而不是重新做一个类似的功能。

ISV（Independent Software Vendors，独立软件开发商）

在打造平台型产品时，最关键的两个地方是如何制定标准和如何让第三方服务与产品已有功能深度结合。

第2章 B端产品的六大层面

在用户、需求、产品设计、迭代、运营、商业六大层面都有哪些差异

2.1 用户层面

业务方：产品所服务业务领域中的人员的统称，也可以说是产品主要用户的统称

角色：产品中具有相同权限用户的合集。

要想产品有更多的付费客户，B端产品经理不仅要分析使用者的需求，还要重点分析客户决策者的需求，并尽力满足，这样才有更大的概率拿下这个付费客户。

而在B端产品中，则经常出现“特权”现象（此处的特权是一个中性词，无褒贬之意），它包括角色特权、人员特权和客户特权。

不同角色对产品的使用权限大小不同，这与实际业务中的管理要求是相呼应的。

当决策者与使用者的需求相矛盾时，在无法折中的情况下，B端产品经理也会以决策者的需求优先

2.2 需求层面

在B端产品中，一般是由业务方主导需求，大多数的B端产品经理主要起到接收、分解、传递需求的作用。这个现象使得很多做B端产品的产品经理感觉自己不像是个产品经理，更像是一个画原型的“工具人”

B端产品经理对业务越熟悉，就越有主导权。

而在B端产品领域中，每种角色的需求相对更明确，不过这与业务所在行业的成熟度有关，一个行业的成熟度越高，需求就越稳定，业务场景也越明确，这为B端产品经理调研角色需求提供了方便。

只要业务上的管理规则确定了，产品需求就可以视为明确了。

角色需求趋同是指在同一角色背景下，不同用户的需求是趋近相同的，可以作为一个集体表达。

当你的产品的使用场景存在集体协作场景时，一定需要考虑多人同时操作的情况。

B端产品经理在设计产品功能时一定要考虑多人协作的情况。

如果B端产品经理没有极强的逻辑思维能力和抽象能力，在梳理需求时就很难发现这些关联点，轻则无法较好地评估工作量，重则前后逻辑自相矛盾，产品出现重大Bug。

B端产品与业务规则相关的文档一定要及时维护、保存，当遇到问题时方便及时查看。

B端产品是为了解决某个特定行业的痛点而产生的，B端产品经理要想做好产品，就一定要深入地学习和理解与产品相关的行业知识，否则做出来的产品会因为产品经理不懂其中的逻辑而漏洞百出。

所以B端产品的需求调研主要以深度访谈的形式进行。

2.3 设计层面

高度灵活是指为了让B端产品满足更多场景需求和应对未来可能遇到的问题，降低产品变动的频率和开发成本，B端产品经理在设计产品时需考虑产品的高度灵活性，以达到在不改动或只是小改产品的情况下就能满足更多需求的目的。

这个特点在产品定制化阶段要求可能不太高，但一旦进入商业化阶段，对这个特性的要求就会大幅提升

那么B端产品为什么需要这么高的灵活性呢？主要是因为对于B端产品而言，虽然在不同组织中，产品的业务领域是一样的，但在不同组织中，其业务领域中的制度、流程不完全相同，这些制度、流程都是长时间根据组织内部实际情况和管理方式逐步沉淀形成的，组织不可能为了适应你的产品规则而改变组织制度。

B端产品要想有更大的市场，就需要拥有高度灵活性，能够灵活配置各种功能，但灵活性与易用性在跨过一个平衡点后就会相互制约

因为产品的灵活配置意味着用户需要付出更高的学习、理解、记忆成本，才能将产品的功能配置成自己需要的，这时的体验自然不会很好。

B端产品经理设计产品时，不可能找到那个“完美的点”，让易用性与灵活性达到完美平衡，只能做出一定取舍——是牺牲灵活性多一点还是牺牲易用性多一点。

一是因为很多B端产品对这方面的要求不高，用户更多关注的是B端产品的功能。二是因为B端产品的页面形式多以表单为主，设计师可发挥的空间有限，多是给一些配色和排版布局的建议

2.4 迭代层面

如果B端产品的MVP版本作为产品推向市场的1.0版本，那根本起不到验证产品对用户痛点解决程度的效果，因为没有B端客户会为一个“残次品”买单。

对于B端产品来说，如果想要客户购买你的产品，那么产品的功能部分至少要达到其成熟形态的60%～70%

1）对客户而言，B端产品使用成本高

2）对团队而言，试错成本高

对于B端产品来说，我们的迭代策略则应该是“小步快跑，稳步上线”。

2.5 运营层面

如果B端产品在还没有形成口碑或有标杆客户背书的情况下，是很难让第一批客户建立信心的，因此就难以获取种子用户。

在B端产品领域中，如果没有实际的业务需求，很少有客户会以体验的心态使用产品，因此B端产品种子用户的获取就更艰难。

B端产品的运营人员不应该投入较多精力和资源在唤起沉默用户、提高用户活跃度方面，而是要把更多的精力投入到开拓新客户和维护老客户中。

产品价值=（新体验-旧体验）-替换成本

这也告诉很多B端产品的产品经理和企业经营者，并不是因为你的产品真的那么好，用户忠诚度才这么高的，而是因为用户的替换成本太高，所以B端产品的产品经理一定要有危机意识，及时发现客户不满意的地方，并重视老客户的关系维护，如果一个使用自家产品很久的客户决定换别人家的产品了，只能说明客户对产品失望了。

简单解释就是在B端产品市场中，你的竞争对手每多一个客户就意味着你少一个客户。

B端产品市场与C端产品市场相比非常慢热，根本不会出现像C端产品那样的指数级增长

2.6 商业层面

不需要非常庞大的客户数量就能养活一个团队，因此B端产品的生命力远比C端产品的生命力要强。

在用户/客户转移成本越低的行业中，就越容易出现“赢家通吃”的局面，马太效应就越强。

3.2 基础素养

思维方式、情商心态和通用能力三个层次，越低的层次越基础、越核心。

最需要具备的几种基础思维方式是本质思维、结构思维、逻辑思维和商业思维。

“第一性原理”是指在每一个系统的探索中，有一个最基本的命题或假设，不能被省略或删除，也不能违反。

本质思维是指我们在面对事物或问题时，要通过事物和问题的表象，看到其本质。

只有真正具备本质思维，才能从业务的表象需求中挖掘客户真正的问题，然后从他们的真正问题出发，找到更好的解决方案。

类比思维解决问题的方式是根据现有问题，类比曾经遇到过的问题（无论是自己的经历还是他人的经历），然后根据经验得到解决方案。
　本质思维解决问题的方式是通过现有问题的表象，探究问题本质，然后根据本质推论出解决方案。

本质思维的优点是不依赖经验，即使面对全新的问题也能解决，同时能从根本上找出解决方案，不容易跑偏；缺点在于需要耗费更多的时间、精力，非常依赖思考者挖掘事物本质的能力，所以真正能够拥有本质思维模式的人非常少。

越是新的领域，越适合采用本质思维

对于事物，我们可以运用“拆解——定义——验证——精简”四步法，以达到探寻事物本质的目的。“拆解”是指对这个事物按一定逻辑进行穷尽式拆分，找出其中的关键词及含义；“定义”是指对拆解的关键词及内容进行准确、完整地定义；“验证”是指将这个定义放在多个场景、多维度中验证定义是否正确；“精简”是指将最终的定义用最简洁的语言加以描述。当我们将事物按这四步进行探究后，基本就能找到其本质了。

逻辑思维是指人对事物、问题的思考有条理，有完整、清晰、合理的逻辑推论链条。

系统思维也可以叫作结构化思维。系统思维是指人对事物、问题的思考有清晰的结构框架，能够系统地、多角度地看待事物与问题。

MECE（Mutually Exclusive Collectively Exhaustive：相互独立，完全穷尽

商业思维是指产品经理需要能够从商业角度挖掘产品的价值，为公司创造商业价值。

如果一开始产品经理不知道未来怎么盈利，那是极其危险的。

产品最健康的状态一定是用户价值与商业价值和谐共存的，而不应陷入乌托邦式的浪漫主义中。

心理学中一般把同理心分为认知同理心、情感同理心和躯体同理心三种类型，其中产品经理需要了解和具备的是情感同理心和认知同理心。

它反应的是一种强大的心理素质，一方面遇事冷静，沉着分析，不被情绪左右；另一方面是以积极的心态面对挑战。

（1）对新鲜事物持有开放心态

（2）对不同看法持有开放心态

所以，对待不同的看法，开放的心态是指倾听、接收不同的声音，并自己做好最终决定。

热情是对自己选择的尊重，也是你在工作中遇到挫折时最重要的内驱支撑。

乔哈里视窗是一种关于沟通的技巧和理论，也被称为“自我意识的发现——反馈模型”。如图3-5所示，这个模型将人际沟通的信息比作一扇窗，将信息分为4个区域：公开区、盲目区、隐藏区和未知区。

对于这个区域的信息，我们需要学习，但切忌盲目接受，尤其是在和业务方讨论需求时，产品经理最重要的是学会区分什么是信息，什么是观点。

3.3 产品能力

需要从需求满足程度、成本、客户体验、未来扩展性及产品所处阶段等多个方面进行综合考虑

我们需要有意识地积累方案储备库，平时遇到一些比较好的解决方案时，可以随时记录下来，以便随时翻看。

4.1 调研准备

需要提炼的关键信息主要包括产品背景、业务痛点、业务需求（粗颗粒度）、领导要求、时间要求和预算等。

价值共识是指产品团队与业务方需要就产品价值形成共识，包括产品定位、产品目标、产品要解决的核心问题及衡量产品价值是否达成的标准。

需求共识是指产品团队与业务方需要对产品需求形成初步共识，包括需求范围、需求场景、用户角色及需求的优先级。

但在调研过程中不要讨论到方案层面，这是调研结束后要做的事。

理解共识是指产品团队与业务方需要对涉及的问题、知识、概念形成理解共识。

4.2 快速掌握业务知识

业务知识包括业务概念和业务规则两大类。

业务规则既有行业通用规则，又有组织自定义的特殊规则。

更有针对性的做法是直接看已经商业化的同类产品，从而预估自己的产品未来可能涉及的业务知识有哪些，然后有针对性地进行学习研究。

在学习业务概念时，B端产品经理要建立专门的知识库

我们要向业务专家讲解我们的理解是怎样的，让这些业务专家指出我们的理解中存在的问题，从而修正我们的理解。

根据业务专家的指导，校正我们理解上的偏差，确保双方的认知一致。

4.3 分析角色及干系人

无论是做B端产品还是做C端产品，产品经理都应该先想清楚产品给谁用，再看用产品的人有什么需求，我们不能脱离用户谈需求。

在调研B端用户需求时，我们是以角色为单位进行调研的。

从系统维度划分是指从系统管理角度，为应对特殊情况和非业务场景所设置的角色，常见的如系统管理员、超级管理员等。

总的来说，我们在确定角色时颗粒度要保持先粗后细的原则，前期一定不要把角色定义得太细，一旦角色定义过细，就会增加后续权限设计、产品开发、推广的工作量，当产品上线后你会发现，有的角色其实是多余的

判断角色及干系人的重要性，可以从多个维度进行分析，如对产品的刚需程度、使用频率、对产品成败的影响力、对产品感兴趣的程度等。

4.4 制订调研计划

调研对象职级最好由高到低排列。这么做的目的不是因为某些“职场文化”，而是因为职级越高的领导视野往往越开阔，看待事物与问题更深入，也更有话语权，所以我们需要先根据他们的调研结果来确定产品未来的方向。如果我们先调研职级较低的同事，很容易被他们不够深入的个人理解带偏。

4.5 调研内容

痛点是目标与现状的差距，需求是达到目标的愿望，功能是实现目标的方式。

客户的痛点，是我们调研的主要目标。产品经理要明确痛点是什么，是哪个角色在什么场景下产生的、发生频率多高、影响程度如何、影响范围多大。

4.6 调研方法

大多数B端产品的业务都是以流程为主线的

用户体验地图是一种针对某一角色，选择一个具体的业务目标后，按主流程及分支流程梳理此角色达到这一业务目标所经历的每个业务节点，并将其体验和感受用线状地图展现出来的方法。

（1）选择角色和业务目标

（3）绘制用户体验曲线

我们在定义B端用户痛点的频次时，不是以时间频率来定义的，而是以“每经历n次业务节点就会出现这一痛点”的方式来定义的

需要先分析这几个方案的优劣，如果有的方案优势互补，那么多个方案都可以保留下来，如果没有互补性，则选择其中一个即可

用户体验地图并不是一个适用范围特别广的方法，但特别适用于以流程为主线的B端产品

针对这类业务，我们主要采用深度访谈的方式进行调研。

描述现状：调研对象描述已经发生或正在发生的客观事实。[插图]　表达感受：调研对象对某些事物或问题的感受。[插图]　询问动机：调研对象采取某些行动、产生某些期望的动机。[插图]　征询建议：调研对象对提到的问题是否有解决方案或建议（是否采纳就要视情况而定），以及对产品的期望等。

产品干系人的需求都是通过深度访谈的形式来调研的，因为他们可能涉及业务不深。用户体验地图更适合调研重度参与业务的对象。

4.7 构建角色/干系人画像

我们的B端产品角色/干系人画像需要始终围绕业务场景来构建。

在这个角色画像中，主要记录的信息包括角色定义、业务职责、核心目标、主要痛点和期望建议

5.1 什么是产品规划蓝图

产品规划蓝图是以产品生命周期为发展脉络，将产品从定位逐步分解到细节功能，并进行版本规划的系统性战略分析方法。

5.2 战略分析与规划

战略层作为产品最高的一层，起到指引方向、统领全局的作用

而对于B端产品来说，则是先把用户需求调研清楚了，再分析战略。

业务维度是产品经理根据产品为业务方所带来的价值确定的产品定位

为了【人事部门同事】（目标用户）
　他们能够【更高效便捷地管理公司人事事务】（业务目标）
　这款HRM系统作为【人员数字化管理工具】（产品类型）
　可以【极大地减少相关人员的手工操作，提升事务处理效率，降低管理中的错误率】（产品价值）

公司维度是公司管理层根据产品对公司的价值所确定的产品定位

（1）对其他业务的关联影响

（3）对公司能力的沉淀

（4）对公司形象的塑造

（5）有利于公司的长远利益

技术上要考虑这些接口的同步机制、并考虑发量、容灾备份、数据脱敏等一系列问题

从目的上看，业务维度上的产品定位是分析产品如何匹配用户心智，公司维度上的产品定位则是分析产品如何匹配公司战略。

不确定产品经理是否真的理解到业务方的核心痛点，不确定产品是不是业务方真正需要的。

完善期的主要目标都是丰富产品功能，提升产品的稳定性。

5.3 需求要素分析与管理

我们主要从需求内容、需求角色、需求价值、需求场景、需求强度和需求频次六个要素进行分析。

B端产品经理判断一个需求对某个角色的刚需程度主要通过反向法。即在调研时，询问调研对象“如果没有满足这个需求会怎样”

这是因为人在拥有一件事物时是意识不到它的重要性的，只有失去时，才明白它对你有多么重要。

需求频率是需求发生概率的量化体现，主要是用来辅助判断需求的优先级的，在其他条件相似的情况下，越是高频的需求，就越要优先满足。

当一个需求可以与多个目标关联时，那么说明这个需求的颗粒度太粗了，需要对这个需求进行拆分

5.4 需求优先级分析

一般比较常用的细分优先级的方法有两个：KANO模型和时间四象限法。

将用户需求分为了基本型需求、期望型需求、兴奋型需求、无差异型需求和反向需求五类

发现我们对体验的记忆由两个因素决定：高峰（无论是正向的还是负向的）时与结束时的感觉，这就是峰终定律。

一般的做法是基本型、期望型、兴奋型三类需求同时推进，只是在不同时期各类型需求的占比不同，在产品早期，基本型需求的占比可能超过总需求量的80%～90%，随着产品逐渐完善，兴奋型需求和期望型需求的占比会逐步提高。

判断需求是否重要，用一句话概括就是分析需求与产品核心的紧密程度。

（1）第一顺位：与核心流程越紧密的需求越重要

（4）第四顺位：与核心角色越紧密的需求越重要

绝对紧急是指需求有明确的上线截止时间，在这个时间点前需求必须上线。

相对紧急是产品经理将多个需求对比后判断的需求紧急性，也就是这个比较紧急的需求如果不先做，相比于其他需求来说，给业务方、团队、公司造成的损失更大。

（1）越影响公司声誉、形象的需求越紧急

（2）影响范围越广的需求越紧急

（3）对后续需求影响越大的需求越紧急

（4）用户使用频率越高的需求越紧急

（6）投入产出比越高的需求越紧急

2）根据紧急性细筛需求

5.5 终端分析

终端分析是指根据已知需求，分析产品需要上线哪些终端、上线计划及各个终端最终具备的功能。

5.7 依赖分析

依赖分析，是指根据已知的需求分析产品要实现某些需求可能依赖的外部条件，主要指需要对接的第三方。

拉或推。如图5-17所示，拉是指当我们有需求时，先通过接口向依赖方发起请求，依赖方再把数据返给我们，这是最常用的方式；推是指当依赖方所提供的数据有更新时，其主动将最新的数据推送给我们，这种方式只有数据实时性要求非常的高的时候才使用，而且实现成本非常高、难度大。

第6章 产品设计

流程驱动设计和领域驱动设计

领域驱动设计相对复杂一些，主要应用于业务概念众多、业务逻辑及流程复杂的大型产品。

6.1 流程驱动设计

流程是指某一角色为了完成某一任务，有顺序地进行一系列操作的过程。

业务流程是指用户为完成业务目标所需要的完整闭环流程，无论是线上执行的步骤还是线下执行的步骤，是自己执行的步骤还是他人执行的步骤，均包含在内。

功能流程是指用户利用产品完成某一任务的流程，它与业务流程的差异在于功能流程仅针对产品中流转的部分，不包含线下步骤和在其他关联系统内流转的步骤。

状态流程是指一个对象在随功能流程流转过程中发生状态变化的过程。

跨职能流程图又称泳道图，是在基本流程图的基础上，将进程中各步骤按执行的职能单位（如角色）、系统或功能模块划分出一个个泳道

B端产品比较常用的辅助功能模块有：基础设置（为主要功能提供基础信息配置的地方）、工作台、帮助中心、消息中心等。

流程驱动设计是一种线性思维的设计方法，用开发人员的话说，这是一种“面向过程”的设计方式

在设计B端产品架构时，有个非常重要的原则叫作“高内聚、低耦合”。

高内聚的意思是让同一业务领域的管理实体、功能尽可能地聚合在一起，做到相近的业务形成内部聚合。

低耦合的意思是不同业务领域的功能尽量减少交叉和重复，降低耦合度，做到不同业务的关联尽量少。

6.2 微服务

“服务”是指用户可以感知的、独立的功能单元，每个服务都具有自主运行的业务功能，它既可以是一个个系统，也可以是一个个独立的功能模块

6.3 领域驱动设计

领域驱动设计（Domain Driven Design，简称DDD）是一种开发复杂软件的方法，是指在某个具体的领域中，一种面向对象的设计方式。

根据子域与业务关联的紧密程度，子域又可以分为核心子域、支撑子域和通用子域三类

核心子域是指从公司角度来看，业务中最重要的子域。

实体是指现实世界中具有唯一性的现实或虚拟的对象，简单理解就是领域中的一个个概念

聚合是指以一个强实体为基础，多个与之相关的弱实体共同组成的一个整体，其中的强实体也叫作聚合根。

领域模型是将业务领域中的概念进行抽象后，用具象的方式表现这些概念间关系的图形

找出需求清单中所有动宾结构的短语，将这些短语中的宾语提炼出来，然后将表达为同一个意思的宾语合并、去重，就能初步得到我们要的实体

对于有直接关联关系的实体，后面设计出的产品原型中就一定有需要用户手动关联的地方；反之，对于间接关联的实体，后面设计出的原型中就一定不能有用户需要手动关联的地方。

模型可扩展的重要性高于模型简化的重要性。

6.4 两种设计方法的关系

流程驱动设计更适合简单的小型产品，而领域驱动设计更适合复杂的产品。

对于复杂系统而言，我们需要先采用领域驱动设计划分子域，当将复杂领域化繁为简后，在子域内就能采用流程驱动设计的方式了

7.1 工作台

将工作台中常用的功能按面向用户群划分，可以分为普适性功能和个性化功能。

当常用功能特别多，不同角色的常用功能差异较大时，还可以增加快捷入口的自定义功能，由用户自己定义在工作台上放置哪些快捷入口。

7.3 搜索/筛选

1）关键字搜索or语义搜索

5）加历史记录or不加历史记录

前端搜索，是后端把所有数据通过接口一次性返回给前端，每次搜索时前端根据已返回的数据进行搜索，这样可以避免前端每次搜索时都要请求后端，重新加载、渲染所有数据，这种方式主要应用于数据量大、变动频率低的场景中。

7.5 用户-角色-权限

RBAC（Role-Based Access Control）模型是一种基于角色的权限管理模型。

用户有什么权限，不在于用户是哪个人，而在于用户是什么角色。

角色的定义：拥有相同权限的用户的身份标签。

RBAC-1是在RBAC-0的基础上，增加了继承关系，包括角色继承和范围继承两种。

角色继承是针对两个不同角色而言的，一个角色只能拥有另一角色的部分权限。这个角色的权限大小受另一角色权限的影响。

范围继承是指多个用户是同一个角色，但由于这些用户所在层级的差异，他们的操作权限虽然相同，但可查看的数据范围却不同。

RBAC-3是RBAC-1与RBAC-2的结合，即角色、权限既有继承关系，又有各类限制条件

弱角色是指在系统中不需要手动配置，用户进行某项操作或被他人指派后自动所拥有的角色

8.2 共建合作机制

事前定原则，事中建机制，事后细总结。

9.1 内部分析

标准一：核心功能基本完善

9.2 行业分析

PEST分析法是分析行业宏观环境的常用方法。即从政策（Policy）、经济（Economy)、社会（Society）、技术（Technology）四个维度分析行业的宏观环境。

市场集中度是决定市场结构最基本、最重要的因素，反映了行业的整合、竞争和垄断程度，集中度越低，竞争越激烈，集中度越高，竞争相对而言越小。

9.5 商业化改造

泛化设计是指为了应对未来客户的未知需求，让产品已有功能广泛适用于更多客户所做的通用性设计，从而在一定程度上减少产品商业化后面对的定制化需求。

相关资料