以前我的PRD写的也不好，网上找的模版，逻辑上也经常会有遗失。后面我的直属boss跟我讲了一节课之后并且给了我他们当时的PRD模版，我学会了如何写好一份PRD
先看个反面案例：
前些天有个小伙伴找我，让我看下他的需求文档，是直接写在Axure里的。
我简单截2张图
乍一看挺像那么回事的，但其实不管是逻辑上、还是原型交互上，仔细看都会有问题。
以登录页面的需求描述为例：
1.图中1、2两部分的逻辑是有冲突的。1讲的是账号没有填写的时候，点击登录按钮会给予提示“账号不能为空”。而2讲的是登录按钮在账号密码未填写时是不可点击的。
那请问当账号和密码都没有填写的时候是可点击还是不可点击呢？
如果可以点击，那点击后的提示是提示账号不能为空还是密码不能为空呢？
2.图中3是指密码错误时候给予提示：密码错误请重新输入。看起来逻辑是正确的。但业务场景上是有问题的。
这样表述代表着你已经默认账号是正确的。
那是否会存在A用户的账号是ningshu，B用户的账户是ninshu。当A在账户上填写的是B用户的账户，那密码不可能正确。
因为错误其实不在密码上，而是在账户上。所以更准确的说法应该是：账号或密码可能有误，请重新输入。
3.图中4部分是指账号不存在的时候，输入框下方会进行提示：无此账号，请重新输入。
第一，没有触发条件，是需要研发监控输入框，每输入一个字符就去数据库查询是否有这个账户吗？显然不合适。
第二，哪怕你的触发条件是在光标离开输入框之后也不合适。因为判断账号信息应该在登录按钮时一起来判断，原本在一个操作上完整判断的事情不合适分开来处理
4.图中5部分只讲了自动登录，那什么时候自动登录会被取消呢？
是保持7个自然日的自动登录，如果用户登录后会重新更新7自然日的token记录，超出7个自然日不登录会被取消自动登录？还是其他的一些条件？
5.整个文档从逻辑上就有问题，在讲某一个页面组件，比如“账号输入框”的时候会出现其他组件的逻辑判断。（输入框提示账号不能为空）
你在和研发沟通的时候，研发的思维是跳跃着来，并且本身是登录按钮的逻辑被打散拆到了账号输入框、密码输入框等不同地方，对于单个组件的逻辑是不连续的。
6.登录按钮在页面上讲过有很多错误提示的情况。那请问这些错误提示的优先级是什么？
就像我们上面刚刚提到过的，既有账号不能为空，也有密码不能为空。那当账号密码都为空的情况下应该给予什么样的错误提示呢？
……
其实这里面还有很多问题。就不一一详细来说了。
那完整的好的PRD应该包含哪些内容呢？
1.版本管理
一份完整的PRD开头会有版本管理，首先一个项目的需求文档从开始到可被研发阶段会经历几个阶段：产品内部评审（部分团队没有）——>大型需求评审。那在这两次评审过程中必然会有一些不同意见的产生，导致需要进行文档修改。
那版本管理的作用就是得知道之前都是谁在写文档，并且修改了哪些部分，什么时候修改的。起到有迹可查。
有些团队写文档会用飞书、tower、tapd等在线协同软件。这些软件都会有这么个功能：版本管理。
2.评审纪要
PRD是给谁看的？PRD评审其实根据不同业务或者重要程度参与的人每次都可能不一样。
参与者会是以上11个岗位的其中1个或多个
当有这么多人参与进行PRD评审的时候，第一件事情不是讲具体的功能点事什么。
而是要和大家沟通为什么做这件事情，做这件事情对我们的业务有什么样的好处？也就是常说的需求目标是什么？
只有大家达成共识的时候在接下来的PRD评审过程里才能让研发和其他部门的人和你是在一个频道上思考的。
3.名词解释
我们做新项目的时候必然会涉及到很多新的一些名词，比如分销、售后中心。哪怕有些名词是很容易理解的，你也需要将它的意思写出来，从而让评审会上所有人对这些名词定义能达成统一理解。
这里又涉及到我们需求文档最重要的一点：统一所有项目组成员的需求理解和业务规则
4. 产品概述和目标
这部分占据着整个PRD文档的C位，最重要的内容，没有之一
这里总共有2个内容，产品框架和业务目标。
通过这部分告诉团队所有成员我们这次项目的目标是什么？要达到什么程度？涉及到的系统和产品框架是什么样的
只有理解了这个，才能继续讲具体的产品方案是怎么样的
5.产品roadmap
这部分并不是所有文档都需要的，只有大型项目才会用到，一个大型项目会分为几个阶段来实现，所以我们就得把Roadmap给制定出来，哪个阶段做什么事情。
6.产品风险
我们在修改原有业务流程的时候势必会产生一些分享，比如安全性风险，数据风险等。特别是大公司里跨系统做项目的时候，尤其明显。
所以我们需要讲所能想到的业务风险写下来，在评审的时候很可能因为这些风险会导致项目的实施方案进行调整
7.需求描述
这次的项目里需要做哪些需求点，需求点的书写和需求列表的逻辑是一样的。目标用户是谁？需求是什么？需求场景是什么？需求优先级如何？
用来判断不同阶段下需求是否要调整
8.可选技术方案
一个项目的实施可能有不多的方案，切记这个不是产品方案，是研发的技术方案。不同方案有各自的优缺点。要让评审人员一起看你们的技术方案，以及统一最终方案是什么
9.成本分析
做这个项目的人力成本和非人力资源成本（商务、PR等）是什么情况。这是用来判断资源投入的，如果这是一个非常重要的项目，你们的人力成本时间周期很大，那领导会根据需要调派更多人手来一起完成项目
10.功能需求
直到这里我们才开始讲本次具体的业务功能
所包含的内容有
- 功能流程图
- 功能状态图
- 具体业务功能的规则有哪些，原规则的修改有哪些
- 前后台功能清单是哪些
- 具体每一个小功能点涉及到的需求说明、业务规则、原型图、原型详细说明、usecase里的正常流和异常流。
详细的我们看图：
11.非功能需求
在一个项目中经常会出现和本身功能无关但又非常重要的需求。
比如：
财务需求（数据需要按照什么要的格式给到财务那边）
法务需求（在做这个项目的时候需要获得哪些执照，需要和用户签署什么样的协议等）
安全性需求（如何保障数据安全，如何防止被竞争对手进行数据抓取或者攻击等）
12.上线需求
最后一个，项目什么时候上线。上线的时间要求和初始用户数有没有什么要求
这就是完整的需求文档。并不是每个项目都要写这么全。可以根据自身项目的大小来调整。
