这两天遇到一个问题，产品经理除了画原型外，是否还要单独写一份PRD文档？今天的话题就来聊聊这个问题我的看法。
我觉得，产品经理是否要产出PRD，还是依据公司实际情况而定，需要同时权衡公司工作习惯、开发人员使用方法、文档管理的便捷性等几个方面，择优而取。
为什么这么说呢？以我本人经验为例，从开始做产品经理那天，我就没有PRD这个概念，最早的时候写的是《软件概要设计文档》、《软件详细设计文档》，接触互联网后，就直接上手Axure原型，开始做的时候喜欢炫技，尝试高保真，就是所有点击交互都做出来，但开发经常抱怨看不懂，不知道点哪儿怎么点，于是就把原型拆开，用流程图组成交互稿，再后来觉得流程图无法说明问题，就在交互稿上标注各种逻辑说明，字段描述，最后又觉得光放交互稿无法说明为什么要这么做，就把每次迭代的项目说明、开发目标、需求List、上线价值等也用Axure写上，直到现在也还在不断补充这个大Axure原型，最终结果类似下图：
从结果来看，大家还是很认可这样的需求描述形式的，原因有如下2点：
1、需求管理方便
每次维护一个版本迭代，直接保存当时的原型文件即可，需要修改、更新，也直接修改一个文件即可，非常方便。
2、需求沟通方便
无论是和需求方沟通，还是和开发、设计沟通，直接对照着一个个页面讲解即可，通常一个页面，交互、需求、逻辑、字段都有标注，能够做到高效评审。
依我的经验，还是比较推崇把PRD和原型文档合在一起交付。
当然，这样做也有如下缺点：
1、需求比较“散”，很难验收
原型毕竟是以“页面”为信息承载媒介，而需求是以“列表”形式存在，二者通常会交叉存在，也就是说，很可能一个页面上的交互稿会实现多个需求，而1个需求也可能由多个页面实现。从而对开发、测试人员造成一定识别困难。通常这种情况我会单独在Axure开一个页面，把需求List和原型页面之间的关系画一个映射表格给开发、测试来对照。如下图所示：（“主题”一列为页面跳转链接，“redmine”一列为需求列表跳转链接）
2、算法、业务逻辑和字段标识，很难用原型标明
比如排序逻辑、热门算法、数据传输协议、埋点规则，这样的内容通常是没有用户界面的，也就无法和交互界面融合。通常这种情况我也会针对这样的需求，单独开一个页面，用文字、流程图的方式描述清楚。
因此，很多公司也会通过单独撰写一份PRD文档，来解决我说的上述问题。
总之，是否需要PRD文档，关键在于你写的需求是否真正能被开发、测试、设计、需求方识别、认可，毕竟需求文档的使用者是他们。所以我觉得不用拘泥于形式，只要你的思路清晰、主次明确、逻辑顺畅，选择一个大家都认可的方式产出需求即可。
以上就是今天的思考，你们公司是怎么写需求的？期待你的留言~
