标签归档：需求文档

产品经理应该先写需求文档还是先画原型？

1条回复

模型：对产品形态结构的梳理，包括功能模块，逻辑关系，信息架构，业务流程等，可以用脑图，use case图，业务流程图来表示，根据不同产品，产出物的侧重点不同。但模型很必要，是可以帮助产品经理将一个想法，或是脑子中的模型梳理清楚，在做这些工作的同时，可以及时发现自己没有想清楚的细节，这些是指导后面产品设计师(或产品经理)进行原型设计的。同时，描述模型的产出物可以做为传递，帮助别人理解你的产品形态。
软件：MindManager，Visio

原型：即画出产品layout，即不包括界面设计和视觉元素在内的产品细节形态的线框图，包括导航逻辑体现对应的信息架构，交互流程，页面布局，功能任务点，页面(流程)跳转逻辑和较为明确的文案设计等。一个高保真的产品原型，不仅是所有的完整的“线框图”，还同时要有对应的注释内容，很多产品设计师(产品经理)不注意这一点，没有注释内容一样不利于传递，因为原型除了在做用户测试外，还是要给界面设计师和工程师看的。
软件：AxureRP

PRD：即我们说的产品需求文档，这个东西在快速发展迭代，产品导向的互联网公司中的主要作用是存档，备案和忽悠大老板。他主要是由上面两个部分组成，要说再重要的就是加上一些前期调研的内容，比如用户调研结果，竞品分析等。如果你的模型和原型做的足够明确，你会发现，工程师或是界面设计师跟本不会去看PRD。产品评审的时候，你打开一个30页的word文档，第一页是目录，第二页是行业背景……你不觉得这是耽误大家的宝贵时间吗？
当然，不能否认，写出一份规范高质量的PRD也是产品经理的基本素质之一。
软件：Word

产品经理需求文档的那点事

3条回复

　　前几天有朋友问我需求文档应该如何写作？需要注意点什么？其实需求文档在每个公司和每个人的产出的都可能是不一样的，基本上没有固定的格式，如果简明扼要的概括就是需求文档把你这个需求描述清楚你想要什么就可以了。

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

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

需求文档写作的一些建议

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

比如现比较推崇的Agile敏捷开发，会更强短平快，削弱文档的沟通而加强团队的直接交流，简化流程，快速反馈，快速迭代等等。这种情况下，需求文档会极大简化，咱就不在这探讨了。

比较正规的文档目录

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

这种文档现在更多的出现在软件行业和严谨开发行业，对于互联网而言已经慢慢简化了需求文档的冗余程度，只要这个文档能很清晰的把这个产品描述清楚就好。

如：微博上有好友推荐关系，需求文档中可以描述为

向用户A 推荐 用户B 为他有共同爱好的人，那么他们需要有>10个共同关注的人；
向用户A 推荐 用户C 为他可能感兴趣的人，那么他们需要有共通过的粉丝>10人；

　　这两句话描述了微博用户推荐机制产品经理需要给开发产出的需求描述，也经常遇到会有开发问“他们之间怎么关联在一起”“这两个表不在一个数据库“等问题，如果产品经理是开发转型能提供解决方案并且时间很充裕可以协助一下，但大多数产品经理也许不会开发，所以这些问题开发要自己想办法解决，不要凡事遇到问题就找产品经理。产品经理也是人，不是神；