1、商业需求文档（ MRD/PRD/BRD）模板 Framework作者：百度PM/惜知猫以上的脑图可以说明一切，我就简单解释下好了。1. 背景和意义，说明你做这件事情的目的和潜在的收益。对于不一定能做成的产品来说，这一块儿可以算是“吸引投资”的最重要的因素。你是否能说服别人开发你的产品，并且证明你的产品对公司是由意义的，决定了这个产品是否能上线。所以，各种最好是能使用各种量化数据。没有这个产品之前，用户的痛点是什么？公司的痛点是什么?客户的痛点是什么？有多痛？产品如何解决这些痛点？上线后能减少多少痛苦？如何评估这些痛苦的减轻？2. 功能概述，简述你解决问题的方法。你的产品有哪些功能？这些功能的优
2、先级排序是怎样的？（如果超过预定排期，可以砍掉或者合并一些优先级低的功能）使用你产品的有哪些人？这些人的权限有什么不同？产品在使用过程中分为哪几种状态？这些状态时如何触发的？你的产品结构是怎样的？如何导航以防止用户不迷路？如何测试你的这些功能？（帮QA 节省人力了，呵呵）3. 功能细分，逐一细数产品的功能。在每个功能里，页面都是怎样的？有什么文案提示？操作有什么边界限制？各种正常与异常的触发方式是什么？这个功能对某些特定需求的用户，正确和错误的案例分别是什么？用户错误了，如何引导他们回归正途？4. 其他需求你的产品对安全性有什么额外要求？对浏览器有什么要求？当原型和文档发生冲突时，当和原系统发
3、生冲突时，以哪个为准？你产品对空间和机器性能有什么要求？5. 附录对于一些比较多的内容，比如每个表单的选项，各种状态的文案、日志需要记录哪些信息，数据库需要记录哪些信息等等。可以通过附录的方式展现。如果你是PM-RD ，你还可以简单设计一下数据库，做一个总体设计：）-【关于本文的一些讨论】PM ：商业需求文档 功能需求文档再有产品需求文档。主要侧重点都哪儿？猫答：一家之言哈，商业主要考虑成本/收益，适用于商业产品；产品主要侧重于产品的定位和目的，所有需求都围绕产品；功能是产品组成产品的力度，是产品需求文档在某一个阶段升级的细分；in all，无论是什么文档，都是形式。只要能完成对研发、测试、乃至老板、运营团队的沟通、设计备案的功能就行不一定要拘泥于形式PM： 找了好多 brd模板，觉得这个不错，但是又觉得他写的太多了。因为简单有些童鞋写的最好BRD最好是不超过5页的PPT,随之我就迷茫了！猫答：我是觉得需求文档应该详细些，保证完备性和可传承性，但它不具备沟通需的简洁性，所以需要PPT和原型来配合沟通
