最近我在跟其他产品经理交流的时候，总能听到类似这样的话：“其实产品经理的基础能力都差不多，区别主要还是行业经验、对业务的理解能力、规划能力以及项目管理能力等等”，对此我是比较认可的。那么，产品经理的基础能力都包含什么呢？我打算整理一系列关于产品经理基础能力的篇章。

在最开始，我打算先跟大家讲一讲 ER 模型，原因很简单，ER 模型可以将物理模型转译为概念模型或者数据模型，能够很直接地将现实场景翻译为数字化场景，这实际上就是一款产品或者一项功能诞生的起始。

ER 模型（实体关系模型），是 Entity-relationship model 的缩写，最开始是由美籍华人陈品山于 1976 年 3 月在 ACM Transactions on Database Systems 发表论文《The Entity-Relationship Model–Toward a Unified View of Data》被人熟知，是用来描述现实世界的概念模型。

按我的理解，ER 模型其实就是一种简单抽象模型，用数据的方式来表达现实世界的关系，比如学生成绩单，用 ER 模型来描述就是：每 1 名学生都拥有 N 张成绩单，每张成绩单会包含学生姓名、学科、分数等；通过这样的描述，开发人员就能很好理解成绩单的数据表要如何设计，且也能知道学生和成绩单的关系。

ER 模型通常都是用 ER 图的方式进行呈现，而 ER 图通常需要包含以下元素：

实体：通常指的是数据模型中的数据对象、或者是现实世界中的主体对象，能够用属性描述的具体对象，比如学生是实体、成绩单也是实体（因为成绩单也具有多个属性，而且是具体的、实际存在的），实体一般用矩形表示。

属性：也就是实体具有的属性，比如学生的属性为学生 ID、学生姓名、学生性别、学生班级等，属性一般用椭圆表示。

联系：通常指的是实体之间的关系，有一对一、一对多、多对多三种联系，比如学生和成绩单之间的联系就是一对多，因为一名学生有多张成绩单，联系一般用菱形表示。

关于 ER 图，其实还有更多细节的东西，比如实体还分强实体、弱实体以及复合实体，属性也有复合属性、派生属性等，但这些并不重要，感兴趣的朋友可以留言咨询，产品经理只需要掌握好 ER 模型的基本绘制方法即可。而对于 ER 模型的运用场景，则主要集中在以下两种场景：

数据逻辑的梳理：也就是根据需求文档整理出数据表的需求，这样方便研发人员理解需求，比如要开发一个学生成绩管理系统，那么可以整理出系统相关的所有实体（学生、学科、班级、年级、成绩单等）、属性以及实体之间的联系。

业务场景的抽象：也就是把复杂的需求场景进行剖析，比较适合用于寻找共性，比如现在要设计一个任务模块，那么首先要做的是搜集各种任务类的场景，然后尝试找到其中的实体，比如事件、任务、奖励，每完成 N 个事件可以触发 N 个任务的完成，每完成 1 个任务可以完成 N 个奖励的派发。

学会 ER 模型，对于产品经理来说是非常有用的思维模型，它能够让产品经理对概念实体之间的关系、数据对象之间的关联有直接的认知，也能够让产品经理可以更容易将现实世界的场景转换为数字世界的场景。

想了解更多产品经理相关的知识和经验，欢迎关注我，和我一起共同进步。