01
什么是PRD文档
PRD是产物由立项阶段进入到需求阶段的最主要的一个文档。
简而言之，PRD就是将宏观抽象化的买卖，拆分成具体化的功能需求，并经由文字或图像等体式呈现出来。
PRD文档首要使用对象有：产物、设计、项目、斥地、测试。产物司理能够凭据PRD进行功能自查，从而加倍完整的梳理产物；设计师能够经由PRD来设计交互细节，并改善用户体验；项目司理能够凭据PRD拆分工作义务，并分派斥地人员；斥地人员能够凭据PRD获知整个产物的逻辑；测试人员能够凭据PRD建用例，并进行可用性测试。
传统的PRD文档冗长而复杂，一方面不轻易产物司理清楚且周全的表达产物设计的相关细节，另一方面不轻易产物司理将需求简洁且清楚地传达给PRD阅读者。
02
PRD文档的目的
PRD文档是产物新人入门的一门必修课，是进入职场的敲门砖，也是产物司理根基功的施展，更是权衡产物司理整体脑筋的一个尺度。
PRD文档是每个产物司理打交道最多的文档。也是项目启动之前，必需要经由项目组评审，并确定最终需求局限的主要文档。
PRD文档在项目立项阶段，可评估产物机会。在需求阶段，可界说产物功能局限。
PRD文档能够梳理产物买卖逻辑，记录需求调换内容，治理产物迭代过程，便于部门需求沟通。PRD文档的利害直接影响到斥地进度、测试质量以及最终的实现结果。
PRD文档是产物司理和斥地人员沟通需求的主要对象，产物司理一样用它做需求治理和版本治理。PRD文档首先应该展示的内容是需求，若是一份PRD文档可以充裕的表达用户需求，那么它就能够作为需求验收的尺度。
03
若何写PRD文档
之前有些想转行和刚入门不久的产物同伙，在产物司理朱学敏公家号留言问我怎么写PRD文档。借着这个机会，给人人分享一下我本身的一点产物经验。
撰写PRD文档的体式有多种，常见的有Word、PPT、Wiki或Axure等，但我小我更倾向于直接在Axure中撰写PRD。此外，描述需求或买卖划定，我偏重于用视化的构造图、流程图和原型透露，文字只是作为增补解说。
PRD文档内容构造包罗：文档概述、产物解说、全局解说、功能需求、非功能需求、改善建议等。基于以上几个方面，从理论角度阐述，连系案例做剖析。
一、文档概述
1.1 修订记录
首要包罗版本、时间、内容、备注等，轻易沟通和记录产物成长路径，为规划将来产物迭代供应参考。以下是PMLink产物迭代的一个简化修订记录。
1.2 项目配景
简洁描述项目的配景、方针、定位和用户等，让成员对项目有整体的认知以及明确偏向。
1.3 阅读对象
文档的首要阅读对象和使用者，一样包罗产物、设计、项目、斥地、测试和甲方负责人。
1.4 专业术语
对文档中会显现一些专业名词做注释，轻易项目成员懂得买卖并统一名称。
二、产物解说
从产物生命周期认识各个阶段的运营运动，好比产物路线图、功能清单、产物构造设计、用例图、买卖流程图、需求列表、产物进度、斥地进度等。
2.1 产物路线图
2.2功能清单
2.3产物构造设计
2.4用例图
2.5买卖流程图
2.6需求列表
2.7产物进度
2.8斥地进度
三、全局解说
对产物设定的一些行为准则，按照既定尺度、规范的要求进行把持。好比页面设计规范、产物状况规范、把持提醒规范、数据加载规范、新闻通知规范等。
3.1 页面设计规范
3.2 产物状况规范
3.3把持提醒规范
3.4数据加载规范
3.5新闻通知规范
四、功能需求
功能需求一样是由四部门构成，功能总览、页面原型、用例描述、买卖划定。首要是对所有的产物功能的描述和规划。其实就是经由场景模拟，敷陈用户此功能首要干什么的，并认识产物在哪种情形下会被用户使用。
4.1 原型页面
常见的原型设计体式有手绘原型、灰模原型、交互原型。产物司理一样是画低保真的手绘原型或灰模原型，而高保真的交互原型更多是让UI去实现，但我们要在软件需求中，解说所有页面的展示及每个功能的状况。
4.2 用例描述
用例描述文档是用文本体式来表述的，为了加倍清楚地描述用例，也能够选择用例图或流程图来辅助解说。
用例名称：该用例的名称；
用例编号：该用例的编号，一样界说到功能Uc级；
把持脚色：介入或执行该用例的用户。
优先级：功能优先级排序；功能方针：功能要实现的预期结果；
前置前提：介入或执行该用例的前提前提，或许所处的状况；后置前提：执行完毕后的究竟或许状况。
4.3 买卖划定
买卖划定是指对买卖界说和约束的描述，用于维持买卖构造或掌握和影响买卖的行为。即敷陈我们此功能在把持时有哪些约束前提。
以PMLink快捷登录为例，会对把持、输入框、内容花样、长度、点亮、控件、数据之间的关系性做出解说。产物在使用时要有响应的买卖划定，且买卖划定必需是完整的、正确的、易懂的。
买卖划定将系统处理的买卖逻辑从法式代码中抽掏出来，将其改变为简洁的买卖划定，以构造化的买卖划定数据来透露买卖行为。如许用户无需找法式员帮助，就能够更改买卖划定。
最典型的就是CRM客户关系治理系统，其复杂且多变的的买卖划定，就需要一套买卖划定引擎的架构设计。
五、非功能需求
非功能性需求是指软件产物为知足用户买卖需求而必需具有且除功能需求以外的特征。一样会涉及到的有：机能需求、平安需求、靠得住性需求、数据监控需求、系统需求、运行情况需求、外部接口需求等。
以机能需求为例，我们会存眷每秒处理的事务,功能把持的响应时间,页面刷新时间。以系统需求为例，我们会存眷办事器保持失败后的重启次数.时间引起失败的比例 失败时数据溃逃的或者性。
六、改善建议
改善建议实际就是基于用户体验区优化产物路径。
网上有太多的PRD文档，能够作为参考，但不是尺度规范。最隐讳的就是把BAT大公司的文档规范尺度，安分守纪的套用过来。要连系公司的实际需求，去撰写适合本身产物团队的PRD文档。
写好PRD不是一蹴而就的，除了根基的专业能力和逻辑脑筋，还得此外，要常收集、常反馈、常总结。
写PRD文档不克为了体面工程或小我绩效，写一堆无关痛痒的废话。如许只会导致需求评审时，产物司理说的天花乱坠，斥地人员看得眼花凌乱。需求最后最后要回来到时效性，在买卖逻辑清楚的前提下，尽量用精简的说话，把需求快速传递给斥地。
一份接地气的PRD文档，必然是遵循整体逻辑清楚，说话简练易懂，信息实时共享，明确功能局限，并快速需求落地的原则。总而言之，PRD文档最主要的就是把需求表述清楚。
