市场、运营或用户反馈，我们需要这样，需要那样的产品改进或产品设计。需求审核也已经通过了。接着产品理完思路，进行流程设计，产品设计也随之做好了。一脸蒙蔽，这些产品设计和设计的细节全部在产品经理的脑海里呀，怎么办？总不能天天跑到技术哪里，我需要技术实现这样的产品需求，需要实现那样的设计效果，每天口头一遍一遍的交流吧？嗯？作为产品，有这样的需求或则有这样的疑惑。对头，PRD就是为这样的需求或则这样的疑惑而生的。PRD的作用就是，把需求白字黑字外加图像的生动明确的表示出啦，便于技术开发；便于需求更改，便于需求记录；便于需求沟通……等等。有了PRD,需求沟通时的撕逼大大减少。
如果市场分析、用户研究、用户需求分析是用户、市场告诉我们需要什么的产品，那么PRD文档就是把产品需求告知给技术实现的直接方式。PRD是这样的存在：
避免出下如下图的悲剧，保证产品人员的人身安全。我们有必要认真好好探究探究，PRD应该怎么样写？怎么样才能写出一份合格的需求文档。
一份合格的需求文档应该包含这些内容。
一、PRD文档头：文档名称、作者或则撰写人、文档编写日期、版本纪录、目录。
写个需求文档，你的告诉人家这是什么吧？这是什么文档，不然人家技术还以为你是给人家发的什么少儿不宜的文档呢。有了文档名称的告诉人家是谁写的吧。人家要拿显示器砸你应该找到人对号入座，不然会殃及无辜的。文档日期也写上，不然人家技术会认为，这需求已经是去年提的需求了。没有版本纪录，鬼知道你这是第几版。目录，清晰的记录文档的脉络结构，让人知道怎么去读你的PRD文档。合格的文档头，应该长这个样子的
OK有了一个漂亮的文档头，那下来就到文档里面内容的填充咯。
二、PRD文档内容结构
PRD文档内容结构包括：概述、产品需求说明、产品流程说明、产品结构和功能说明、其他产品需求、上线需求说明。如果需要的话有相关文档，附件说明。
1、概述。
从大的方向，讲讲项目的相关背景、有什么目标、有没有竞品对像？而阶段性计划是什么？传递做这个需求的目的是什么？要达到什么样的目标？要达到这个目标阶段性计划是什么？
2、产品需求。
落到具体的地方，产品有哪些需求？增加了哪些需求？调整了什么？取消了什么？需不需要其他资源的配合？有什么影响？，从这几个地方说清楚。
3、产品流程说明。
讲清楚每个逻辑点，每个地方应该怎么走？应该做什么样的判断？如果进行这个操作返回给用户什么内容？用户触发之后得到什么内容？
常见的流程图：
泳道图：
4、产品结构说明。
根据产品的内在逻辑，分解、细化需求，将需求细化说明。针对内在的需求逻辑，考虑到那个需求不同情况的不同反馈，逻辑严密，考虑到每个逻辑分支。如果有和其他产品关联，考虑到对其他产品的影响。在描述的时候，不要用户含糊的词语，“可能”、“也许”之类的词语。如果无法biao表述清楚，可以举个例子说明。
例如：
必要的时候添加用例说明：
举例：
5、其他产品需求。
涉及到其他产品的产品线时，需要协同多个产品线进行多方面考虑。协同调整，避免出现遗漏，出现不必要的偏差。
6、相关文档。
如果一个项目分解成多个团队。多个需求文档协同合作。如一个UGC社区，有PC端社区，有APP端社区。这需要不同的研发团队，Web前端、APP又分为安卓、iOS。所以需求文档会拆分为PC端需求文档和APP端需求文档。
7、上线需求。
测试通过的需求，具体的上线时间，具体一些特殊的流程需求等。
8、其他需求、附件。
作为需求的一种补充，对一些需求进行补充说明，或者需要的文件说明等。
结束语
OK这样一个文档下来，需求明确了，如果要改需求也是有版本纪录，有方向的改进了。不然，作为个产品经理你时不时跑到，跑到技术那边所以一嘴，哎呀，哎呀，这个需求不是这样的呀，你做错了，重新改。技术保证打不死你，人家辛辛苦苦做出来，然后你所不是这样。送你大大的一个白眼。写好PRD，真爱生命，远离撕逼。最后，豌侠所说的都是没用的，大家自行体会。
作者：豌侠。
微信公众号：豌侠说（ID:wanxiashuo）
