一 定义
广义上来讲，产品需求的描述，应该包含有产品的战略和战术。
战略是指：产品定位、目标市场、目标用户、竞争对手等。
战术是指：产品的结构、核心业务流程、具体用例描述、功能&内容描述等，本文主要讨论的是战术部分。
PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。
二 写作逻辑
写PRD，其实就是一个产品业务需求分析的过程：
① 整理产品结构
② 分析核心业务流程
③ 分析及整理用例
④ 分析及整理非功能性需求
⑤ 整理需求文档并评审
-
整理产品结构
就像修建一座商城，在设计的时候需要考虑整体的结构，商城包括美食区，服装区，休闲娱乐区，百货区等，然后每个区又可以安装商家或类型细分。产品也是这个道理，产品是由功能和内容组成，这些功能和内容，按照某种维度，组成频道/模块，最终形成产品的整体结构。以产品结构中的个人中心这个模块为例，
产品结构一般由 MindManager/Xmind（思维导图）梳理，产品结构 != 页面结构，产品结构是逻辑上的，页面结构是物理上的。具体的结构和方法，参考《用户体验要素》一书。
- 分析核心业务流程
分析梳理核心业务流程，可以帮助产品经理了解产品逻辑。 -
分析及整理用例
这个步骤是更具体、也很重要的一步，前两个步骤确定了范围和流程，这一步正对流程上的某个点来进行具体描述。以会员中心——内容管理这个模块为例，这个模块下面包含的用例有：
①新增文章
②修改文章
③删除文章
④查看文章列表
⑤查看文章详情
现在，就可以按照上面这个列表，来一一描述用例。一个完整的用例应该包含一下内容：
在描述需求时，有2种方式，一种是用例描述，另外一种是功能点描述。用例描述和功能点描述最大的区别在于，描述的角度不一样，用例是从人和系统的旁观者来描述，而功能点是从产品的角度来描述。通过用例描述需求，最好用文档，并且有统一的用例模板，而功能描述只需要在Axure里，以注释的方式描述即可。
其实，关于需求怎么描述，没有完全正确的方式，只有最合适的方式，具体因人而异。《启示录》一书作者就建议描述产品需求只需要 高保真原型 + 注释 就可以，完全不需要文档，以下是书中的一些观点：
产品说明(需求)文档的主体应该是高保真原型，由它体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计。高保证原型最大的优势是可以用于测试。
与其花几个星期撰写冗长的Word文档，既没人读，也无法测试，还不如和设计师一起创建原型。
不管是用例描述还是功能描述，规则都是最重要的一部分，这里主要讲一下如何描述能完整无误的阐述需求并让阅读者看懂。规则的描述，主要是从3方面思考。
①数据规则。主要指页面从数据库调取数据并展现的规则，比如查看文章列表这个用例，需要描述文章列表页面展示哪些字段、每个字段的类型及长度、列表的排序规则刷新频率等。
②状态逻辑。文章不同状态之间切换的触发点是什么，比如状态为已发布的文章，要变为下架，可能的触发条件有：发布时间已过期、手动操作下架等。
③交互规则。界面上存在交互的元素，一一列举并说明，比如链接、按钮、滑动、下拉的具体交互规则及异常处理。另外，整个场景由于网络问题、系统问题导致的异常也需要说明。
-
分析及整理非功能性需求
非功能需求涉及比较广，比如产品的性能需求，访问速度达到多少、最大能支持多少人同时访问;比如设计需求，产品要设计成小清新风格还是成熟稳重的风格等;还比如统计需求，产品要统计哪些字段，形成哪些报表等。这个可以根据具体的需求来描述。 -
整理需求文档并评审
当完成以上4个步骤以后，整个产品的逻辑已经很清楚了，再将产出物汇总，就可以整理出需求文档。文档出来后，需要和项目相关的负责人一起评审，评审确认通过，就可以进入产品的实施阶段。实施一般是由项目经理负责，但是很多公司没有配备该岗位，这就要求产品经理拥有项目管理的能力，来推动产品顺利实施并上线。
三 PRD文档格式
没有最好，只有合适。
每个人所在的公司背景都不一样，大公司要求文档规范，细节到位，小公司可能只需要记录关键信息，剩余的靠口头沟通，甚至都不需要文档。还有些人，直接通过Axure描述产品需求。
PRD文档，最重要的还是以上的整个思考 和 整理 的过程，当以上步骤梳理清楚后，文档只是水到渠成的产出。只要内容清楚，文档格式没那么重要。
四 写在最后
产品经理需要做产品的战术执行和战略计划工作，我认为这两个工作是个递进的关系，当你能把产品的战术执行到位，真正的把一款产品从0到1做出来的时候，再去思考产品的创新、规划……产品才容易落地，否则，永远是纸上谈兵。这也是为什么很多产品助理刚开始到公司都只接一些功能模块的设计实施工作，而不是一来就做战略方面的工作。
参考书籍：
《用户体验要素》
《启示录》
《火球UML大战需求分析》
参考链接： http://www.yixieshi.com/22377.html
网友评论