程序员怎么写prd

‘壹’ BRD MRD PRD应该怎么写，提纲如下

这些客户是什么样子的？ 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确定; 业务逻辑的细节确定; 表结构设计 功能详细说明

‘贰’ 产品经理的PRD到底该怎么写

PRD（Proct-Requirement-Document，产品需求文档），写作目录如下：
1、文件命名（编号）
文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代。
2、修订控制页
一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。
3、目录
4、请与以下部门讨论PRD
PRD作为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员确定“沟通内容”，这对于产品整体流程将是很重要的。
5、概述
概念就是总结，它包括的点有：名词说明、产品概述及目标、产品roadmap、产品风险。
6、使用者需求
使用者需求一般只有个需求描述。需求描述有以下几项内容：目标客户、需求描述、场景描述、优先级。
7、可选方案
列出所有可以选择的达到该产品目标的方案要点（主要思路），给各方案适当的评价，并推荐最优方案。
8、效益成本分析
产品经理是个全才，在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面：效益预测、产品技术中心成本、非产品技术中心支持成本。
9、功能需求
功能需求一般是由四部分组成，功能总览、功能详情、整合需求、BETA测试需求。
10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上，利用公司现有的资源或外部资源（合作公司等）实现产品功能需求的整合。
11、BETA测试需求
很多产品都有BETA版本放出，为了就是收求意见和一些性能测试。
12、非功能性需求
都说产品经理是全才，在这点上得到彻底的体现。很多产品经理在这点上忽视了，但很多方面使用到的，只是在产品过程中弱化了。
13、上、下线需求
上线时限需求：此产品预定上线日期？上线日期有无任何特殊依据或规定？
下线需求（活动类需求必须明确下线时间）：此产品预定下线日期？下线日期有无任何特殊依据或规定？
14、运营计划
说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户，产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。
……
写PRD并不是产品经理的全部工作，但却是不可少的一部分，很大程度上反应了产品经理的思维和产品核心功能把握上，同时对产品经理沟通、协调、规划等
想学习更多PRD文档写作方式，可以来官网学习

‘叁’ 怎么写prd文档

这些客户是什么样子的？ 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确定;业务逻辑的细节确定;表结构设计功能详细说明

‘肆’ 如何撰写PRD文档

prd文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。

开发工具推荐 ：
Rational Rose★★★★－－熟悉项目发生的相关业务行为。
visio 2007★★★★－－将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一
mind manager★★★－－把项目条目化，条理化，目录结构具体规定好。
Axure★★★－－前台结构布局，合理规范的将系统脱去朦胧的华纱。
Word★★★★★--穿针织网，把需求综合起来，整理成最终的产品需求文档。

也就是用以上任意一种软件都可以打开，不过应该有版本要求。

‘伍’ PRD文档到底有什么用

PRD的最大作用是指导产品设计的，让ui设计的时候不会跑偏。

稍微大一点的团队产品经理未必能向每个人传达产品需求，这就需要有一个文档的形式来向项目的所有成员来传达需求，这就是文档的来源。

简介

由于产品经理经常会变更需求，经常爱拍脑袋，容易变卦，所以程序员就想到用一个文档来约束产品经理。

测试人员需要根据产品需求文档来验收产品质量。

当你的项目有新人进入的时候，可以让新人更快的了解产品。当你离职的时候，继任的产品经理也可以根据你的文档来熟悉产品迭代的内容。

‘陆’ 怎样开发互联网产品

