为什么要写MRD和PRD？如何写？
- 格式：pdf
- 大小：143.93 KB
- 文档页数：4
为什么要写MRD和PRD？如何写？
这个问题看似简单，但是细细思量却又不是那么简单。
写过PRD的人能体会到那动辄几十页到上百页的文档写起来是相当滴痛苦和枯燥。
我们为什么不直接就口头交流，避开那该死的文档呢？其实万物存在就有其理由，MRD和PRD也有其存在的理由。
首先，口头交流的信息保真度是有限的，我们需要借助于文字和图形来确保准确表达我们的思想；
再则，人的记忆力是有限的，我们不可能记住无限多的信息，我们需要记录于纸面的图文信息来存储我们的思想；
最后，它是我们成绩的一种较好的体现方式。
如何写好MRD和PRD呢？
MRD全称市场需求文档，侧重于对市场需求的描述与分析，属于（宏观层面的）高层定义。
MRD告诉我们要做什么，用户是谁，有何利益，有何风险，产品轮廓是怎样的。
MRD就如房屋的设计图纸——简洁而不简单，它定义了这个产品的基本形态。
在这里我不想列一个MRD的模板，我觉得每个公司、每个人都有适合本身的模板，我们要了解MRD背后的思想。
掌握了MRD的思想后，你自然就知道如何构造适合自己的MRD模板结构了。
我自己对于MRD背后思想的理解就是：如何精炼地阐述“怎样在有限的资源、可接受的风险下实现商业与用户利益的平衡”。
相信你对MRD有了一定的理解，下面说一说PRD——产品说明文档。
如果说MRD是“设计图”，那么PRD就是支架结构。
PRD严格来说还是抽象层面的说明，但是又有一点点接近功能实现。
PRD详实地描述了这个系统需要实现哪些功能，需要满足哪些质量要求和约束。
MRD如果是描述做什么，那么PRD就是描述怎么做。
我个人觉得采用用例技术描述系统要实现哪些功能是个非常不错且得到业界认可的良好实践方法。
用例如果要详细说明，那也是一门大学问，这里不多赘述，有心人可以阅读相关书籍学习，我这里推荐《编写有效用例》、《沉思需求》这两本书。
我相信你掌握了用例技术后，也就知道如何书写PRD文档了。
请记住，PRD的核心思想是：用系统架构师能读懂的语言描述系统在特定的质量要求和约束下是怎么做事情的。
产品从无到有，每个环节关注什么？有何输入、输出物？
首先，先说一下需求捕获阶段，这个阶段一般是由产品经理来完成。
产品经理在这个阶段关注宏观层面的东西多一些，思考范围较多在于：
我们要做什么类型的产品？
服务于谁？
通过我们的产品，用户能达成什么目标（用户需求、利益）？
我们能得到什么（利益）？
我们要实现什么功能需求，满足什么（质量）要求？
理想情境下，我们可以做到什么程度？
考虑（环境）约束？，我们现阶段能做到什么程度？
路线图（Roadmap）……？
通过以上步骤的思考，产品经理基本上就能够搭建起产品的框架了，而这个框架就是产品详细设计的“设计图纸/路线图”。
BRD：Business Requirements Document，商业需求文档。
这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。
MRD：Market Requirements Document，市场需求文档。
获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。
实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List 等。
PRD：Product Requirements Document，产品需求文档。
进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。
主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。
Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。
FSD：Functional Specifications Document，功能详细说明。
有一点像“概要设计”，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。
相应的，有很多内容，比如表结构设计，要由项目经理来编写了。
