PRD总是被吐槽？试试掌握这些底层思维！

产品经理，大概可以分为三个级别：初级、中级和高级。

初级产品经理，最重要的能力是写好PRD，能够保证功能模块设计得没问题，正常上线。

中级产品经理，最重要的能力是做好用户需求分析，识别用户价值和商业价值，让上线的需求具有较高的投产比。

高级产品经理，最重要的能力是具有一定的商业操盘能力，能够识别市场需求，将需求转为产品，通过产品来实现盈利。

这是一个递进关系，要往上走，必须具备下一层的能力。比如，你想成为高级产品经理，你必须具备优秀的PRD写作能力和需求分析能力。

但是刀哥发现，现在职场中，有一些产品经理，有着中高级产品的Title，看似干着中高级产品经理的事，却连最基础的PRD都写不好。

虽然需求能写出来，但总是漏洞百出，工作中很大一部分时间，都用在和开发扯皮，费心又费力。

那么，到底怎么写PRD，如何才能写出好的PRD，腾出更多的时间去研究市场、竞品？

这篇文章，刀哥给你们分享一些思路。

需要说明一点的是，不同的公司，不同的产品经理，PRD的形式可能都不一样。

有些公司有Word+原型截图，有些公司用Axure+备注，有些公司，压根不写PRD，全靠口头交流。

刀哥这里仅分享思路，具体的呈现方式，不一定有统一的标准。

1.PRD

PRD，就是产品需求文档，是产品经理提交给研发团队，对于需求描述的文档。

产品需求文档，不是描述用户需求的文档，也不是描述商业需求的文档。

我们写的PRD当中，99%都是在写功能需求，所以，不要在PRD里写太多用户场景、项目介绍等资料。

写了也没啥人看，对于项目或者业务的描述，应该用其他文档来描述，PRD的重点是对于功能的描述。

用户提交产品的需求，所使用的语言，叫自然语言，我们人与人之间的沟通，都是自然语言。

研发提交给计算机执行的指令，叫编程语言。

自然语言放松、发散，没有那么严谨。

编程语言标准、逻辑性强，必须非常严谨。

作为产品经理，我们处于用户和研发之间，既不用自然语言，也不必用编程语言。

而是用UML。

2.UML

UML，也是一门语言，UML是统一建模语言。

是产品经理跟研发说话的语言。

有的产品经理，在PRD里，用自然语言写，研发痛苦不堪。

有的产品经理，在PRD里，用编程语言写，把研发的实现方案都写好了，搞得研发觉得没什么存在价值，自己还特别累。

使用UML语言里的几个核心逻辑图，就可以把PRD写得很清楚，这是写PRD的底层思维。

掌握了写PRD的底层思维，才有可能写出逻辑缜密的PRD。

这几个逻辑图分别是：用例图、业务流程图和状态机。

3.用例图

用例是对参与者通过系统达成目标过程的描述。

用例是UML里面的标准术语，也可以理解为功能模块，用例是参与者和系统的交互过程，是第三方视角，而功能是系统视角，可以从这个角度来加以区分。

一个完整的用例，包含用例名称、参与者、前置条件、后置条件、主流程、备选流程、业务规则，这几个部分。

用例名称：用例名称是一个动宾结构，如新增用户、修改用户、删除用户。用例也有层级结构，比如管理用户是一级用例，而新增、修改、删除，为二级用例。

参与者：是指执行这个用例的角色。

前置条件：要执行这个用例，需要具备的权限、状态等。

后置条件：执行完用例后，系统如何处理，比如增加一条数据、删除一条数据、变更状态等。

主流程：用户达成目标的正常流程，分为参与者和系统。

备选流程：包含异常路程和分支流程，这部分是在梳理需求时，最容易被遗漏的。

业务规则：系统根据具体的规则来执行处理，这些规则，需要在用例的描述清楚，业务规则也是容易遗漏的点。

以下是一个用例的模板：

用例，是写PRD最重要的一个逻辑思维。

用例是一个逻辑概念，把产品分成用例，一个用例包含业务逻辑、业务规则、字段规则和界面交互。

我们在写PRD的时候，从这几个方面去思考和描述，就可以了。

4.业务流程图

业务流程是不同角色，完成业务目标的先后顺序，是一系列步骤、程序，是对每个环节进行的程序化处理。

角色可以是任何对象，例如人、系统、部门、公司…

一个业务流程由多个连续的活动组成，复杂的业务流程还分为子流程。

业务流程有多种类型，例如部门人与人之间的业务流程、用户(人)与系统(产品)的交互业务流程、系统与系统之间的业务流程。

人与人之间的业务流程如公司的请假、调休、转岗、离职等，OA系统里面会有很多这种流程。

人与系统的业务流程如注册、登录、找回密码这些基础流程，还有如打车、叫外卖、购物的业务流程。系统可以看作是一个黑箱子，箱子里面又包含有前端和后端等。

系统与系统的业务流程主要在于进行数据交互，系统使用结构化设计，将整个系统拆分成很多聚合度很高、耦合度很低的模块，模块之间除了内部交互外，还需外部系统进行交互，系统之间的交互通常使用接口。

每个业务流程都由多个连续的活动组成，例如请假这个业务流程，里面的活动有填写请假单、审批请假单等活动。注册的流程涉及填写手机号、获取验证码、输入密码等活动。

多个角色完成同一业务目标时，使用泳道图，一个或两个角色完成同一个业务目标时，使用活动图。

5.状态机图

状态机图，用于描述某个实体的状态变化和流转规则。

状态机图对于梳理业务逻辑和开发实现，有很大的帮助。在实际工作场景中，写一大堆文字来描述状态流转，效果通常都不太好。对于状态定义及流转的描述，状态机图是最好的工具，没有之一。

状态描述最常见的应用场景，是对各类订单的描述，如电商的订单状态、快递物流状态、支付状态等。

状态机也不复杂，只需遵循以下几个原则，即可画出高质量的状态机图：

1、有限集合。状态都是有限的，需要枚举所有状态。并且每个状态都能体现一个实体的某个阶段。

2、状态互斥。状态之间，一定没有重合的地方，必须互斥。

3、可能具备子状态。子状态的前提，是有子订单，比如，电商的主订单是购物订单，基于这个购物订单，衍生出了支付订单、物流订单、售后订单，在待发货这个状态下，有退款中和退款完成两个子状态。

4、持续一定时长。状态是能持续一定时长的，而不是瞬间状态，比如创建一个订单，创建这个过程，由代码执行，需要一定的时间，但是很短暂，我们如果定义一个“创建中”的状态，就没有必要。

5、包括已中待其中一个词。定义一个状态时，通常使用“已”、“中”、“待”其中一个。

以下是一个电商订单的实例：

从示例图中，我们可以看出，一个完整的状态机图，包含几个核心要素：

1、开始和结束。开始通常代表产生对象的开始，结束代表状态已经进入终态。

2、状态流转的条件。从一个状态流转到另外一个状态，必定有1个或多个事件。

3、状态本身。定义订单当前的阶段。

状态机图跟实体关系图一样，画法很简单，但是代表的是对状态的定义和规则的思考，帮助巨大。

可以使用ProcessOn、Visio、Axure就可以很方便地画出来。

----------- End -------------