稍微有点经验的产品经理，基本上都会写好一份PRD，那到底要具备哪些特点，才能让开发、测试一致称赞你的PRD？
如果你去采访几个周围稍微有点经验的产品经理：“你认为你写的PRD是一份好PRD吗？”
答案可能会高度统一：“Yes,itis！”
在产品经理岗位上耕耘这些年，我的PRD收到了来自开发GG和测试MM的不计其数的建（pi）议（dou），终于收获了长足的进步，最近一年写的PRD在开发、测试团队中获得了一致的认可。所以如果你要问我这个问题，我的答案也会是：“Yes,itis！”
但如果再追问一下：“你认为什么样的PRD是一份好的PRD呢？“
这个时候答案就会千奇百怪了，“思路清晰，排版整齐……”每个人可能都巴拉巴拉列举一大堆的特征。
在我看来，在一个真正的产品经理眼里，世间万物，只要是人造出来的，都是产品。产品上市之前，PRD就是产品经理交付的第一个产品。对这个产品经理交付的第一个“产品”，至少应该具备以下4个特点，才能算是一个好的产品（PRD），即：价值明确、考虑全面、可读性强、修订留痕。
一、价值要明确
能帮助用户解决问题，则产品是有价值的；而有价值，是一个产品诞生的原点。产品是为了解决用户问题的，PRD是为了打造帮用户解决问题的这个产品而编制的。
那么，你的产品最终要解决的是用户在什么场景下的什么问题？要实现的定性目标是什么？定量目标是什么？
在你的PRD当中把这些内容写清楚，一方面，可以让自己更加清晰地理解和审视项目价值；另一方面，也让开发、测试同学知道自己要做的工作是有价值的。
这有什么意义？这么说吧：
有工资拿，我做到朝九晚五；
有价值感，我自愿朝九晚九。
让团队知道他们做的工作是有价值的，并且让他们知道能实现什么样的价值，是凝结一个团队克服重重困难，滚滚向前的最为重要的力量。因此，一份好的PRD，一定会有关于它的项目价值的清晰描述。
二、考虑要全面
衡量一个产品经理PRD功力的最为关键的指标，就是看他是否考虑得足够全面。我将产品经理考虑全面的功力分成三个段位：
第一级：模块内全面
在这个段位上，产品经理能考虑到在正常情况下，所设计模块当中可能的应用场景，每个场景下有哪些分支流程和处理逻辑。
比如：在下单流程中，能考虑到针对接口返回成功、失败的各种场景的处理逻辑；同时，也能考虑到在正常场景或流程之外，有哪些异常场景，并设计对应的处理方式。比如：下单流程中，接口响应超时场景怎么处理。
第二级：模块外全面
这个段位上的产品经理，不仅能考虑到所设计模块的各种正常、异常场景，还能考虑到这个模块的调整会影响到的其他系统模块，并在PRD当中给出相应的应对策略。
比如：当你在门票的下单流程中调整了游玩人信息的处理逻辑，你能否考虑到对酒店品类的下单流程的影响。
第三极：扩展性全面
到了这个段位上的产品经理，不仅能对当下的模块内容的场景考虑全面，还能考虑到未来三到五个迭代版本之后可能的产品形态。
他在自己的设计方案中预留产品扩展空间的同时，也在前期PRD当中对可能的扩展需求进行标注，以提醒开发人员在代码层、数据结构层预留充分的扩展空间。
比如：你负责了一个旅游平台订单重构的项目。在第一个版本中，你只对门票的下单流程进行了重构，但你在前期的方案设计阶段，除了对现阶段门票订单的重构方案进行全面的设计，还能考虑到未来1年之中，对酒店、线路品类进行重构时的主要场景需求，并在产品方案中预留出扩展空间以供未来扩展。
三、可读性要强
这一点应该很好理解，PRD全称ProductRequirementDocument，即产品需求文档。因此，它的本质还是一份文档，对于开发、测试团队成员来说，还是一份需要仔细研读的文档。对于需要研读的团队成员而言，一份可读性强的PRD可以节省大量的时间，有效提高开发和测试的工作效率。
那么，啥叫可读性强？
我认为可读性强的PRD包括三个特点：
1.一个文档覆盖完整需求
这是对于文档可读性的最基本的要求，刚做产品那会儿，沉迷于各种所谓的PRD模板和绘图工具，大致就是用Xmind画脑图、用Axure画原型，用visio画流程图，然后再用word写PRD。
尽管也会在PRD中把重要的界面原型截图放进去，但有时候，Word无法很好地呈现一些交互效果，或者比较大的visio图在word里面看不清的时候，开发、测试团队就需要html原型文件、word、visio几个文档一起看，并进行来回切换。有时候也会出现开发人员嫌来回切换麻烦，干脆直接就简单看看原型图，之后就按照自己的想法开始coding了。
很显然，从阅读体验来看，用word来写的PRD很难一个文档覆盖完整需求，也不是一份可读性很强的PRD文档。
那么，有没有什么方式是可以实现一个PRD文档覆盖所有需求的呢？
在这里推荐一个比较好的写PRD的方式——直接在Axure原型中撰写PRD，这也是目前我所在公司撰写PRD的方式。自从在Axure中写PRD之后，原型、流程图、需求说明都被写在了一个原型文档当中，开发、测试再也不用几个文档来回切换着看了。
另外，除了便于团队成员在一个文档中查看完整需求之外，对于产品经理而言也有诸多便利。比如：多文档无需来回腾挪，调整时只需维护一个文档即可，无需担心漏了某个文档，可以按照页面撰写，伸缩性强等等。因此，如果你还在用word写PRD，建议你赶紧抛弃word，拥抱Axure吧。
2.文档有清晰的框架结构
一两页就能写完的小需求PRD，框架结构对可读性的影响自是不大，但是对于超过10页的PRD文档来说，框架结构对于可读性的影响就比较大了。
经过我多年实战经验，化繁为简，一个好的文档框架大致是如下一个结构：
封面：需求名称、版本、更新日期、作者等；
修订记录：修订时间、修订人、修订位置、修订内容、修订原因、审核人等；
文档说明：需求背景、解决方案、项目目标、产品范围等；
总体流程/架构：产品架构、主流程、主要功能模块简述等；
模块一：模块名称、用户场景、产品用例等；
模块二：模块名称、用户场景、产品用例等；
迭代版本1：版本名称、时间等；
迭代版本2：版本名称、时间等；
附录：会议纪要、遗留问题等。
3.排版清爽、条理清晰、图文并茂
好比是人不能只有骨骼没有血肉，PRD光有一个清晰的框架结构还远远不够，因为开发、测试团队看得最多还是具体的细化的功能需求，而这些细碎具体的需求内容实际上也是最应该考虑可读性的地方。
如何提高内容的可读性？尽可能让你的需求描述具有清晰的条理和清爽的布局。
几个提高内容可读性的小技巧分享给大家：
需求描述和原型一一对应，且不宜相隔太远；
图文并茂，尽量避免整版整版的文字；
能用图描述的，就不要用干巴巴的文字；
的确需要大段文字描述的内容，分拆成一个一个的小点描述。
总而言之就是一个原则：让用户看起来不那么累。
四、修订要留痕
需求变更对于产品经理而言是难以避免的，在项目进入开发阶段之后，对PRD所做的所有变更一定要留下痕迹，这些修订痕迹包括两种：修订记录及修订标注。
1.修订记录
通常情况下，一份合格的PRD里面一般都会标配一个如下图所示的修订记录，这是一份PRD最基本的修订痕迹。
据我观察：即便是在我目前这样一家相对成熟的互联网公司当中，依然存在大量的修订记录形同虚设的情况。要改什么内容，产品经理直接跟开发测试说一下就改掉了。
为什么会这样？
有的时候可能是因为忙，忘记了；有的可能是因为懒，懒得改；而最主要的原因还是在于产品经理缺少修订留痕的意识，认为这种细碎的工作没必要。
实际上这个修订痕迹是非常重要的，他直接反映了PRD文档的变迁史，也让开发、测试团队对PRD的变化做到同步更新，避免团队做无用功，避免不必要的扯皮。
由于没有修订记录，跟开发和测试扯皮自然难以避免，即便没有扯皮，产品最终上线之后的实际情况与PRD有诸多不符，也会逐渐就演变成了给后人挖的一个接一个的坑。有良心的产品经理，不给后人挖坑。
2.修订标注
当然，有了修订记录痕迹，如果你能秉持着心中的用户思维，产品思维来对待，你会认为这是不够的，为什么？
因为开发测试要从你洋洋洒洒十几页的PRD当中，找出你改动的那两段文字依然是一件很困难的事情。
怎么解决开（yong）发（hu）的这个痛点？
对于一名产品经理而言，要解决这个问题实在太容易了，把修订内容标注出来不就可以了嘛。如果你是用Word写PRD，解决这个问题简直soeasy，直接在“修订”模式下编辑文档就可以了；如果你是用Axure写PRD，也不难，只需要把你改动的位置用其他颜色标记一下就可以了。
在这里分享几个火山的PRD中的一些修订痕迹：
Word修订模式标注留痕：
Axure橙色字体留痕：
流程图橙色填充留痕：
这样的PRD痕迹可以给开发、测试小伙伴带来巨大的便利，做起来很容易，也花不了太多时间，当然，要做到前文描述的所有要求其实也都不难，关键取决于你是否有这个意识这样去做而已。
从根本上来说，其实是取决于你是否把你写的PRD看做是你的一个产品，是否把你的开发、测试搭档看做是你的用户。
三、总结
PRD没有标准，所以什么样的PRD是一份好的PRD，这实际上是一个仁者见仁智者见智的问题。本文阐述的好PRD的4个特点也仅代表一家之言。
那么，这个问题谁最有发言权？它的读（yong）者（hu）。
PRD文档的读者是谁？UED、开发、测试、业务需求方以及未来要接手你工作的其他产品经理，都会成为它的用户。
产品好不好，产品经理说了不算，用户说了才算。所以，回到文章开头的问题，如果你也认为自己的PRD写得很好，不妨再找几个搭档的开发、测试同学问一下，看看结果会是怎样……
#专栏作家#
PM火山，