【MRD、PRD】产品经理常用文档.docx

产品经理常用文档大全原创：山有木兮/Stanley目 录1.MRD市场需求文档61.1文档介绍61.1.1文档目的61.1.2内容概要61.2市场问题和机会61.2.1市场问题61.2.2市场机会71.3产品问题和机会71.4技术问题和机会71.5市场概述71.5.1目标市场特征81.5.2目标市场趋势81.5.3目标市场细分81.5.4目标市场时间约束91.6客户和购买者91.6.1目标客户描述91.6.2目标客户细分91.6.3客户动机91.6.4影响因素91.6.5客户目标101.6.6目标购买者描述101.6.7现实需要111.6.8原型联系111.7市场需求111.7.1开发环境说明111.7.2兼容性说明111.7.3性能说明111.7.4国际性说明121.8支持信息121.8.1文档假设121.8.2参考资料121.8.3产品体系122.如何撰写PRD文档133.市场需求文档(MRD)文档的写作方法214.PRD 产品需求文档294.1文件命名（编号）304.2修订控制页304.3目录304.4请与以下部门讨论PRD314.5概述314.6使用者需求324.7可选方案324.8效益成本分析334.9功能需求334.10整合需求344.11BETA测试需求354.12非功能性需求354.13上、下线需求354.14运营计划365.产品需求文档(PRD)的写作方法376.产品需求模板567.单项需求卡片模板618.会议记录模板639.人物角色6410.调查问卷模板6611.某某产品用户访谈纲要6911.1目的与意义6911.2方法6911.3执行方案7012.UC用例模板721. MRD市场需求文档1.1 文档介绍1.1.1 文档目的小威“产品”，是父母一手创造的无价“产品”。对社会无益但也不会对社会有害，但相信对互联网来说只有益，不会有害。1.1.2 内容概要“产品”的好坏，不是按时间长短来判断的，而是按做为“产品”可以让更多件其它产品面市，同时“产品”会为企业带来多少价值。1.2 市场问题和机会小威这件“产品”永远干着打杂的工作，但并不是每个产品都可以为企业打杂。要有企业愿意给你机会为它打杂，同时还必须得打扫的漂亮。不会给企业添加烦恼，只会为之解决烦恼。1.2.1 市场问题产品市场需要打杂的，需要有人为产品打杂，互联网发展的需要，是互联网发展的必须品，不论是引进国外的产品理念，还是中国互联网企业发展的需要，小威这件“产品”还是不可或缺。1.2.2 市场机会国外的时髦概念，国内大型企业有相关的职位，故无论企业大小都开始设产品经理职务，有很多企业总经理是产品经理，但还是需要打杂的，所以小威这件“产品”会永远存在。1.3 产品问题和机会这是个不可退货的“产品”，也是个不可替代的“产品”（我永远是独一无二的）。机会是自己创造的，但这个“产品”存在的一天机会永远是有的，同时这个“产品”会不断创造机会，这个才能发挥“产品”最全面的功能。1.4 技术问题和机会沟通是“产品”最主要的技术，不但要沟通不同的人群，同时还有可能面对肤色问题，种族问题，性别问题，性格问题，所以“产品”技术问题要很全面。机会是自己创造出来的，只有不断的摸索、不断的与人沟通，“产品”技术才会不断的进步，才会认识更多的朋友。1.5 市场概述“产品”存在了，就要为企业带来效益，给我5K的工资就要翻倍给企业创造更高的效益。目标市场描述互联网市场永远不会落伍，众多企业开始走互联网路线，像我这样的“产品”也会得到市场的认同，同时也会有越来越多的猎头开始寻找我这样的“产品”。1.5.1 目标市场特征研究生越来越多，本科生已经成群，像我这样的“产品”更是一大把，高学历不代表高能力，记住一句话“学历代表过去，能力代表现在，学习能力代表未来”。1.5.2 目标市场趋势众多的互联网公司将有越来越多的我这类“产品”，追求最好的互联网公司是发展的趋势，但并不是每个人都可以在大企业生存，适合自己才是最重要的。1.5.3 目标市场细分市场细分 关键特征S大型企业（阿里、百度等） 中国最大、台阶高、分工细中型企业（软件、资讯类网站） 市场需求量大、适合展示才华、“产品”多用小型企业（大部份小型网站） “产品”即CEO，做的比牛多1.5.4 目标市场时间约束青春永远有冲劲，“产品”年年辈出，保持活力，同时缩短“介绍期”，延长“产品”的增长期，稳定“产品”成熟期，不要走向衰退期。1.6 客户和购买者“产品”需要有人买单，谁也不愿意购买不值钱的“产品”，高额的价值背后是高效的工作业绩。“产品”需要找到适合自己的客户和购买者。1.6.1 目标客户描述互联网公司、软件公司等都是“产品”目标客户，客户有选择“产品”的权利，“产品”也要为客户负责的职责。1.6.2 目标客户细分客户细分 关键特征软件公司 系统架构，与技术沟通、寻找用户互联网公司 沟通，全局发展观，运营、策划1.6.3 客户动机即买即用，这是客户动机，不希望“产品”中途退货，买了不能用。1.6.4 影响因素企业文化，工作氛围。1.6.5 客户目标最好的“产品”适合自己发展的需要。1.6.6 目标购买者描述业务决策购买者（BDM）带来经济效益、给企业增加销售技术决策购买者（TDM）创新，激情，团队集体发展使用者和用户原型企业boss是最终的使用者，不是买来摆设的，需要创造利益的。原型特征特征项 描述原型名字 小威背景 产品经理技能 Axure、MM、word、excel、ppt环境 适者生存、优胜劣汰态度 激情永在行为 干一行爱一行目标 做最适合boss的“产品”备注 没有最合适的，只有自己不断的改进，达到最好的1.6.7 现实需要社会发展需要“产品”，互联网、软件行业少不了“产品”1.6.8 原型联系1.7 市场需求互联网永远是个不断有生机出现的市场，软件行业永远会有更新换代时期，这就是“产品”的市场需求1.7.1 开发环境说明熟手上阵是企业最喜欢的，不能做到最熟的“产品”，但希望做到用最短时间适应的“产品”1.7.2 兼容性说明“产品”适应性强，生存意识强1.7.3 性能说明“产品”身体健康，工作态度端正，学习能力强1.7.4 国际性说明暂无出口国外的意识1.8 支持信息“产品”不是万能的，同时需要其它的配合，团队合作才是最根本的1.8.1 文档假设如果“产品”适合企业发展需要说明“产品”用的适如恰当，如果阻碍发展，将是“产品”的悲哀，但相信“产品”只会给带来好的方面1.8.2 参考资料这是“产品”磨练过程，不是很长，但相信“产品”总有适合的一点1.8.3 产品体系“产品”只有被伯乐识别才是真正的“产品”做一件真正满足市场的“产品”，努力！。2. 如何撰写PRD文档产品经理主要有两项职责：评估产品机会 定义要开发的产品；前者我们在上篇的如何获得产品立项文章中已经大致介绍过；而定义开发的产品则需要通过产品需求文档(PRD）来描述产品的特征和功能。本篇主要分享下博主平常工作中是如何撰写移动应用的PRD文档的。PRD(开发需求文档）的作用在学习如何撰写PRD之前，我们先要明白写PRD的目的是什么：概念化”阶段进入到“图纸化”我们之前在市场需求文档（MRD）中阐述到的功能，都是表达的一个意向，不考虑实现方法和细节。而PRD则是将概念图纸化，需要阐述详细的细节和实现模型。产品人员可以通过撰写PRD，梳理清楚方案实现过程中的各种问题和影响。向项目成员传达需求的意义和明细PRD的主要面向对象是项目经理、开发、设计和测试。如何向这些不同的角色表达清楚需求明细，就需要一份规范的PRD文档来描述。项目经理通过文档可以迅速了解任务的规模和相关接口，而开发设计人员通过文档可以了解页面元素和用例规则，测试人员可以提前根据文档撰写测试用例。PRD文档在形式上是项目启动的必要元素之一。 管理归档需求大都数的新需求都需要迭代几个版本后才能走向成熟稳定的阶段，如果没有PRD文档，在大型项目中，需求的迭代变更将变的无据可循。PRD的文档修订编号和命名也是项目规范化管理的主要方法之一。PRD的表现形式一般企业内部的PRD文档选择wiki系统或word文档。wiki在协同和保密方面会有优势，而且能够记录修改文档的每一次变更。而word在阅读修改方面比较有优势，一般使用Word加SVN的方式来管理更新文档。这个可根据每个企业的管理规范来选择那种方法更合适。PRD的主要构成一份基础的PRD文档主要由三部分组成引言引言部分主要包括：需求背景、需求目的、需求概要、涉及范围、全局规则和名词说明，交互原型地址等。引言部分的写作目的是让阅读者快速理解需求背景和概要。如果是公司内部文档，引言部分可以从简写作。业务建模建模的目的是为了帮助阅读对象更好的理解需要开发的需求，常用的模型种类包括：用例图、实体图、状态图、流程图等。常用的建模语言如UML。UML具体的建模方法请戳这里。 业务模块业务模块包含具体页面的元素、用例规则，以及相关的原型，流程图。业务模块的描述是整个文档最核心的部分，下面博主用案例来描述一下业务模块的编写方法。案例介绍：旅行箱目的地攻略（应用商店搜索“旅行箱”）需求的目标是在APP中展示相关国家/城市的旅游资讯内容，如下图所示：那么我们在第一部分的引言中可以写下简单的需求描述：1 目的地攻略以城市/国家为单位，展示八个栏目下的文章列表。2 初期运营指标为编辑所有涉及城市的归属国家攻略内容，相关城市暂不编辑；APP前台默认显示国家内容卡片，城市内容卡片无数据时隐藏。3 运营系统提供内容生成对应的触屏网页，App读取和下载对应网页内容；为了帮开发者迅速了解需求结构，我们需要建一个简单的流程图帮助开发理解功能：相对复杂的运营系统，我们可以补充相关用例图和实体关系图：引言和建模部分是为了帮助开发和测试人员快速理解需求，具体的页面和用例规则还需要通过第三部分的业务模块来描述，这里我们节选案例中的文章列表页来描述：文章列表页共包含一个页面，四个用例那我们的描述结构就为：文章卡片页面元素收藏文章用例分享文章用例查看文章列表查看文章（太简单可不描述）文章卡片的页面元素描述：（收藏）用例的描述为业务模块的描述一般是原型图+数据元素+用例描述，这样可以在原型图的基础上加上对应元素属性的描述，并通过动作描写的方式表达用例规则和各种流程。这样的写作方式不仅可以向不同对象传达产品经理的意图，而且可以帮助产品经理自己梳理需求的逻辑和各种异常流程。3. 市场需求文档(MRD)文档的写作方法MRD定义与分类MRD指Market Requirements Document，简称市场需求文档。市场需求文档的主要功能是描述什么样的功能和特点的产品（包含产品版本）可以在市场上取得成功。产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。产品市场经理（PMM，Product Marketing Manager）负责分析市场变化，通过对市场的分析，MRD指出什么样的新产品、方案和服务可以更好的开拓市场。通常情况下，产品经理或者技术产品经理会将在MRD的基础上完成PRD（Product Requiremnets Document），技术团队应用PRD开发产品。在百度的ECOM PM部门，MRD要分为给RD/QA看和给业务部门看的两种。给工程、测试、设计看的MRD是他们的输入信息和测试对象。给业务部门看的MRD，最主要是因为MRD里面的功能实现后，会对客户产生影响，所以必须确认业务部门知晓。MRD基本写法一般来说，MRD包含“项目背景”“名词解释”“可行性分析”“综合描述”“功能详述”等部分。这里结合不同版本的MRD谈谈MRD的基本写法。目前看到的几个MRD比较重视功能需求这块。功能需求主要包括功能点类型和优先级/流程图/页面布局/功能点描述等要素。其中优先级和功能描述比较重要，流程图常可省略。要素1：项目背景要让RD理解。“具体开发的背景是什么，解决什么问题得写清楚，否则开发人员在不清楚背景的情况下去做，很容易出问题，而且也缺乏参与感。”事实证明，谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的对工程师很有价值，许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。要尽可能的（在MRD中）包含这些信息。不一定要很详细，只要包含几个段落就足够了。要素2：名词解释要确保RD看得明白。在名词解释这块，“描述的准确性很重要，没有二意性，否则，等RD开发好了以后，才会发现和自己想要的不一样，追溯mrd才发现有歧义。”要素3：要考虑系统的兼容性等不确定因素，把控风险。我们应该提前把控风险，不确定性降到最低，并具有良好的沟通和通报意识。例如，当MRD要求的是原来系统的更新，而不是一个全新的，与其他系统没有关联的产品时，应考虑到更新的内容与原来的系统其他部件的接口，以及其他外部系统的兼容。eg：2006年8月3日MRD）要素4：对于要实现的系统功能要详细分解。每一步出现什么界面，进行什么操作，下一步又怎么进入什么界面，进行什么操作，都要介绍清楚，这样比较容易让RD明白，也易于实现。（eg：2006年9月4日MRD ）要素5：在涉及数量关系时，要利用好公式。要用公式明白地表明变量的关系。对公式里面变量的定义必须清晰无疑义。在列举公式时，需要穷尽所有可能的情况，此外，还需要列举注意事项，澄清可能存在的误区。在增加QA时，要把提问的问题写清楚。（eg：2006年8月3日写MRD）MRD里面的数据来源最好有附表，这样比较清楚明白。（eg：2006年9月4日MRD）要素6：要区分功能需求的优先级。通常来说，工程师团队不一定能全部实现MRD里包括的所有特性的没有删减的项目。当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括客户和公司。在实际实践中，最好是和其他多种因素一起综合决定。在学习材料里面的几个MRD里面一个突出的问题是优先级写的都是很高，没有根据第一等级，第二等级这样的区分。（eg：2006年9月4日MRD）要素7：要积极参加评审鼓励修正。要让产品经理伙伴和工程师团队评审MRD然后提出反馈意见。保持一个敞开的思想然后在评审反馈的基础上更新MRD。（eg：2006年9月4日MRD）要素8: 要覆盖非功能性需求要用功能性需求描述产品的功能，然后用非功能性需求描述系统特性，当写非功能性需求的时候，尽可能的是使他们可度量（可测试）。否则，QA不能测试它们，PM将没有办法知道完成的产品是否已经实现了这些非功能性需求。要素9：要包含一个术语表如果MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一 个术语表。术语表将确保所有读者（有些可能不是技术人员）理解PM的意思是什么 。要素10：深入分析目标用户群需求，市场发展趋势，竞品，结合自身优势找出制胜点在学习的历史MRD中，没有包含市场分析和定位，而针对市场做好分析其实是很重 要的一块，因为“写MRD一定就和画像一样，得现有轮廓，然后才有具体里面的眉毛、眼睛。”特别是对目标用户群需求，市场发展趋势，竞品等深入分析，然后结合公司自身优势找出制胜点。MRD必须在覆盖了市场目标（谁将买和使用户你的产品）和定位（与竞争对手的产品比你的产品定位怎么样的）的方面做好。那么，如何分析好市场目标和定位？首先，在写MRD之前，得有细致的研究和沟通阶段。其中比较重要的是要知道几个为什么：“用户需要的是什么？/ 我们为用户提供的是不是用户真正想要的？/ 凭什么能代表用户？”其他考虑的因素还有很多，例如人力，时间，成本，价值等。综合衡量很多因素，最后决定是否需要做这件事情。在这方面，我们也可以通过以下方法去实现：1、对于某产品可以进行调查问卷的形式发放出去（搞一些活动之类的）2、对于有针对性的产品，可以去专访一些资深的用户去调查体验3、找一些资源，设计一些脚本程序，用这个脚本程序，计算需要的数值，用数字说明用户想要。多个维度的思考会比较有力，所以最好综合参考几个维度。撰写MRD的常见陷阱和对策陷进1：如何不断提高可读性？为了确保MRD可以执行，最重要的是提高MRD的可读性。其中可读性一般包含准确性和易读性两个方面。不准确指表达模棱两可，容易让人误解；不易读指逻辑关系太复杂，表述太长，不容易理解。那么如何尽量避免这两个问题呢？1 插入屏幕截图或者流程图，同时保持文本和图片描述一致。一般来说，图片直观，容易理解。与此同时，因为MRD经常会改动很多次。当文字发生改动时，图片也应做相应的改动，以免带来不必要的混淆和误解。Eg1: 图片中写了付款方式，但是文字中提到相应概念时，却说是“缴费方式”，那么就容易让人产生误解。Eg2: 图片里面画了简略的图表，但是文字里面有了详细的分支的展开。那么读者在图表里面找不到文字里面描述的分支，就会产生困惑。2 正文批注分开，省略功能实现等方面的细节有时候MRD里面描述非常清楚，但是RD和QA希望提供更多的细节帮助理解。于是MRD越写越长，造成易读性变差，怎么办呢？MRD里面应该省略细节，主要讲产品设计的思路。在排版时，应该把正文和批注分开。细节写在批注里面。这样一方面条理清楚，容易阅读。另一方面，讲清楚为什么这么设计的原因，而不穷举功能该如何实现，可以发挥RD的主观能动性，让他们更有参与感，从而主动去想如何做得更好。应该说明的是是什么和为什么，但不要如何 和“怎么样”。3 通过版式来提高MRD易读性MRD最好控制在5-6页之内。如果MRD比较长，最好使用1.5倍行间距，以便RD读起来比较舒服。如果使用模板，确信相关人员可以灵活的跳过模板某些部分和创建新的内容。另外，应避免大段的文字。如果使用宋体5号字，文字超过两行半，就应该利用良好的逻辑结构来使文章易读，例如使用分段，序列符号，并列符号等等。在语句组织上，应保持简短的语句，把长的语句分解成多个小的语句。或者把大块文本做成表格都是很好的办法。4 通过详细解释项目背景和名词解释简化MRD项目背景和名词解释对于某一个具体的MRD都是通用的知识。在项目背景和名词解释方面解释得越详细清楚，越有助于RD和QA理解下文中功能点设计和实施目标。预先的解释可以大量减少MRD后续解释的篇幅。5 功能点和功能点之间合理分配篇幅并注意衔接对于比较复杂需要长篇叙述的功能点应该进行进一步的细分。例如一个5页的MRD如果包含5个功能点，那么就不应该让一个独立的功能点占据2页的篇幅。如果两个功能点A和B提到了同一个背景知识。为了节省篇幅，我们只需要在A展开背景知识，而在B的相应部分写上“相关介绍请见A”。如果多个功能点共享同样的背景知识，造成嵌套的情况，容易让人对功能点之间的逻辑结构产生混淆。这时候应该画功能点逻辑图，以便于读者理解。陷阱2：如何抓住关键，又不错过关键细节？在MRD的纂写过程中，必须抓住关键，不能太纠缠于细节。与此同时，有些细节也是很关键的，需要辨别出来，那么，哪些是关键的细节呢？1 当一个流程出现分支/异常的时候，临界的判断条件是关键细节Eg 假设一个点击3毛钱，一个客户的广告该不该出现？那就需要考虑用户的预算/帐户余额等多种情况，然后确定广告是否出现，以及广告被点击后的后续操作2 涉及用户体验的细节是关键细节Eg 当客户点击一个操作按钮时，应该在新窗口打开，还是新标签页打开？3 当一个过程操作结束后无法恢复时，处理方式是关键细节Eg 当客户删除一个关键字时，操作是不可重复的，那么是不是应该有一个二次提醒的框？陷阱3：多模块的合作模式下，MRD需要注意哪些方面？有时候产品的更新不是一个独立进行的操作，而是涉及到多个模块的合作。应该注意推举一个总负责人，确保MRD与MRD之间，设计与设计之间不重合，也没有三不管地带。既减少别的产品更新给自己的产品变化带来不利影响，也认真考虑自己的MRD对别人的影响。陷阱4：处于和RD/QA磨合期时，MRD需要注意哪些方面？处于和RD/QA磨合期时，应该注意预判RD/QA可能出现的易错点和盲区，做好PPA/POA分析，及早预防可能存在的意外。尤其是当MRD推的产品非常重要时，需要特别注意这一方面。另一方面，如果RD和QA在新人培训方面的确做得不到位，也应考虑暴露问题，推进问题的彻底解决。4. PRD 产品需求文档PRD是每个产品人员最经常看到的文档，还是有很多产品的朋友问我PRD怎么写，如何才能表达清楚意思。其实PRD并没有规定的格式，每个公司都可以根据自己公司的实际需要来写适合自己产品团队的PRD。PRD（Product Requirement Document，产品需求文档），这对于任何一个产品经理来说都不会陌生的一个文档，一个PRD是衡量一个产品经理整体思维的标准，一个PRD可以看出 一个产品经理在某个领域的专业性，同时也可以反应出一个产品经理的整体产品思维。产品经理的整体思维体现在：1、提炼核心需求2、思考满足核心需求的方式3、评估方式优劣选定方案4、思考功能概要5、思考支撑功能和关联功能6、细化设计功能7、子功能（功能间迭代）PRD其实就是将以上的思维整体走向写出来，同时将产品的思想提炼出来，用文字表示给开发者，给UI、给视觉、给老板PRD给的是一种思想，将 产品的整体思想和核心需求灌输给产品的相关人员，都说PRD是个承上启下的功能，因为上接MRD，下对MRD进行技术性的描述。网上已经有太多互联网公司的PRD文档，淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范，适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例，讲解一下PRD的主要内容。4.1 文件命名（编号）文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭 代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名-PRD- D1.1”，当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”。4.2 修订控制页一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序，文档版本显示的当前修改的内容是在哪个版本中出 现，修订章节是具体到哪个章节哪个功能模块的修改，修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期，修改人显示修改内容模块的 人，可能是当前用户也可能是其它产品人员。4.3 目录不建议自己去添加一个新的目录，你可以去其它的文档中拷一个过来，不考虑目录的内容，等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。4.4 请与以下部门讨论PRDPRD做为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员 确定“沟通内容”，这对于产品整体流程将是很重要的。同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。例与客服中心：客 服服务部，讨论的内容：预测客服成本、工作量；讨论客服如何支持；协助评估诈欺/数据窜改风险：欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部 门讨论PRD中的。一个产品经理需要考虑如何与其它部门之间的沟通合作，文档很大一部分的功能是提醒你要做的工作，同时不断补充将要面临的工作。4.5 概述概念就是总结，它包括的点有：名词说明、产品概述及目标、产品roadmap、产品风险。名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。产品概述及目标：解释说明该产品是干什么的，为什么需要这样的产品。同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解，同时希望可以达到的期望。产品roadmap：产品分期目标，阶段描述，以及时间点的确定，产品是个不断演进的过程，很多时间一期产品只完成了产品70%的功能，二期才会继续去完 善剩下的30%，同时有可能会推翻了重新推出第二版。产品roadmap并不及着全部规划好所有的阶段目标，而是更多的通过维护来保持产品的更新和迭代。产品风险：描述产品可能存在的风险，比如商务谈判的风险，外部合作的风险，不当使用的风险等等。风险级别为高中低。4.6 使用者需求使用者需求一般只有个需求描述。需求描述有以下几项内容：目标客户、需求描述、场景描述、优先级。目标客户即为产品的最终用户，确定产品的最终使用者。需求描述是对目标客户的需求描述，表达用户最需要的是什么，找到用户的最根本需求。场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。优先级是指用户对于当前产品功能需求的优先级，哪些是用户最想要的功能优先级则排前。4.7 可选方案列出所有可以选择的达到该产品目标的方案要点（主要思路），给各方案适当的评价，并推荐最优方案。你在做这个产品规划时一定有很多的备选方案，别放弃这些方案，永远没有过时的idea，只有最适合时机的idea。所以可以写出几个可选方案，或许是你下期产品改版一个方向。4.8 效益成本分析产品经理是个全才，在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面：效益预测、产品技术中心成本、非产品技术中心支持成本。效益预测是指提供在各种产品环境中的效益预测，并标明主要的变量及假设，最好能包含现在和过去的效益数据。如网站的PV值，软件的使用数都是效益预测数据。产品技术中心成本是指设计及部署此产品的产品技术中心所需的资源需求，包括人力成本，软硬件支出等。很大时候这份成本需要由项目经理来协助，需要有什么样的人才加入产品中需与人力协助。非产品技术中心支持成本，产品不是只有产品组完成的，同样需要其它部门的配合与协助。比如：需要客服部投入多少的资源用于该产品的服务，需要运营部投入多少的资源运营该产品。4.9 功能需求功能需求一般是由四部分组成，功能总览、功能详情、整合需求、BETA测试需求。功能总览一般包括二个部分，一个是流程图，一个是功能表。流程图是对产品的整体走向的流程的规划，流程图是用来对产品整体功能的梳理。所以在做产品前建议所有的产品经理先梳理一下产品流程。功能表是将流程图文字化，同时将列出产品的功能点。功能详情，这是所有的产品功能的描述和规划。包括以下内容：简要说明：告诉此功能主要干什么的。业务规则：每上产品在使用时都有自己的规则，而产品的业务规则则是将产品的流程细化。个人建议将这个功能的业务规则，包括一些细节，如排版形式、日期显示方式全定好，这样方便其它人员的沟通和理解。界面原型：产品经理在这时做的原型界面只是显示的框架，别细化，这样会给交互和UI造成错觉。只需做一个简单的界面即可，更多的时候只是个框架图。执行者：产品使用者。前置条件：具体的操作。后置条件：操作后的展示。在UC（user case）中后置条件又是另一种情况，所以对于建议在PRD中的前置条件和后置条件结果合起来。主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明。将此功能的流程走向做个分点说明。4.10 整合需求产品经理很重要的一个能力就是体现在产品整合能力上，利用公司现有的资源或外部资源（合作公司等）实现产品功能需求的整合。实现功能贯穿的同时，更多的如何在新产品上实现功能的拓展来辅助核心功能。4.11 BETA测试需求很多产品都有BETA版本放出，为了就是收求意见和一些性能测试。这部份内容不是必须的，但现在很多产品已经开始先推出BETA版本再推出正式版，当然也 可以通过升级来解决。所以BETA测试需求并不是一定需要的。如果有BETA测试需求，则需写出BETA版测试的要求和期望达到的目标要求。4.12 非功能性需求都说产品经理是全才，在这点上得到彻底的体现。很多产品经理在这点上忽视了，但很多方面是用到的，只是在产品过程中弱化了。一般情况下非功能性需求包括以下几个部分：产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等。与其说是全方位的掌握技能，还不如说是沟通，如何与不同的部门人员之间的沟通，让更多的人协助产品的正常使用与上线。4.13 上、下线需求上线时限需求：此产品预定上线日期？上线日期有无任何特殊依据或规定？下线需求（活动类需求必须明确下线时间）：此产品预定下线日期？下线日期有无任何特殊依据或规定？4.14 运营计划说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户，产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。写PRD并不是产品经理的全部工作，但却是不可少的一部分，很大程度上反应了产品经理的思维和产品核心功能把握上，同时对产品经理沟通、协调、规划等都得到了一定的验证，但每个产品经理的第一职能是会写一份让其它人员看得懂的PRD。5. 产品需求文档(PRD)的写作方法无论我们做什么事都讲究方式方法，写产品需求文档(以下称PRD文档)也是如此，之前我通过五篇文章分享了自己写PRD文档的一些方法，而这一篇文章主要是对之前五篇文章进行整体的摘要介绍，帮助大家快速了解写作流程。产品需求文档(PRD)的写作 五篇章：1、写前准备(信息结构图)2、梳理需求(产品结构图和用户流程图)3、原型设计(手绘原型,灰模原型,交互原型)4、撰写文档(PRD文档)5、用例文档(UML用例图、流程图)1、写前准备(信息结构图)：在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。2、梳理需求(产品结构图和用户流程图)：当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。我们首先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。3、原型设计(手绘原型,灰模原型,交互原型)：当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性，当有一定的进展之后，我们再通过软件工具进行更深入的设计。移动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了避免产品宣讲时，抽象的语言描述导致听众理解困难和理解偏差。4、撰写文档(PRD文档)：当我们通过以上三个大的步骤之后，我们就已经非常清晰产品的需求了，一般情况下，通过原型加描述的方式就已经完成了PRD文档的目的(很多产品经理直接使用Axure制作PRD)。当然也会有一些个人或团队的要求不一样，对PRD文档有特定的规范标准，这类情况可能是需要存档归类。无论什么样的规范标准，PRD文档的目的都是相近的，因此功能描述的方式也是相似的，所以在这里我分享了三种撰写PRD文档的方式。5、用例文档(UML用例图、流程图)：产品需求文档(PRD)的写作方法的补充文章，主要讲解PRD文档中的重要辅助文档“用例文档”。产品需求文档的写作(一) 写前准备(信息结构图) 当我们初次接触产品需求文档时，首先会从网络上寻找产品需求文档模板，希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的PRD文档都是与实际工作不相符的，或者说是复杂的。前几天一位从事产品类工作的朋友，发来一份他写的产品需求文档目录截图给我(下图)，当时我就郁闷了，这些类目更像是MRD文档，而不是PRD文档了，因此我决定写几篇讲述写作PRD文档的文章，分享一些我关于PRD文档的见解和写作方法。 PRD是英文Product Requirement Document的缩写，中文的意思是产品需求文档，具体的名词介绍大家可以询问Google。PRD文档是基于BRD、MRD的延续文档，主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。在这类人群中，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向于技术人员。相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。PRD文档是一份没有闲话，直入主题的功能说明文档，因此我们在写作时，脑海里构思的是成品