PRD到底应该怎么写

PRD到底应该怎么写

PRD，也就是产品需求文档到底该写什么不该写什么本来已经没有什么悬念了，但是写PRD的时候会写上技术实现的细节，还有就是系统数据的交互逻辑，也就是数据在数据库里面是怎么交互的。这些东西应不应该写在PRD里面呢？

其实除非这些内容会影响到商业价值，否则不要写，如果觉得有必要，可以和技术沟通。

首先，来理一下思路，PRD到底是干什么的？从某个角度来讲，PRD是项目价值实现链条中的一个重要环节，前面接着BRD和MRD，也就是商业需求文档和市场需求文档，后面连着技术团队，它其实要严密匹配BRD和MRD，同时告诉技术团队如果要实现项目的预期商业价值，要实现的产品的这个版本应该做成什么样。换句话讲，PRD的读者是：程序员、UI/UE、测试、还有就是合作伙伴。

言归正传，站在理想层面和个人经验来看，PRD应该包含下面十几项内容，主要有：项目背景、需求来源、版本号、变更内容、术语表、角色定义、角色功能关系、基本规则、功能流程图、页面流程图、信息架构、Use case、原型等内容。挨着个儿来说一遍吧。

首先就是项目背景，里面包含了项目的来源、目标、商业价值、项目计划等内容，这些内容因为比较多，而且分布在多个文档里，所以在这里不要复制粘贴相关的内容，只要一笔带过，说参考BRD、MRD和项目计划就可以。看到了这些内容，技术团队才有可能了解项目的来龙去脉，才能够更好地配合，也才能有更大的成就感。

然后就是需求来源，这一点经常被忽略，这些需求到底来自于市场调研、经营目标、合规性审查、线上的Bug还是干脆就是某个CXO拍脑袋的结果，都要写出来，如果在别的文档里有，一笔带过说参考某文档就可以。

下一个就是版本号，当前线上版本的版本号是多少，现在这个PRD对应的版本号是多少，在产品路线图里处于什么位置。

变更内容要说明这个版本的产品和上个版本相比有什么地方不一样，是业务逻辑变了，还是交互方式变了，需要说清楚。

术语表就不用说了，我们都知道。

角色定义需要说明这个版本的产品涉及到哪些角色，比如和上个版本相比，这个版本新增加了人工审核订单的功能，那就需要说明订单审核员这个角色的相关定义。

角色功能关系说明了每一个角色和哪些具体的功能相关，既可以写文字，也可以画图。

基本规则有的时候也叫做全局规则，就是在这个版本中需要遵守的最基本的规则，在描述基本规则的时候可以举例说明或者是写一些伪代码。

功能流程图就是功能执行的先后顺序，可以理解为业务流程图。

页面流程图描述了各个页面之间的交互和跳转逻辑，注意要包括页面的入口，比如页面挂在哪个菜单下面也要说清楚。

信息架构是信息的呈现形式和内容。

Use case也就是用例，这是描述需求的核心方法。

最后就是原型，不细说了。

上面这十几项内容是应该写在PRD里的内容，哪些内容不应该写在PRD里呢？主要是下面4项内容：

1.软件设计和实现方案不能写，这一部分由技术团队自己搞定。

2.项目的质量标准和验收标准不能写，这部分包含在项目文档里，PRD里最多加上引用。

3.项目计划不能写，这部分内容包含在项目文档里，PRD里最多加上引用。

4.项目的目标和商业价值不能写，这部分内容包含在BRD、MRD或者是项目文档里，PRD里最多加上引用。

最后，PRD里应该写什么不应该写什么没有绝对的标准，需要综合考虑项目、产品和组织等因素来决定。