撰写PRD是产品经理日常工作中一项必不可少的工作。一份高质量的PRD不仅是产品经理专业水准的体现，还能大大降低PM和UI、RD、QA的沟通成本，从而提升工作效率。
随着产品迭代速度的不断加快，越来越多的公司内部开始采用扁平化的组织方式，传统的PRD已经很难胜任这种开发节奏，特别是对一些敏捷开发团队来说。</big>
随着项目经验的增加，我已经放弃了工作初期采用的传统PRD形式（那种上百页的word文档，很少有人会仔细去看）。现在，我会根据不同的场景和"需求人群"，采用不同的工具制作演示文稿或者需求文档。下面是日常工作中用到的部分工具。
| <small> 工具</small> | <small> 用途 </small> | <small> 使用场景</small> |
|---|---|---|
| <small> Axure </small> | <small>制作原型和撰写PRD </small> | <small> 产品立项会、功能设计会、交付UI和RD </small> |
| <small> Sketch</small> | <small>制作高保真原型</small> | <small>给RD展示设计效果</small> |
| <small>Principle</small> | <small>演示交互设计</small> | <small>和UI讨论交互设计、给RD展示交互效果</small> |
| <small>Worktile</small> | <small>需求、文档和项目管理</small> | <small>日常项目管理、资料备份 |
| <small>BitTorrent Sync</small> | <small>项目资源共享 (PRD、切图、设计规范等) </small> | <small> UI设计和产品开发</small> |
其中，给RD和UI看的PRD基本上都是用Axure做好原型，然后在上面直接标注功能说明。
当我写PRD时，我写些什么
用Axure原型替代的PRD至少应该包含以些内容：版本说明、文档变更日志、流程图和 原型说明。
版本更新说明
版本更新表中，主要描述该PRD涉及到的功能或改动。因为，在产品迭代过程中，一次更新可能会涉及到多个PM负责的业务或者模块，有时候多份PRD未必会汇总提交给开发。因此，在文档开始处声明该PRD中涉及的需求，能够让RD对文档有个大致的了解。
文档变更说明
尽管产品经理会反复模拟产品的使用流程，但实际项目中PRD还是很难做到一步到位。除了一些临时新增需求，一些异常或边界条件如果PM之前没有经验，很难在一开始就考虑到。这时候，如果你的RD是一个负责任的老司机，他可能会提醒你并给予一些建议（不过，一些情况下老司机会自动帮你脑补你未完成的部分）。
所以，如果不得已要更新已提交的PRD，更新日志就显得尤为重要了。文档更新后，要及时通过邮件或内部IM告知相关项目人员。大家通过查看更新日志就能大致了解变更内容，可以直接定位查看。
<small>注：如果是文档的话，还可以用Beyond Compare来查看两份文档修改前后的差异。但程序员们一句git diff 就搞定了，有木有···</small>
流程图
如果涉及新的业务流程或者页面逻辑，建议提供一份清晰的流程图或树状图。一方面，可以更直观地梳理逻辑和查找漏洞；另一方面，这种逻辑性很强的东西更符合程序员的思维方式，效果远远好于仅提供一个可交互的原型，让可怜的程序员自己去琢磨你的逻辑。
<small>注：如果只是简单的页面改动，可以没有这一部分内容。</small>
原型说明
初期，用Axure制作的原型在通过了需求评审和设计评审后（这时候，UI可以开始正式做设计和切图了），就可以进一步完善成为PRD。
用Axure制作PRD的好处主要有以下几点：
** 原型和说明文档可以同步更新**。在项目进行中，我们提交的原型因为种种原因，会存在变动的可能。当我们在Axure中修改了原型后，可以很方便的对说明进行同步更新。
-
文件左侧的站点地图有天然的逻辑分组。Auxre的树状组织结构使得页面间的逻辑关系非常的清晰。新的 Axure 8 新增了很多流程图和控件，功能更加的强大。
site map of Axure 8 方便程序员的工作。大多数的程序员至少会有两块显示屏，一个用来开 IDE 撸代码，另一个就用来查资料和看文档。如果PRD和原型分开来做，那么无形中增加了他们的切换成本，降低了开发效率，程序员肯定不买账。最后的结果很可能就是，不仅辛辛苦苦写的PRD没人看，就连原型图也成了摆设，有问题全跑来问产品。
为了最大程度降低RD大大们的阅读疲劳感，使他们不遗漏PRD中的一些重要细节和说明。在Axure的一个Page中，我尽量只描述一个页面。甚至该页面上的一些事件或弹框，如果有必要的话，我也会单独新建一个同级的Page来进行说明。
事实证明，这种 "一个Page只说一件事儿" 的方法更能激发RD的阅读欲望，使他们更加专注于该页面的细节和逻辑。因为，少了很多无关页面的干扰，UE说明的字数也会减少。研究证明，适当的文字篇幅更有利于人们阅读。（<small>虽然如此，但是页面的前置条件、说明文案、边界情况、异常流程，甚至是算法，还是必不可少的。</small>）
另一方面，因为每个页面说明都在一个独立的Page中，所以页面间的跳转关系，可以通过超链接来完成（整体的页面逻辑已经在前面的流程图中体现了）。只需要在说明处标明，其他人点击查看即可，如示例中左上角返回按钮处的说明。
<small>注：不建议用点击事件来代替显性的超链接说明。除非是高保真可交互原型，否则其他人不知道哪些地方可以点击或者交互。</small>
结语
我所说的都是错的。
上述，就是我在平时工作中根据公司和团队的实际情况不断调整和摸索出来的一套方法。相对来说，对于规模较小的开发团队，这种原型PRD非常推荐。大家在平时工作中，一定要根据公司和团队的实际情况灵活调整。写文档本身就是在做产品，如何让大家接受并且易读、易懂，则需要我们在日常工作中多思考、多总结。