互联网产品开发阶段大致有以下几点
需求阶段
需求产生
需求产生有三种渠道： a) 业务部门（或根据客户的需求）提出需求，包含行业应用部、市场部、互联网部等部门。
2. 策划阶段
2.1. PRD（Proct Requirement Document产品需求文档）
PRD侧重对产品产品功能和性能的说明，相对于MRD中的同样内容，要更加详细，并进行量化。PRD一般包含流程图、原型图等，使用用例等手段，以准确说明。若无MRD，则PRD需对目标进行说明。PRD为必须经过的步骤，由PD或UI完成。PRD需进行编号，编号规则详见“需求编码”表格。
2.2. 评审
需求方、相关领域的顾问（即有丰富经验者）、PD或UI参与的评审PRD的会议，一般项目经理、PM需参与会议。若项目较大，需邀请总经理参与。会议必须有主持，并在会后出MEMO（备忘）或PRD更新说明。专家评审结束后，PD出设计结果方案，需求方签字确认。程序员接到PRD方案后，需评估完成开发的大致时间，以及任务分解安排。当需要GUI方案作为辅助判断时，需明确提出。
2.3. 交互DEMO
ID（Interaction Designer交互设计师）根据PRD定稿做出交互设计方案，真实再现用户交互过程，并与PD、UI进行内部评审。视情况，PM参与。（因公司没有ID，此步骤由PD与美工，视觉设计师，口头沟通完成）
2.4. 视觉界面
由美工（视觉设计师）设计页面风格、布局、关键界面等，交由PD、UI、ID进行内部GUI（Graphical User Interface图形使用者接口）评审。GUI方案通过后，页面制作师开始切割页面，编写HTML。
3. 开发阶段
3.1. 后台编码
在编码之前，程序员应视其系统需要，进行概要设计、数据库设计，并进行内部讨论和评审，邀请顾问参与。程序员对文档有疑问或不理解，需与PD进行沟通，了解其真实涵义，不得以任何理由私自更改已确定的PRD、GUI方案。确有功能需做调整，程序员需与PD、需求方共同协商完成。改动应出具文档，由需求方、技术经理、PM签字后生效。
3.2. α（alpha最初）测试
在开发小组内部进行，测试的方法也较多，黑盒、白盒、 压力、应力等。此阶段应完成80%以上的需求开发，测试以PRD为准。测试完成后，收集反馈，修复BUG，优化流程。开发者在场。
3.3. β（beta第二次）测试
有选择地请一些最终用户实际使用，将发现的问题反馈，开发者对系统进行最后的修改，之后准备发布最终产品。β测试开发者不在场。产品估算开发时间，以完成β测试为准。
3.4. 产品发布
β测试后，PD校验产品。如产品与策划方案相差较大，有权不接受产品，责任由开发部门负责。将产品发布日设为里程碑，以此考核整个项目的运作效率。
4. 校验阶段
4.1. 发布跟踪
产品上线后，PD或市场调研员负责收集用户操作数据，检测各个反馈渠道，筛选数据，出具用户检测报告，检验产品改进是否达到预期目标。立项产品应专门出具报告，非立项改动需在数据分析报告中体现。
以上只是对产品开发的常见流程进行的解读，不同公司，不同项目间会有部分的优先级变动，但大体流程是类似的。因此，了解了大致流程，就会在工作中做到心中有数，不会在与产品、UI、技术、测试人员沟通时出现大的障碍，使得项目可以快速推进

‘柒’ PRD怎么写

1、文件命名（编号）
文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”，当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”。
2、修订控制页
一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序，文档版本显示的当前修改的内容是在哪个版本中出现，修订章节是具体到哪个章节哪个功能模块的修改，修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期，修改人显示修改内容模块的人，可能是当前用户也可能是其它产品人员。
3、目录
不建议自己去添加一个新的目录，你可以去其它的文档中拷一个过来，不考虑目录的内容，等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。
4、请与以下部门讨论PRD
PRD做为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员确定“沟通内容”，这对于产品整体流程将是很重要的。同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。例与客服中心：客服服务部，讨论的内容：预测客服成本、工作量；讨论客服如何支持；协助评估诈欺/数据窜改风险：欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部门讨论PRD中的。一个产品经理需要考虑如何与其它部门之间的沟通合作，文档很大一部分的功能是提醒你要做的工作，同时不断补充将要面临的工作。

‘捌’ 如何写出好的PRD

