关于产品需求文档

 
开发参考

产品需求文档的撰写是PM的最需要熟练掌握的技能之一，但在流程完善的大公司和行事灵活的创业公司，PRD就出现了较大的不同，下面转载自知乎上一位知友的回答，相当完善，看过之后才觉得自己之前对于PRD的认识太肤浅，这对于需要关注细节的PM来说简直是职业习惯上的灾难啊，要注意！！

转载地址：http://www.zhihu.com/question/19586231

需求文档注定是给所有人看的，它就是产品的定义。

  • 文档围观的人包括：你的老板（如果产品够大，还会需要老板的老板），设计师，工程师，测试工程师。有时还应该包括产品前端：如运营，销售，甚至市场部同事。
  • 在通过各方的评审和签字后，一般来说，这个文档就是一锤定音的事。若有更改，就是需求变更了。
  • 所以，在需求文档撰写前和撰写中，对产品方向和用户的把握要足够强，从产品目的，到每个链接的含义，都需要准确地定义。基本上，当你开始写文档时，应该万事俱备。一边想一边写，那说明你还没有想明白这个产品是怎么回事。
  • 在有些公司，需求文档会包括产品的最终设计界面。即在文档提交给大家围观前，产品界面已经确定完毕。


需求文档写作的一些建议
  • 格式无所谓。用WORD的多，HTML，在线文档都成，我还见过PPT写的！
  • 产品定义部分一定要详细描述。按功能模块写，跨功能的定义用流程和关系来描述。多站在用户的角度上，去定义用户任务，用户流程，页面逻辑关系等。
  • 使用准确的用语，注意边界情况。比如，一个文本框最多输入多少个字符？是阿拉伯数字还是皆可？超过字数会怎么样？
  • 多画图。把原型包括进去，或者把产品界面包括进去，不然就画出来。否则除了你，没多少看得懂。

一个需求文档，一些通用部分是必须要包括进去的，我总结了一个示例。
当然， 很多时候有可能是创业公司，或是小版本快速上线，要求会宽泛得多得多。
比如现比较推崇的Agile敏捷开发，会更强短平快，削弱文档的沟通而加强团队的直接交流，简化流程，快速反馈，快速迭代等等。这种情况下，需求文档会极大简化，咱就不在这探讨了。

  1. 文档信息，版本记录，责任人等
  2. 项目背景，产品目的
  3. 文档约定（采用的标准，通用名词等）
  4. 可行性分析
    • 前期调研
    • 产品预期
    • 对其他产品的影响
  5. 产品定义功能详述（文档主体部分）
    • 功能模块
    • 用例
    • 用户流程
    • 数据需求
    • 业务规则流程
  6.  产品非功能需求
    • 对性能的需求
    • 安全性需求等
  7. 产品风险或潜在问题

以上是相当完整的PRD写作规范，但是从PRD的“用户来看”，可分为以下两类

1、给市场、运营、销售的部门看——业务内容+原型图

2、给研发、设计的部门看——原型图+原型图功能描述

一方面，考虑到PRD的使命是用最简洁的方式传达产品的细节，因此文字、图、流程、原型的表达力度是依次递增的，尽量选择最有效的形式。

另一方面，涉及到具体的方法论，这里有一个七字口诀“增删查改显算传”，以下是具体的说明，来自UCDchina的好文：

转载链接：http://ucdchina.com/snap/9715

增删查改显算传，产品设计的七字真言，也是产品经理的基本功。

增：数据会增加到怎样的一个量，当这些量增加到一定程度时页面需要怎样的表现形式。拿新浪微博的实时刷新来说，当微博条数持续增加，我们是按微博数量来固定分页，还是按照页面的长度来分页，还是根本就不用分页，持续的刷新下去，抑或是刷新和分页并存。

删：这个也是常规性操作，既然数据有增加，就会有删除的需求，哪些数据可以删，哪些不能删，删完之后数据会呈现怎么样形态等。

查：这是快速获得信息的一种方式，从繁杂的数据排列中准确定位出用户想知道的结果，通常会有好几种查询方式及查询条件，不管是哪种都要表现出来。

改：可分为两种来表现，一是用户对原有数据的修改，哪些可以哪些不可以，可以修改哪些元素，哪些元素一旦确定将不提供修改等；二是对设计的修改程序实现的方式，从一种方式更改为另一种方式程序是否易于实现。

一般来说产品经理做到以上四点就能把原型做的非常完善，假如数据做成了列表样式，是否考虑到了分页？是否需要排序？排序的话按什么条件进行？排序满足不了需要的话是否需要搜索框？查询框？查看详细列表的打开方式是怎样的？本页操作还是新窗口操作？跳转之后需不需要跳回来？选择数据支持单选还是多选？单选的话用下拉还是radio？如此等等细节交待的越清楚，和开发的沟通越少。

显：数据的显示，根据需要做哪些显示，显示的方式是怎么样的，不同用户的权限是否一样，不一样的话数据如何表现。这里的表现的是背后逻辑。

算：指计算规则，比如热门文章=点击数*1+评论数*2+分享数*3诸如此类的背后计算的数值。此类规则约定之后可以节约很多时间。

传：数据的传递，不同服务器之间的数据传递，考虑到用户体验的时候ajax的传递，还有一些api的数值传递等等。

有话要说