产品运营文档
1. 产品经理需要输出哪些文档
吹降淖盅凼牵翰
2. 产品需求文档模板
首先告诉你产品需求文档肯定是有的！一个经过实际工作检验、经历过“质疑”、“挑战”和“斗争”之后沉淀下来的模板，肯定是已经吸收了各类人的偏好、意见，固化了很多符合实际业务必须的内容要求，能够起到很好的业务承接作用。格式化、标准化本身是一个很好的思维、工作方式，可以让你在编辑文档和接受文档的双方关系中建立一种“标准”的沟通机制和预先定义的沟通基础，减少额外的沟通成本，提高效率。
不过，在享受别人智力和经验梳理好的模板进行需求编写的同时，还是应该了解模板形成的原因，并在此过程中形成自己对于模板的理解，进而形成对于产品需求文档的理解，在理解中使用，裁剪和优化。
要理解和分析模板，理解和分析产品需求文档，可以运用以下几个方法：
一、描述-解释-预测-监控
描述，是对观察过程和观察结果的描述。观察的对象因不同的研究而有差异，其目标是尽可能完整地将观察者根据自己的观察得到的现象、由此现象所产生的思想和感觉，以及在观察过程中选择纳入的过程参与者对现象的反应等信息进行描述。
解释，是回答 “为什么”，是对于描述的理解、归类、定义和解释。其目标是将描述内容背后的成因、原理、动机，内容中各部分之间的相关，依存、依赖和影响关系等进行说明，以便对于描述内容有更清晰、更细致、全面的了解。
预测，根据以因果关系为内容的内在联系，相互影响来推导未来的发展或者将要发生的事情。通过研究解释内在的联系，准确地表达内在联系，从中推导出正确的预测。
监控，是对于预测行为、现象的观察和监督，包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生，以及因此而采取的对应的反映动作；这些反映动作是预测过程中根据内在联系制定的“响应”机制，并任其自然发生或者通过提供“系统”的自制能力来实现。
二、需求准备、编写和检查
回归到产品经理的日常工作中，在时间占比上较为集中的就是产品需求管理了，包括了需求的准备、分析、编写和检查过程。在这个过程中，描述——解释——预测——监控这个通用的科学分析过程也同样使用，且可以贯穿其中，并可以帮助理解、形成并固化成我们前文提到的需求文档的模板。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同。
1. 描述
描述的过程是客观的进行“需求向”描述的过程，是一个“背景”信息的补充，用来说明，这个需求文档的源出是什么，是针对什么问题，这个问题是在具体什么领域，在怎样的范围内，涉及到的是那些人；在需求相应的功能设计实现之前，当前的解决方案存在的问题是什么，参与者是怎么解决的，解决的情况怎么样，是好，还是不好，还是勉强可以，对于新的需求的紧迫性是什么样的。此外，描述的过程还需提供一个基础的概念和流程的解释，用来统一作为背景去理解一个现实的业务场景和“沟通字典”，避免在沟通中因为误解而产生不必要的偏差。
需求准备的过程：了解需求来源（管理部门、市场部门、运营部门等），需求背景（行业、同业规则现状等）；
需求分析的过程：了解需求目标、预期效果（时间、结果等）、使用者习惯、相关人影响；
需求编写的过程：描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围；
需求检查的过程：需求的背景、目标、过程、干系人、结果预测和预防的完整性检查；
2. 解释
解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题，同时还加入了“是什么”和“怎么样”的部分。就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题，这个新的解决方法需要要做什么，对于原有的业务过程有哪些改变，会提升什么，会降低什么，会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生。这个部分，是需求文档的最主要、最核心的内容部分，也是在内容上占比最大的一部分。
这里的解释根据产品需求面向的要解决的问题不同，而可能存在多个层面，多个维度的层面，比如对于运营的影响，对于前端市场的影响，对于用户的影响，对于财务、法务的影响；从技术开发、技术实现维度，比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响，还可能涉及到对于运维资源的影响等；因此对应到实际的产品需求工作中：
需求准备的过程：了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑；了解面向的内外部用户的产品使用水平、学习能力和使用习惯；
需求分析的过程：选择和制定最有效的，满足时间、资源投入等要求的方案；
需求编写的过程：详细描述需求的业务流程，通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品，产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出；每个业务节点明确的输出物和节点标志，重要性和优先级；系统架构、干系人角色和影响范围；
需求检查的过程：需求的流程、用户交互动作、系统信息交互等完整性检查；
3. 预测与监控
预测与监控在产品需求文档的管理上是联动的，是对于预测的事件发生的时候，进行管理的机制，监控=预测+干预。在产品需求文档的管理上，对于设计好的业务流程、使用功能，在实际过程中可能会出现这样或者那样的 “非规划”的使用，也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品，而且，往往相反。”因此，这部分内容很大的比例需要来对于用户的行为进行预测和监控，并提供“预防”或者“解决”方案。其中：
预防在于，预测产品的用户在使用的过程中，可能会进行的一些超过产品使用半径的操作，一旦进行这些操作，操作的任务流程会中断，掉出，进入其他业务流程中且无法回滚，从而使得操作无法进行下去，功能使用失败，使用者会感觉产品、功能没有包容性，缺乏引导性，导致了最后操作的失败，预想的结果没有实现，而且造成了一定的挫败感，甚至造成了一定的损失。预防的具体方法多采用导航、提示等，不同的系统都有各自标准化的控价，我们在这里不做展开。
解决在于，预测产品的用户在使用产品的过程中，因误解、操作手误而进行了“非标”、“超规”使用“掉出”原本设计的业务流程和操作流程的情况下，需要提供额外的流程和控制来“回转”用户的操作，来帮助用户回到预先设定和他所需要的流程上来。解决的具体方法多通过“导航”引导“跳转”和“返回”、“回退”来实现。对应到实际的产品需求工作中：
需求准备的过程：了解用户特征和使用水平、评估、比较不同方式实现需求对于用户行为的可控性和“非常规”操作的危害程度；
需求分析的过程：选择和确定需求实现方案，评估行为管理方式和管理机制；
需求编写的过程：详细描述需求的业务流程和交互过程中可能出现的用户异常操作，相应异常操作中系统反应，系统对应的控制和引导；
需求检查的过程：需求“异常”流程和相应引导、控制地完整性检查；
在需求管理的过程中，就可以按照这个 描述——解释——预测——监控流程来进行。这四个既是步骤，是需求文档内容的组成部分，也是需求编写完成之后的检查。
四个模块构成了需求文档的完整性，且同时有各自独立，有对应的说明，引导、要求和标准。所谓标准文档，就可以按照这四个模块作为框架、内容和格式。
写在最后
产品需求文档作为产品经理同视觉设计、交互设计以及技术开发人员进行需求沟通的一个载体，我平时用的比较多的是摹客的服务进行创作。一个完整的、充分沟通确认，并最终达成多方理解和共识的产品需求文档，能够最大限度的还原产品、功能的设计，保证产品、功能的实现，最大限度的减少因为各方理解的偏差而造成的时间、人力和经济资源的浪费及复工。
3. 产品需求文档模板新版
您想问产品经理需求文档的模板是吧？我告诉你是有的，一个经过实际工作检验、经历过“质疑”、“挑战”和“斗争”之后沉淀下来的模板，肯定是已经吸收了各类人的偏好、意见，固化了很多符合实际业务必须的内容要求，能够起到很好的业务承接作用。格式化、标准化本身是一个很好的思维、工作方式，可以让你在编辑文档和接受文档的双方关系中建立一种“标准”的沟通机制和预先定义的沟通基础，减少额外的沟通成本，提高效率。
不过，在享受别人智力和经验梳理好的模板进行需求编写的同时，还是应该了解模板形成的原因，并在此过程中形成自己对于模板的理解，进而形成对于产品需求文档的理解，在理解中使用，裁剪和优化。
要理解和分析模板，理解和分析产品需求文档，可以运用以下几个方法：
一、描述-解释-预测-监控
描述，是对观察过程和观察结果的描述。观察的对象因不同的研究而有差异，其目标是尽可能完整地将观察者根据自己的观察得到的现象、由此现象所产生的思想和感觉，以及在观察过程中选择纳入的过程参与者对现象的反应等信息进行描述。
解释，是回答 “为什么”，是对于描述的理解、归类、定义和解释。其目标是将描述内容背后的成因、原理、动机，内容中各部分之间的相关，依存、依赖和影响关系等进行说明，以便对于描述内容有更清晰、更细致、全面的了解。
预测，根据以因果关系为内容的内在联系，相互影响来推导未来的发展或者将要发生的事情。通过研究解释内在的联系，准确地表达内在联系，从中推导出正确的预测。
监控，是对于预测行为、现象的观察和监督，包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生，以及因此而采取的对应的反映动作；这些反映动作是预测过程中根据内在联系制定的“响应”机制，并任其自然发生或者通过提供“系统”的自制能力来实现。
二、需求准备、编写和检查
回归到产品经理的日常工作中，在时间占比上较为集中的就是产品需求管理了，包括了需求的准备、分析、编写和检查过程。在这个过程中，描述——解释——预测——监控这个通用的科学分析过程也同样使用，且可以贯穿其中，并可以帮助理解、形成并固化成我们前文提到的需求文档的模板。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同。
1. 描述
描述的过程是客观的进行“需求向”描述的过程，是一个“背景”信息的补充，用来说明，这个需求文档的源出是什么，是针对什么问题，这个问题是在具体什么领域，在怎样的范围内，涉及到的是那些人；在需求相应的功能设计实现之前，当前的解决方案存在的问题是什么，参与者是怎么解决的，解决的情况怎么样，是好，还是不好，还是勉强可以，对于新的需求的紧迫性是什么样的。此外，描述的过程还需提供一个基础的概念和流程的解释，用来统一作为背景去理解一个现实的业务场景和“沟通字典”，避免在沟通中因为误解而产生不必要的偏差。
需求准备的过程：了解需求来源（管理部门、市场部门、运营部门等），需求背景（行业、同业规则现状等）；
需求分析的过程：了解需求目标、预期效果（时间、结果等）、使用者习惯、相关人影响；
需求编写的过程：描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围；
需求检查的过程：需求的背景、目标、过程、干系人、结果预测和预防的完整性检查；
2. 解释
解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题，同时还加入了“是什么”和“怎么样”的部分。就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题，这个新的解决方法需要要做什么，对于原有的业务过程有哪些改变，会提升什么，会降低什么，会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生。这个部分，是需求文档的最主要、最核心的内容部分，也是在内容上占比最大的一部分。
这里的解释根据产品需求面向的要解决的问题不同，而可能存在多个层面，多个维度的层面，比如对于运营的影响，对于前端市场的影响，对于用户的影响，对于财务、法务的影响；从技术开发、技术实现维度，比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响，还可能涉及到对于运维资源的影响等；因此对应到实际的产品需求工作中：
需求准备的过程：了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑；了解面向的内外部用户的产品使用水平、学习能力和使用习惯；
需求分析的过程：选择和制定最有效的，满足时间、资源投入等要求的方案；
需求编写的过程：详细描述需求的业务流程，通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品，产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出；每个业务节点明确的输出物和节点标志，重要性和优先级；系统架构、干系人角色和影响范围；
需求检查的过程：需求的流程、用户交互动作、系统信息交互等完整性检查；
3. 预测与监控
预测与监控在产品需求文档的管理上是联动的，是对于预测的事件发生的时候，进行管理的机制，监控=预测+干预。在产品需求文档的管理上，对于设计好的业务流程、使用功能，在实际过程中可能会出现这样或者那样的 “非规划”的使用，也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品，而且，往往相反。”因此，这部分内容很大的比例需要来对于用户的行为进行预测和监控，并提供“预防”或者“解决”方案。其中：
预防在于，预测产品的用户在使用的过程中，可能会进行的一些超过产品使用半径的操作，一旦进行这些操作，操作的任务流程会中断，掉出，进入其他业务流程中且无法回滚，从而使得操作无法进行下去，功能使用失败，使用者会感觉产品、功能没有包容性，缺乏引导性，导致了最后操作的失败，预想的结果没有实现，而且造成了一定的挫败感，甚至造成了一定的损失。预防的具体方法多采用导航、提示等，不同的系统都有各自标准化的控价，我们在这里不做展开。
解决在于，预测产品的用户在使用产品的过程中，因误解、操作手误而进行了“非标”、“超规”使用“掉出”原本设计的业务流程和操作流程的情况下，需要提供额外的流程和控制来“回转”用户的操作，来帮助用户回到预先设定和他所需要的流程上来。解决的具体方法多通过“导航”引导“跳转”和“返回”、“回退”来实现。对应到实际的产品需求工作中：
需求准备的过程：了解用户特征和使用水平、评估、比较不同方式实现需求对于用户行为的可控性和“非常规”操作的危害程度；
需求分析的过程：选择和确定需求实现方案，评估行为管理方式和管理机制；
需求编写的过程：详细描述需求的业务流程和交互过程中可能出现的用户异常操作，相应异常操作中系统反应，系统对应的控制和引导；
需求检查的过程：需求“异常”流程和相应引导、控制地完整性检查；
在需求管理的过程中，就可以按照这个 描述——解释——预测——监控流程来进行。这四个既是步骤，是需求文档内容的组成部分，也是需求编写完成之后的检查。
四个模块构成了需求文档的完整性，且同时有各自独立，有对应的说明，引导、要求和标准。所谓标准文档，就可以按照这四个模块作为框架、内容和格式。
写在最后
产品需求文档作为产品经理同视觉设计、交互设计以及技术开发人员进行需求沟通的一个载体，我平时用的比较多的是摹客的服务进行创作。一个完整的、充分沟通确认，并最终达成多方理解和共识的产品需求文档，能够最大限度的还原产品、功能的设计，保证产品、功能的实现，最大限度的减少因为各方理解的偏差而造成的时间、人力和经济资源的浪费及复工。
4. 产品运营的工作内容是什么
产品运营是一项从内容建设，用户维护，活动策划三个层面来管理产品内容和用户的职业。
一、互联网产品运营的工作：
其实互联网运营和其他行业的运营没有本质的区别，只是由于资源和行业用户不同，执行手段不一样而已。总的一句话，运营策划所做的主要工作就是及时掌握市场行情，整合周边资源，通过一系列的运作手段，为自有产品做推广并实现盈利。
简单的讲可以理解为市场部工作者，但是与传统市场部不同的是，现实中大部分所谓运营策划又承担了很多业绩支柱角色（有点像电影业里的发行商），就是传统的销售部门，其主要原因还是由于互联网行业大部分公司盈利模式不清晰造成的，公司不仅仅需要一个会花钱的推广超人，还需要他保证能为公司带来实际的利润，由于盈利模式不清晰，决策者不能确定某种方案漂漂亮亮的推广后是否能奏效（当然如果像传统行业的买卖关系的话就另当别论了）。这对运营策划就大大提高了一个档次要求，也就是说好的运营策划不仅要渠道广泛、朋友多，而且还得有独到的眼光和市场嗅觉，能够准确预测推广后带来的实际效果，后者是评价此人是优秀运营策划还是普通运营策划的本质标准。
二、站点规划：
网站上线前，站点规划包括前期调研、可行性分析、策划文档撰写、业务流程及逻辑明确、站点展现规范、参与UE测试等工作;网站上线后，站点规划则主要是指新增需求的分析、补充开发的需求明确及相关文档落实;
5. 互联网产品功能介绍文档又叫什么
需求文档注定是给所有人看的，它就是产品的定义。
文档围观的人包括：你的老板（如果产品够大，还会需要老板的老板），设计师，工程师，测试工程师。有时还应该包括产品前端：如运营，销售，甚至市场部同事。
在通过各方的评审和签字后，一般来说，这个文档就是一锤定音的事。若有更改，就是需求变更了。
所以，在需求文档撰写前和撰写中，对产品方向和用户的把握要足够强，从产品目的，到每个链接的含义，都需要准确地定义。基本上，当你开始写文档时，应该万事俱备。一边想一边写，那说明你还没有想明白这个产品是怎么回事。
在有些公司，需求文档会包括产品的最终设计界面。即在文档提交给大家围观前，产品界面已经确定完毕。
----------------------------------------------------------------------------------------------
需求文档写作的一些建议
格式无所谓。用WORD的多，html，在线文档都成，我还见过PPT写的！
产品定义部分一定要详细描述。按功能模块写，跨功能的定义用流程和关系来描述。多站在用户的角度上，去定义用户任务，用户流程，页面逻辑关系等。
使用准确的用语，注意边界情况。比如，一个文本框最多输入多少个字符？是阿拉伯数字还是皆可？超过字数会怎么样？
多画图。把原型包括进去，或者把产品界面包括进去，不然就画出来。否则除了你，没多少看得懂。
一个需求文档，一些通用部分是必须要包括进去的，我总结了一个示例。
当然， 很多时候有可能是创业公司，或是小版本快速上线，要求会宽泛得多得多。
比如现比较推崇的Agile敏捷开发，会更强短平快，削弱文档的沟通而加强团队的直接交流，简化流程，快速反馈，快速迭代等等。这种情况下，需求文档会极大简化，咱就不在这探讨了。
6. 市场需求文档和产品需求文档区别是什么
该文档是软件产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是某个软件产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。一般在互联网企业中MRD都是由运营人员和产品设计人员共同制定完成的，互联网软件产品由于最终直接面向终端用户，且需要长期运营，作为互联网企业中的运营人员是最清晰市场动向？产品受众是哪些人？为什么需要产品人员配合呢，主要是因为运营人员很普遍的观念是以运营商品的视角来考虑问题并未能深埋产品级的需求，所以两者配合来制定编写市场需求文档是最合适不过的。产品需求文档(Proct Requirement Document，PRD)，该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。该文档一般是由产品设计人员来完成，也就是传统意义上的需求分析，其主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程、子流程、分支流程，等几大块），功能点业务流程框线图，界面说明，Demo等。
7. 产品需求文档应该包含哪些内容
规范化软件开发过程中的《需求说明书》的编写，使之成为整个开发工作的基础。
2 适用范围
本规范适用于集团开发项目的（软件）《需求说明书》的编写。
3 编写内容提示
1 引言
3.1.1 背景说明
说明被开发软件的名称，任务提出者，用户及实现该软件的计算机网络。
3.1.2 参考资料
列出有关资料(名称，发表日期，出版单位，作者等)。
3.1.3 术语和缩写词
列出本文件中用到的专门术语的定义，及术语缩写词。
3.2 软件总体概述
3.2.1 目标
软件开发的意图、应用目标、作用范围以及需说明背景材料。
3.2.2 系统模型
图示说明该软件的所有功能及其相互关系和数据传递情况。
3.2.3 假设和约束
说明影响软件开发、运行环境和系统能力（如预告出错类型的能力）的某些假设和约束。3.3 详细需求
详细描述此软件系统的功能需求和性能需求。
3.3.1 功能需求
对系统中每一个功能，要详细描述（图示或文字）。
概述 叙述功能名称，目标和作用。
输入 输入该功能的信息。
处理 描述该功能做什么，如何对输入信息进行加工并转换成输出信息。
输出 列出内部生成的文件。
3.3.2 性能需求
定量地描述此软件系统应满足的具体性能需求。可考虑以下方面：
3.3.2.1精度
说明系统的精度要求，如：
数据的精度要求。
数字计算的精度要求。
数据传送的误码率要求。
3.3.2.2 时间特性
说明系统的时间特性要求，如：
解题时间。
询问和更新数据文件的响应时间。
系统各项功能的顺序关系。
3.3.2.3 灵活性
说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。
3.3.2.4系统容量
包括系统的设计容量和理论（计算）容量。
3.3.3 输入和输出
解释各输入输出数据类型，并逐项说明某媒体、格式、数值范围等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.3.4 数据管理能力
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作估算。
3.3.5 故障处理
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.4 环境
描述所开发软件运行所需的环境。
3.4.1 设备环境
描述运行软件系统所需的设备能力，如：
处理器的型号和内存容量。
存储媒体的数量。
通信网络（包括说明网络结构，线路速度及通讯协议等）。
3.4.2 支持软件环境
列出与待开发的软件互相配合的支持软件（包括名称，版本号和文件资料），必要时还应列出测试软件，还要指出该软件用的编程语言，编译程序，操作系统和数据管理系统。
3.4.3 接口
说明本软件与其他软件之间的接口、数据通信协议等。
3.4.4其他
说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。
8. 产品经理需要输出哪些文档
1. 立项阶段 产品经理需要进行市场分析、用户研究、竞品分析等，输出的文档有: 市场与竞品分析报告:市场容量背景，竞品数据、操作流程、用户体验、优势、用户构成等; 用户研究报告:这个部分内容很多，根据实际进行选择具体方法输出不同形式的总结，譬如问卷调研、用户访谈、用户观察、头脑风暴等等;需要考虑的问题是这个产品是满足哪一类用户的哪一项需求?解决用户的什么问题?是提升效率，还是更加有趣好玩? 产品立项评审申请:在以上的市场与竞品分析、用户分析基础上，提出立项申请，包含项目背景、项目目标、产品形态、项目投入与产出等。 2. 产品需求阶段 立项成功后，就开始进入产品需求阶段，这时就要更加深入的分析用户需求，准备如下文档: 产品策划需求，包含:产品目标、需求概述、产品逻辑、主要功能特性、数值策划;产品交互设计稿; 数据需求文档:产品关键指标、指标体系、计算逻辑、数据上报、报表样式等;目的是产品上线后对产品的评估，用户行为数据的分析，对产品优化提供决策参考; 互联网的一些事 产品运营方案:产品上线发布策略、产品运营后台设计，产品营销推广，内容运营，运营工作安排，持续运营优化等; yixieshi.com 客服文档:包含产品说明、产品逻辑、用户有可能遇到的常见问题解答等内容，如果产品相对复杂，需要对客服进行现场培训指引;
9. 产品经理都需要写哪些文档，会哪些软件
一、PRD的含义
PRD英文全称Proct Requirement Document，中文意思是：产品需求文档。 PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
二、MRD的含义
MRD英文全称Market Requirement Document，中文意思是：市场需求文档。 该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。 作用是：产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。
三、BRD的含义
BRD，英文全称为：Business Requirement Document；中文意思是：商业需求描述。 基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。
四、PRD、MRD、BRD之间的关系
1、PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明，而产品需求本身是在MRD中有所体现的。
2、MRD侧重的是对产品所在市场、客户（client）、购买者（buyer）、用户（user）以及市场需求进行定义，并通过原型的形式加以形象化。
3、如果说PRD的好坏，直接决定了项目的质量水平；那么BRD的作用，就是决定了你的项目的商业价值。 PRD、BRD和MRD，一起被认为是从市场到产品需要建立的文档规范。
1、Axure RP（Rapid Prototyping）
Axure（读音为Ack-Sure）无疑是目前最受关注的原型开发工具，其能通过组件的方式帮助网站或软件设计师快速建立带有注释的原型（流程图、线框图），并凭借自定义可重用的元件、动态面板以及丰富的script能够建立基本功能或页面逻辑的动态演示文件。
Axure借鉴了office的界面，能够让用户快速上手，并且提供了丰富的组件样式修改，使得通过其能够创建低保真、高保真甚至接近于实际效果的界面。然而最让人称道的是，Axure的丰富的脚本模式，可以通过点击和选择能够快速完成界面元素的交互，如链接、state切换、动态变化等效果，使得Axure能够生成十分接近于真实产品的原型。另一方面，Axure能够导入其他人创建的元件库，使得Axure能够满足绝大多数类型产品的设计。
但Axure仍然有一个让人头痛的问题：对于中文的支持不太友好。在小部分元件上输入中午的时候，经常需要像碰运气似的反复切换输入法，破坏了咱们设计师的用户体验。
瑕不掩瑜，Axure仍然是交互设计师的首选原型工具。
2、Microsoft Office Visio
Visio在2000年被微软收购，并在2002年成为office2003套件中的一个组件，最新版本是2007。Visio能够获得推荐的原因是因为Visio的适用性非常之广，从网站界面、数据库模型，到平面布置图到工艺流程图，Visio都提供了相应的元件库和模板来进行快速创建。
相较Axure而言，Visio更适合于传统行业的生产或流程设计，或者软件及互联网行业中的信息、数据和流程的说明，而不太适用于web界面。因为其的基于web的元件库还是比较少，并且形式和结构也更类似于word中的图形工具，因此在原型开发效率上都有所不足。
3、Balsamiq Mockups
这个基于Adobe AIR Runtime的工具实在是有让人眼前一亮的感觉，手绘风格的元件样式粗犷淋漓，能创建接近于纸上手绘的原型文件。其提供了丰富的手绘风格的web常用元件，包括常用的html控件、以及一些组合控件，如多媒体控制器、标签页、列表、Iphone界面元件等。
Mockups最值得赞赏之处在于其提供的多数组件都可定制外观，对于中文的支持也不错（选择View > Use System Fonts）。
4、Mockflow
Mockflow和以上工具最大的不同在于Mockflow是一项基于Adobe Flex技术开发在线服务，提供了与Balsamiq Mockups基本相似的功能，甚至更丰富的组件，虽然其元件定制化不够强大，但其提供的元件库默认样式却非常适合用来做商业产品原型的搭建。有一个让我爱不释手的功能是模板，可以设置基于任何页面的模板来进行新的页面设计。
与其他模板工具相比，mockflow有一个非常特色的功能，基于web的存储可以在任意电脑上联机打开，同时可以其他人进行快速的分享，并收集在线反馈意见，非常适合虚拟团队的原型设计交流。
虽然在线服务的基本帐号只能创建一个文件，但单个文件却没有限制页数，因此也基本上足够使用。
5、Pencil sketch
Pencil 是一款基于Firefox的扩展组件，安装之后即可在Firefox的工具菜单中打开Pencil的绘图面板。功能比较简单，仅能用以日常简单工作的辅助 说明。提供的默认元件都是基于软件工程，因此更适合用于windows桌面程序的简易界面搭建，或者是基本的页面功能说明，并不适用于严肃的原型开发，但 好在体积小、又轻便，能够方便将网页中的元素直接拖到或者复制到当前的画布中，这也是Pencil安装在Firefox所带来的便利之一吧。
更多工具...
在以上列举的原型开发工具都是较为常用的，也是在国内的交互设计师们比较常讨论的，但其实和Axure功能相似的软件还有很多，下面也就一些简单说明：
6、GUI Design Studio
这 是一款真的非常强大的原型制作工具，没有在上面推荐的原因是因为我还没有实际体验过，但冲着这工程级的界面设计就没有去尝试的冲动，但是从官方网站的截图 和视频演示来看，这款软件的操作模式和前面的原型工具大有不同。Axure之类多是基于页面的原型设计，对于web网站尽管很实用，但是对于软件界面的流 程设计却略显繁琐。而GUI Design Studio却另辟蹊径，直接以建立元素与元素之间的关联的方式来自动化的创建动作流程，而从视频演示来看，这样的确很大程度上提升了软件界面原型搭建的 效率。
7、Prototype Composer
Serena 公司免费提供的原型开发工具，功能确实强大，提供了基于项目管理主要流程的产出物文档模板、原型工具以及开发流程控制，这个软件的开发理念非常好，用这一 款工具来满足项目开发流程中各个环节的沟通和决策。但软件的学习和使用成本比较高，要了解其中的全部功能，貌似需要花不少时间。另外软件的效率和稳定性还 有待提高，试用的过程中多次出错及停止响应。
8、Lucid Spec
由 Elegance科技推出的Lucid Spec是一款很类似Pencil的原型工具，仅仅是提供了更多控件。不过Lucid Spec强调了生成干净的说明文档的功能，这可能是针对于多数原型工具的自动化生成规范的冗余而言的，不过老实说Lucid Spec提供的原型界面太过简陋，并且生成的说明文档也未见优化有怎样的提升。视频介绍
9、Irise Professional Edition
Irise与其他原型工具相比其中一个特色在于提供了样本数据的功能，这是类似于excel表的一个样本数据库，可以通过界面元素直接获取样本数据库中的数据，这样所生成的原型甚至可以使动态数据更新的。
10、Adobe Reader
Adobe reader？没错。其实理论上任何可以创建图形和文本的工具都可以用来原型开发，因为原型本身就是对于业务逻辑和功能界面的模拟或仿真，因此有何理由不能使用PDF格式呢？BoxandArrow的这篇文章《PDF Prototype》提醒了我们，所有的原型工具都只是工具，而不是设计本身。
另外这里的也可参考一下.http://www.oschina.net/project/tag/291/ui-design/
但个人推荐:
原型
• Axure 7.0
• UIDesigner
思维
• Mindmanager
• Xmind
流程
• Visio 2013
• EDraw Max
知识
• 有道云笔记
• 印象笔记
时间
• Todolist
• Worktile
图形
• Photoshop
• Colorpix
交互
• 快现
• UIDesiger
10. 产品经理需要写的文档有哪些
这些客户是什么样子的？ 2、我可以满足他们什么样的需求(提供什么样的价值，核心价值是什么)？我要满足他们什么样的需求？我(暂时)不打算满足他的哪些需求
二、商业价值；
1、我可以为企业创造什么样的价值？
2、这些价值是否符合企业的整体战略目标？
三、路线规划；1、我先满足什么需求？再满足什么需求？为什么？ 2、每个阶段的核心价值是什么？ 3、执行计划(时间…)？
四、历史回顾；
1、客户价值和商业价值是否发生了变化？
2、二期产品的路线规划和原规划是否一致，（如有调整）调整原因是什么？
3、之前的实际运营效果和计划的差异是什么？为什么？
五、成本估算；1、整合各类资源所需要的运营成本、营销成本。
2、研发和维护所需要的人力成本。
3、同时，还需要对未来的风险进行预估，并给出合理的预案。
六、评估方法 1、为什么指定这个目标？这个目标是如何显现出来的？
3、凭什么可以做到这个目标向公司申请需要的费用、资源得到各级领导支持；
MRD阶段
一、 更细致的市场与竞争对手分析；
二、 通过哪些功能来实现商业目的；
三、 功能/非功能需求分哪几块；
四、 功能的优先级；——可能产出物有Mind Manager的思维图，Excel的Feature List
一、产品介绍；
二、用户描述；1. 用户/市场统计；2. 用户剖析；3. 关键用户需求；4. 替代品和竞争品
三、产品轮廓；1. 产品前景；2. 产品定位
四、功能需求；
五、非功能需求；
六、 附件：用户需求调查报告收集、分析、定义主要的用户需求和产品特性——不用考虑系统如何满足这些需求以及需求的技术和资源局限PRD阶段一、 功能使用的具体描述；二、 Visio版功能点业务流程；三、 界面的说明；四、 Demo(注：可是dreamweaver、ps、画图板的简单版，有时也会有UI/UE支持)一、项目边界；二、验收标准；三、业务流程图；四、用例说明；1. 用例总图；2. 单个用例说明五、性能需求；1. 响应时间；2. 空间使用量等六、维护性需求；七、质量需求；1. 安全性；2. 可操作性；3. 可靠性；4. 兼容性；5. 移植性八、接口需求外部接口需求；内部接口需求对MRD中的内容进行指标化和技术化；
明确产品的功能和性能FSD阶段（类似概要设计）产品UI确定;业务逻辑的细节确定;表结构设计功能详细说明