首先，先了解清楚PRD的阅读对象，使用者。
PRD的模版中一般有如下信息：
PRD预期的读者包括：产品、开发、测试人员及相应的负责人和用户方代表。产品、开发、测试人员会从中了解到本次需求的背景和详细要求，以及每个需求点未来的优化方向或对用户的价值。而用户方代表则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求，是否符合以及是否都覆盖到了自己的预期。因此PRD也是产品经理同相关角色确认开发任务的重要依据。当所有角色认可了PRD中的内容后，这份PRD将作为后续开发、测试、需求验证的依据。
其次，一个完整的PRD还应该具备的要素有
1、文档的命名和编号
文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆。
2、文档的版本历史
包括，编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版本(或第几次修改，一次修改一般为一个版本)，章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观的了解原因。日期是指需求文档修改的时间，修改人是指需求内容的修改者。
3、目录
不需要自己新建，文档完成后直接更新模版中的目录即可。目录是用来了解文档结构的
4、引言
这部分的内容有：产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明
产品概述：解释说明该产品研发的背景以及核心功能。
预期读者：文档的使用对象
成功的定义和判断标准：旨在说明产品的目标
参考资料：PRD的参考资料
名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。
5、需求概述
需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等
需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。
用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明。
运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。
设计和实现上的限制：比如控件的开发环境、接口的调用方式等等
项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等等
产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。
6.功能需求
功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：
简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。
场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件
使用者说明：对产品使用者做出说明，可融入简要说明中。
前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。
后置条件：操作后引发的后续处理。
主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明(这是非常重要的)。
推荐一个方法：“用例”，在面向对象的软件设计模型中，用例是一个被阐述的内容，用例是对功能使用场景的解释。用例很条理的介绍了每个功能的前置、后置条件，主流程介绍，帮助开发、测试等角色快速的了解产品功能。
7、可选方案
列出所有可以选择的达到该产品目标的方案要点(主要思路)，给各方案适当的评价，并推荐最优方案(在功能需求中描述的)。你在做这个产品规划时一定有很多的备选方案，别放弃这些方案，永远没有过时的idea，只有最适合时机的idea。所以可以写出几个可选方案，或许是你下期产品改版一个方向。记住，多思考方案是永不为过的
8、效益成本分析
通过这一点上能看出产品经理必须是个全才，不仅要具备行业知识，还需要有财务知识。一个产品的成本衡量一般包括三个方面：效益预测、产品技术成本和其他成本支出。
9、整合需求
产品整合能力是产品经理很重要的一个能力，业务合作通常是不可避免的，将隶属于两个不同来源的业务功能做整合也是常见需求，比如系统登陆使用公司的域用户登陆，或者付款使用财付通、支付宝付款，解决好整合需求也是体现产品经理核心竞争力的一大重要表现。
10、BETA测试需求
很多产品在正式上线前都有BETA版本或者内测版本，或者叫灰度版本，目的是在测试产品的一些核心功能或者性能。这部份内容不是必须的，但如果需要，需要给出在此阶段要实现的目标或测试、衡量标准。
11、非功能性需求
一般情况下非功能性需求包括以下几个部分：产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。这些信息构成了产品上线的完整内容，也很好的体现了产品经理的综合素质。
12、运营计划
产品上线后如何运营，目标受众是什么，建议的推广策略、问题反馈途径、风险监控、亮点宣传等等，以及与运营人员的协作方式。作为产品的设计人员不是开发完产品就能画句号的，让产品用起来、用得好，有口碑更为重要，所以非常建议运营计划的制定上有产品设计人员的参与。

‘玖’ 刚入职的Java程序员，怎样去看公司的项目，看不懂怎么办

首先你入职的是什么等级，一般来说公司都有等级的划分比如：初级 中级 高级软件开发工程师。
一般进公司都会给你一个星期的适应期，在这适应期你必须做好理解业务，理解公司文化，理解架构等。
如果你是初级 会有项目经理指导你核心问题。建议不要问的太频繁，毕竟招你进来是解决问题的，不是制造问题，看不懂，主要是哪里看不懂，代码都是通过业务来写的，你如果看到业务代码不懂可以直接先看prd或者产品文档，接口文档等一切可以梳理业务逻辑的代码，如果有技术问题，可以大方的问你的项目经理，他会告诉你的。
如果是中级，成本就不一样了，所以你的基础必须要扎实，一些消息队列（rabbitmq,activemq等），nosql（redis,mongo等）,分布式（spring cloud，bbo等），db（mysql等）。一般来说都够了，再不懂的也可以问项目经理，毕竟是中级。
如果是高级，那完全都不用说了，基本什么都懂了，框架类的都是浮云，业务逻辑随随便便看看就好了，而且一般打代码也很少了，主要是框架类的维护。

当然了，如果你是实习生，就相当于打打杂了，他会安排你学习什么，然后修补一下bug，让你有独立性，所以不用担心。不过也少说多做。
纯手打，工作经验累积出来，如不喜欢，勿喷。谢谢！

‘拾’ 产品经理应该怎么写BRD、MRD、PRD（需求文档）呢

