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