开发测试
稍微有点经验的产品经理，基本上都会写好一份PRD，那到底要具备哪些特点，才能让开发、测试一致称赞你的PRD？
如果你去采访几个周围稍微有点经验的产品经理：“你认为你写的PRD是一份好PRD吗？”
答案可能会高度统一：“Yes,it is！”
在产品经理岗位上耕耘这些年，我的PRD收到了来自开发GG和测试MM的不计其数的建（pi）议（dou），终于收获了长足的进步，最近一年写的PRD在开发、测试团队中获得了一致的认可。所以如果你要问我这个问题，我的答案也会是：“Yes,it is！”
但如果再追问一下：“你认为什么样的PRD是一份好的PRD呢？“
这个时候答案就会千奇百怪了，“思路清晰，排版整齐……”每个人可能都巴拉巴拉列举一大堆的特征。
在我看来，在一个真正的产品经理眼里，世间万物，只要是人造出来的，都是产品。产品上市之前，PRD就是产品经理交付的第一个产品。对这个产品经理交付的第一个“产品”，至少应该具备以下4个特点，才能算是一个好的产品（PRD），即：价值明确、考虑全面、可读性强、修订留痕。
一、价值要明确
能帮助用户解决问题，则产品是有价值的；而有价值，是一个产品诞生的原点。产品是为了解决用户问题的，PRD是为了打造帮用户解决问题的这个产品而编制的。
那么，你的产品最终要解决的是用户在什么场景下的什么问题？要实现的定性目标是什么？定量目标是什么？
在你的PRD当中把这些内容写清楚，一方面，可以让自己更加清晰地理解和审视项目价值；另一方面，也让开发、测试同学知道自己要做的工作是有价值的。
这有什么意义？ 这么说吧：
有工资拿，我做到朝九晚五；
有价值感，我自愿朝九晚九。
让团队知道他们做的工作是有价值的，并且让他们知道能实现什么样的价值，是凝结一个团队克服重重困难，滚滚向前的最为重要的力量。因此，一份好的PRD，一定会有关于它的项目价值的清晰描述。
二、考虑要全面
衡量一个产品经理PRD功力的最为关键的指标，就是看他是否考虑得足够全面。我将产品经理考虑全面的功力分成三个段位：
第一级：模块内全面
在这个段位上，产品经理能考虑到在正常情况下，所设计模块当中可能的应用场景，每个场景下有哪些分支流程和处理逻辑。
比如：在下单流程中，能考虑到针对接口返回成功、失败的各种场景的处理逻辑；同时，也能考虑到在正常场景或流程之外，有哪些异常场景，并设计对应的处理方式。比如：下单流程中，接口响应超时场景怎么处理。
第二级：模块外全面
这个段位上的产品经理，不仅能考虑到所设计模块的各种正常、异常场景，还能考虑到这个模块的调整会影响到的其他系统模块，并在PRD当中给出相应的应对策略。
比如：当你在门票的下单流程中调整了游玩人信息的处理逻辑，你能否考虑到对酒店品类的下单流程的影响。
第三极：扩展性全面
到了这个段位上的产品经理，不仅能对当下的模块内容的场景考虑全面，还能考虑到未来三到五个迭代版本之后可能的产品形态。
他在自己的设计方案中预留产品扩展空间的同时，也在前期PRD当中对可能的扩展需求进行标注，以提醒开发人员在代码层、数据结构层预留充分的扩展空间。
比如：你负责了一个旅游平台订单重构的项目。在第一个版本中，你只对门票的下单流程进行了重构，但你在前期的方案设计阶段，除了对现阶段门票订单的重构方案进行全面的设计，还能考虑到未来1年之中，对酒店、线路品类进行重构时的主要场景需求，并在产品方案中预留出扩展空间以供未来扩展。
三、可读性要强
这一点应该很好理解，PRD全称Product requirement Document，即产品需求文档。因此，它的本质还是一份文档，对于开发、测试团队成员来说，还是一份需要仔细研读的文档。对于需要研读的团队成员而言，一份可读性强的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写得很好，不妨再找几个搭档的开发、测试同学问一下，看看结果会是怎样……
相关阅读
一款成功的APP开发产品，产品的定位是极其重要的，产品定位决定了接下来围绕产品的一系列工作：如何确定产品工作的优先级？需要围绕产品
ab是一种用于测试Apache超文本传输协议（HTTP）服务器的工具。apache自带ab工具，可以测试apache、IIs、tomcat、nginx等服务器但是ab没
我曾经和来自不同开发机构的人探讨过关于他们如何管理软件开发，如何组织，他们遵循什么样的开发实践，以及什么样的开发实践真正有效。
siege是一款开源的压力测试工具，可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量
本篇文章作者分享了对有关内容及视觉可用性测试的几个问题的思考。前言最近项目中经常接触内容及视觉可用性测试，一开始有些懵圈，因