因为内容较多，我就简要说一下写作目录
BRD文档
01 BRD说明
概念：BRD文档是产品生命周期中最早的文档，是我们产品定义阶段的汇总。
用于：说明市场分析，销售策略，盈利预测，产品构思等。
目的：说服领导及同事为此项目提供资源支持。
02 BRD撰写
撰写结构：方案背景、产品规划、运营规划、收益&成本、盈利模式、风险&对策
整体结构梳理如下：
1. 方案背景
描述背景的所有的数据最好注明数据来源。可以通过上市公司财报，艾瑞咨询，或一些知名网站的采访文章来获取数据，甚至是内部人士的消息，都是重要的参考来源。
基于整个行业，描述以下内容：
(1)行业背景和现状
(2)商业价值/市场规模(开辟新市场的情况下)
(3)用户需求
(4)盈利模式
(5)发展趋势
(6)竞争对手发展情况
2. 产品规划
产品规划主要是包括对于产品的定位、产品的核心目标、产品的结构和迭代路线进行一个整体的呈现。这部分内容可以借鉴产品的迭代更新文件(如果有的话)，主要是基于当前产品的规划，描述以下内容：
(1)产品定位
(2)核心目标
(3)产品结构
(4)产品路线
3. 运营规划
完整的运营规划，包括内容运营，用户运营，社区运营，活动运营，产品运营五个方面，但是并不是所有的产品都会占据所有的运营方式，每个产品的运营涉及的部分不一定一样，侧重点也不一样。
(1)内容运营
(2)用户运营
(3)社区运营
(4)活动运营
(5)产品运营
4. 盈利模式
简单的说，就是介绍产品将通过怎样的模式、渠道来获得收益
5. 收益与成本
6. 风险与对策
SWOT分析：优势、劣势、机会、威胁;(SWOT就不多叙述了，网站内有详细的介绍哦)
MRD文档
1、概述:包含两个点，背景和目标。
2、市场概述:描述一下你们要做的是什么市场。
2.1市场特征
从全局说说目前市场个竞品的产品定位。
2.1.1市场问题
列举市场痛点，用户在需求产生后，遇到的各个环节的问题，目前市场是如何满足的，以及那些需求点尚未得到满足?或满足不够有深度挖掘的空间。
2.1.2市场机会
根据市场的问题，分析问题，是否还有机会做这个市场?根据市场凸显的问题，举例出几种解决方案，逐一举例。
2.2市场趋势
可预见的估测评估未来市场的发展，可能会出现那种情况?出现巨头垄断?还是三足鼎立?垂直细分?020线上线下结合等等。
2.3市场细分
举例市场都有哪些细分?和这些细分相对应的产品都有哪些?
2.4市场壁垒
要切入市场，有哪些难题，有什么壁垒?
成熟壁垒。市场已经非常成熟，品牌体验已经深入人心，不细分切入几乎没用胜算。
资金壁垒。市场处于初期红海或者到了火拼时代如以前的百团大战、打车、拼车、外卖市场等。一种就是起动需要大量的资金，如京东的自建物料。
技术壁垒。如人工智能、搜索这些需要高精尖技术人才，才能实现的。
垄断壁垒。例如医疗、电信、支付等，需要国家批准的。
2.5市场紧迫性
基于市场发展的趋势，项目的启动是否需要一些特殊的需求?
3.用户需求分析:详细说明用户需求的动机。
3.1用户类型细分
说明用户群体的细分维度，对用户进行分解，可通过典型用户、类型特征特征等进行描述。不同需求用户，对产品的关注点不同。
3.2用户场景
用户发生需求的场景，和不同场景的特征。比如睡觉时、坐地铁坐公交时、开车时等等。
4、竞品分析
直接竞品
间接竞品
竞品模式分析
PRD文档
一、PRD文档头
文档名称、作者或则撰写人、文档编写日期、版本纪录、目录。
二、PRD文档内容结构
PRD文档内容结构包括：概述、产品需求说明、产品流程说明、产品结构和功能说明、其他产品需求、上线需求说明。如果需要的话有相关文档，附件说明。
1、概述
从大的方向，讲讲项目的相关背景、有什么目标、有没有竞品对像?而阶段性计划是什么?传递做这个需求的目的是什么?要达到什么样的目标?要达到这个目标阶段性计划是什么?
2、产品需求
落到具体的地方，产品有哪些需求?增加了哪些需求?调整了什么?取消了什么?需不需要其他资源的配合?有什么影响?，从这几个地方说清楚。
3、产品流程说明
讲清楚每个逻辑点，每个地方应该怎么走?应该做什么样的判断?如果进行这个操作返回给用户什么内容?用户触发之后得到什么内容?
4、产品结构说明
根据产品的内在逻辑，分解、细化需求，将需求细化说明。
5、其他产品需求
涉及到其他产品的产品线时，需要协同多个产品线进行多方面考虑。协同调整，避免出现遗漏，出现不必要的偏差。
6、相关文档
如果一个项目分解成多个团队。多个需求文档协同合作。如一个UGC社区，有PC端社区，有APP端社区。
7、上线需求
测试通过的需求，具体的上线时间，具体一些特殊的流程需求等。
8、其他需求、附件
作为需求的一种补充，对一些需求进行补充说明，或者需要的文件说明等
欢迎来起点学院学习更多产品文档写作方法