一、为什么需要一个优秀的PRD
小案例：需求评审，预计1个小时的时间，PM自信的打开PRD，开始讲述自认为想的很周全的需求，可是研发们发现了PRD上没有的各种细节逻辑并开始质问，PM急得一头汗的回应着各种问题，评审会议也终于在2个小时结束；开始开发了，RD发现这份PRD中仍然缺少了相当多的逻辑细节，于是一边心里暗骂PM不靠谱，一边去找PM确认，于是PM在整个需求开发周期中一边被喷，一边心累着跟进需求；需求开发完毕，PM开始回归，发现很多细节不是自己想要的，于是去找RD修改，RD认为你这个不靠谱的PM还敢修改需求后果断拒绝了，并给出终极大招，看，PRD上没写，PM此时可以做的，只能是沉默…
其实我们从上面发现，一个优秀的PRD的用处。
是PM基本功的体现
节省开发中PM的精力
增强在RD心中的靠谱程度（这很重要）
需求验收的标准
二、如何写出优秀的PRD
那么，如何写出一个优秀的PRD–精于心，简于形。
每份PRD都应该是PM心血的体现，都应该让一个对需求完全不了解的人能够知悉需求中的全貌和细节，但是没人会一开始就写出一份优秀的PRD，没人会在一开始写的PRD中就想到了所有的细节，一份优秀的PRD必然是PM踩着坑，总结着坑点，一步一步的不断完善才完成的，那么一个优秀的PRD，必须包含的元素有哪些？干货见下：
1、需求纬度
一个PRD首先应该展示的内容是需求，需求的背景是什么，没人会想做一个完全不了解或者没有意义的需求，作为项目的一份子，研发们有必要知道需求本身最重要的内容–需求背景是什么？需求意义是什么？而且PM和研发也必须知道本需求有效的衡量方法，接下来有个固定的方法，即：
2、业务纬度
精于心：一个需求/项目（比较大的）里面包括了很多小的需求分支、业务逻辑、甚至是之前没有的名词和定义，这里需要用心考虑周全，业务上所有的角色的流程都要考虑到，以免照成影响。
简于形：相比大段的说明文档，可能大家需要的是一个逻辑图。
业务纬度的内容见下：
1）业务流程图
需求的具体业务是怎么样的，涉及到哪些部门，物料/数据/信息在各个部门中是如何流转的。
以淘宝退款流程为例
2）操作流程图
用户角度对各个功能是如何使用的，页面跳转逻辑是怎么样的。
以登录流程为例
3）功能分支图
整个需求都包括了哪些功能，功能的具体做是什么？
4）新定义说明
需求中涉及到的新定义是怎样的，跟业务的关系是怎么样的？
3、页面纬度
说明了需求，说明了业务，下一步就需要具体到页面，这部分是用户真正看到的内容，这里的细节也是研发真正实现的时候最容易遇到细节不清楚的地方，所以，精于心特别重要。那么页面纬度具体包括哪些内容呢？
共有5个方面的内容：
1）角色区别
进入页面时是否分角色展示不同内容。
2）展示方式
进入页面后，默认展示的样式、多信息排列的规则、UE图涉及到的逻辑变化、控件点击前后的细节、文字数目的限制等都需要做详细的描述。
3）交互方式
页面中各个控件切换的交互方式是怎么样的，是否有特殊的交互方式需要特别指出
4）退出方式
页面退出逻辑是否遵从从哪里进，退回哪里的逻辑（以场景判断，属于需求层面），若不遵从，需做明显标识。
5）数据规则
刷新、缓存、加载、loading具体细节如何，都需要做出详细的描述，但是由于此部分涉及技术层面内容较多，故一定要与RD做好预沟通后再将确定的内容填写至PRD。
5、边界情况
非正常情况也需要在PRD中做详细的分类和描述，对于RD来说这部分不可缺失，且是PRD中最容易出漏洞的。边界情况大致包括以下6种。
1）登录相关
用户登录和不登录展示逻辑，是否可以进入功能等。
2）网络相关
无网/弱网如何处理，页面如何展示。
3）空页面相关
页面信息为空时如何展示
4）版本相关
历史版本如何包容新样式、新信息。
5）操作相关
用户在使用时杀掉APP，清理了缓存如何处理。
6）帐号相关
单个设备切换帐号后，如何处理数据。
7）数据相关
本需求中需要处理的数据在其他需求中有用到时，是否一并改动，如何兼容问题
6、一定记得检查你的错别字和排版
一个错别字会让你之前的努力大部分付之东流，错别字的出现将使好不容易获得的靠谱度急剧下降，所以别小看它，它是一个PM专业态度的体现。
回头再看看排版吧，是否看着舒服，信息清晰易懂，这决定着这份PRD的第一印象，请像对待一件艺术品一样，对待PRD，排版也需要精于心，简于形。
三、写在最后的话
一份PRD不仅仅是一份PRD，看一份PRD，就能看出这个PM的逻辑性、思考的缜密性、对需求的理解、对美的理解，也就代表了一个PM的水平。
精于心，简于形，对待PRD，也需要如此…
CIO之家 www.ciozj.com 公众号:imciow