声明：，，，。概况

　　产品需求文档是将商业需求文档（BRD）和商场需求文档（MRD）用愈加专业的言语进行描绘

　　该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最首要的一个文档。当然，这个界说针对的是一个全新的产品。广义上来讲，产品需求的描绘，应该包含有产品的战略和战术，战略是指：产品定位、方针商场、方针用户、竞争对手等。战术是指产品的结构、中心事务流程、详细用例描绘、功用&内容描绘等。

　　PRD的首要运用方针有：开发、测验、项目司理交互规划师、运营及其他事务人员。开发能够依据PRD获悉整个产品的逻辑；测验能够依据PRD建用例；项目司理能够依据PRD拆分工作包，并分配开发人员；交互规划师能够经过PRD来规划交互细节。PRD是项目发动之前，必需求经过评定确认的最重要文档。

　　文档的编号和命名很要害，每个产品都是经过若干个迭代才完结的，而每个迭代所完结的产品功用或许晋级的需求都或许是不一样的，因而需求界说清楚该文件归于产品的哪个迭代，修正了几个版别。文件命名的办法一般是经过版别号界说，比方简略的办法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后边的V2 PRD的版别号。略微详细点能够界说成，XX产品XXXX需求PRD_V2,即对本次迭代的需求使命做命名，这样更便于阅览和回忆。

　　包含，编号、文档版别、章节、修正原因、日期、修正人。编号仅仅为了记载修正的次序，文档版别显现的当时修正的内容归于文档的第几个版别(或第几次修正，一次修正一般为一个版别)，章节是详细到修正内容迎誉只归于的功用模块，以便阅览人及时找到修正后的内容，修正原因阐明为什么要修正该需求，让阅览者直观的了解原因。日期是指需求文档修正的时刻，修正人是指需求内容的修正者。

　　不需求自己新建，文档完结后直接更新模版中的目录即可。目录是用来了解文档结构的

　　这部分的内容有：产品概述及糠臭微方针、产品roadmap、预期读者、成功的界说规范和判别、参考资料、名词阐明。

　　产品roadmap：为产品规划的蓝图，每个要害阶段完结的中心使命。产品研制是个不断迭代的进程，需求经过若干个版其他迭代，，对一个功用点做了N个迭代后终究又回归到了第一个迭代是很常见。产品司理需求做好心理准备。产品roadmap并不需求悉数规划好一切的阶段方针，可是对产品未来开展趋势的一种预估，要到达方针，需求更多的更新和迭代。明晰的呈现产品的roadmap能够协助产品司理掌握产品的全貌，更好的操控研制进程。

　　名词阐明：称号、阐明。称号便是对文档中会呈现的比较新的称号，阐明则是对这些称号进行解说。

　　需求概述一般包含需求概览、用户类与特征、运转环境、规划和完结上的约束、项目计划、产品危险等等。

　　需求概览：分两部分，一是事务流程图，对产品整个事务流程的发生进程做图形化的展现，是对产品全体功用流程的阐释。二是需求清单，对本非有必要开发的需求使命做分类，给出短小精悍的需求描绘并标示优先级。

　　用户类与特征：产品的终究用户，确认产品的终究运用者，并对运用者的人物和操作行为做出阐明。

　　运转环境：该产品上线后的运用环境，比方支撑的浏览器及其版别，操作体系、数据库的要求等等，测验人员在看到环境要求后会在测验时要点乌夜去测验，而终究上线产品时需求把最佳的运营环境奉告给用户。规划和完结上的约束：比方控件的开发环境、接口的调用办法等等。

　　项目计划：关于prd中要开发的内容，给出要害里程碑，比她邀如需求评定经过的时刻、开发的完结时刻、上线时刻等等。

　　产品危险：描绘产品或许存在的危险，比方功用瓶颈，没有解巩乃拔辩决的问题，用户不妥运用的危险等等。

　　功用需求一般是由功用概况和干流程阐明两大部分。功用概况是一切的产品功用的描绘和规划。功用概况包含以下内容：

　　场景描绘，产品在哪种状况下会被用户运用，便是用户场景模仿。这也是产品司理讲“好”故事的必备条件。

　　事务规矩：每上产品在开发时都有相应的事务规矩，将这些规矩明晰的描绘出来，让开发、测验人员能够直观的阀拘酷归了解该规矩，且没有发生歧义。事务规矩必需是完好的、精确的、易懂的。事务规矩的描绘上假如涉及到页面交互或许页面的修正，主张给出页面的草图或许页面截图在图上阐明要修正的内容。其他也主张对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出阐明，什么时候可见，不行见，灰掉或点亮的条件在文档中都给出阐明。便利阅览者了解事务规矩。

　　界面原型：如前所述，涉及到页面交互的部分，产品司理需求规划页面原型。原型规划一般需求产品司理和UI规划师一起来完结。主张的做法是，产品司理可规划一个页面结构，将该页面要呈现的字段及其特征以及页面要运用的场景向交互规划师解说清楚。之后交互和视觉规划师完结产品的原型规划。

　　前置条件：该需求完结依靠的前提条件。比方，上传照片时，需求存有图像文件。

　　干流程：把干流放在最终是有道理的，结合上面所说的，做出干流程阐明，对每个功用流程走向分点阐明(这是十分重要的)。

　　看过许多的PRD，文档中对既没有前提条件，也没有后置条件，只对干流程做了阐明，可是在描绘干流程时却没有描绘干流程中每个功用流程的各种走向，只要一个主走向，让人感觉prd成了操作手册。事实上，对分支的介绍是十分重要的，开发和测验中提出的各类问题均与对分支的界说不明有关。一个合格的PRD不只要描绘干流程，一起对分支流程所呈现的各类问题都要做详细论述并给出处理办法。PRD的特征必定是明晰的、全面的论述需求及各类异常状况的处理而不是比及开发和测验阶段发现问题后再处以答案(尽管PRD不或许百分之百的掩盖一切的或许，可是最大化的考虑一切的事务问题是编制PRD时有必要恪守的准则)。其他，在描绘功用需求时给出的办法中不能呈现“或许”、“或许”等词，必定是明晰的，精确的描绘。假如有其他计划，主张写入“可选计划”，在产品构建的前期可选计划可认为功用完结供给更多的挑选，当计划确认后可在文档中注明本次运用了哪种计划。

　　引荐一个办法：“用例”，在面向方针的软件规划模型中，用例是一个被论述的内容，用例是对功用运用场景的解说。用例很条理的介绍了每个功用的前置、后置条件，干流程介绍，协助开发、测验等人物快速的了解产品功用。

　　经过这一点上能看出产品司理有必要是个全才，不只要具有职业常识，还需求有财政常识。一个产品的本钱衡量一般包含三个方面：效益猜测、产品技能本钱和其他本钱开销。

　　效益猜测是指所供给的功用在未来能发生的效益，可经过比照以往的产品或许竞争对手的产品来做预估，效益猜测的方针，如每个功用点的潜在用户数、运用频率，吸引到的新的用户特征及数量。产品技能本钱是指研制规划以及上线后的运营需求的资源需求，包含人力，软硬件(带宽、服务器、机房)开销。当有项目司理时能够由项目司理来和谐这部分需求，假如没有项目司理，产品司理得挑头了，招集开发司理去找运维等部分执行此事。其他的本钱还包含支撑本钱，比方上线后的运营资源投入、商场推行投入以及客服服务投入等。

　　此处主张产品司理们都去学习一门课《非财政人员的财政办理》体会下财政的进程办理，假如能亲历沙盘练习，记载财政明细账目，核算资产负债、现金流量、利润率的核算，对本钱和利益的核算十分有协助，并且财政上要求的一丝不苟、精雕细镂也是每个产品司理需求长时刻坚持和恪守的。

　　产品整合才能是产品司理很重要的一个才能，事务协作一般是不行防止的，将隶归于两个不同来历的事务功用做整合也是常见需求，比方体系登陆运用公司的域用户登陆，或许付款运用财付通、支付宝付款，处理好整合需求也是体现产品司理中心竞争力的一大重要体现

　　许多产品在正式上线前都有BETA版别或许内测版别，或许叫灰度版别，意图是在测验产品的一些中心功用或许功用。这部分内容不是有必要的，但假如需求，需求给出在此阶段要完结的方针或测验、衡量规范。

　　一般状况下非功用性需求包含以下几个部分：产品营销需求、运营需求、财政需求、法务需求、运用协助、问题反应等。这些信息构成了产品上线的完好内容，也很好的体现了产品司理的归纳本质。

　　产品上线后怎么运营，方针受众是什么，主张的推行战略、问题反应途径、危险监控、亮点宣扬等等，以及与运营人员的协作办法。作为产品的规划人员不是开发完产品就能画句号的，让产品用起来、用得好，有口碑更为重要，所以十分主张运营计划的拟定上有产品规划人员的参加。

　　再次，说下需求改变，需求不是原封不动的，在产品研制进程中需求改变是正常的，产品团队成员需正确的看待需求改变，并要操控好改变。这儿的主张是在做需求剖析时，尽或许把每个问题都考虑透彻，提早做好需求改变的预估及应对计划，必要的状况下和团队成员提早交流存在改变的内容。

　　在与团队交流改变时，需求以一种敞开的心态，从团队成员的视点、产品未来的开展趋势、商场格式的改变正确的提出改变需求，始终保持产品方向的正确和团队成员方针的共同。

　　该文档在产品项目中是一个“承上启下”的效果，“向上”是对MRD内容的承继和开展，“向下”是要把MRD中的内容技能化，向研制部分阐明产品的功用和功用方针。

　　在该文档中，基点依然是MRD中的内容，仅仅把重心放在了“产品需求”上，而产品需求自身是在MRD中有所体现的，差异便是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的阐明。

　　这部分是PD写得最多的内容，也便是传统意义上的需求剖析，咱们这儿首要指UC（use case）文档。首要内容有，功用运用的详细描绘（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描绘、流程/子流程/分支流程，等几大块），Visio做的功用点事务流程，界面的阐明，demo等。Demo方面，或许用dreamweaver、ps乃至画图板简略画一下，有时候也会有UI/UE支撑，出高保真的demo，开发将来能够直接用的那种。

　　该文档中，偏重的是对产品产品功用和功用（即“产品需求”）的阐明，相关于MRD中的相同内容，要愈加详细，并进行量化。在一些国外的公司，是答应把MRD和PRD合并成一个文档的，一般叫做“Marketing & Product Requirements Document”。

　　在写PRD文档之前，咱们需求先罗列出产品功用的信息内容，这一步是将主意逐步明晰的第一步，也是协助咱们接下来规划功用的辅佐信息，一起也能够辅佐服务端技能人员创立数据库。由于这是第一步，所以咱们不需求罗列的很详细，在之后的过程里，咱们会逐步改善和完善信息内容。

　　例如一篇文章的信息内容首要有：文章标题、文章正文、文章作者、发布时刻、所属分类。初始的功用需求只要这些信息内容，可是在之后的功用规划中逐步愈加详尽的考虑时，或许会添加或许删减，因而第一步咱们不必故意的寻求信息的全面。

　　罗列信息内容的办法有许多种，文本方法、思想导图方法等等都能够，最首要的是能够明晰易懂，我最常用的办法便是思想导图，因而我称这一步为信息结构图。

　　当咱们对产品的信息结构了解后，咱们就需求规整脑海中的产品需求，让主意愈加结构化，因而这一步是整理产品的需求。咱们首要要罗列出产品的频道及页面(产品结构图)，其次再根据产品结构图整理出频道及页面中的功用，并延伸构建出用户的操作流程(用户流程图)。

　　以上两步是为了让咱们在编撰产品需求文档之前能够对产品有一个全面的了解，类似俯瞰式的一望而知，也便利调整完善。

　　当咱们逐步明晰了产品的需求后，并整理了产品的各个频道及页面，那么这一步就要开端验证这些主意的详细界面体现和计划的可行性了。

　　首要我主张经过手绘的方法快速在草纸上制造出产品的原型，推演和评论计划的可行性，当有必定的发展之后，咱们再经过软件东西进行更深化的规划。移动产品能够考虑灰模原型，网站产品能够考虑交互原型，关于这两种原型办法，不管是移动产品仍是网站产品都能够运用，详细取得于你的个人习气和团队要求。

　　关于产品司理来说，原型规划是为了协助咱们详尽的考虑计划，并证明计划的可行性，一起也是为了防止产品宣讲时，笼统的言语描绘导致听众了解困难和了解误差。

　　当咱们经过以上三个大的过程之后，咱们就现已十分明晰产品的需求了，一般状况下，经过原型加描绘的办法就现已完结了PRD文档的意图(许多产品司理直接运用Axure制造PRD)。

　　当然也会有一些个人或团队的要求不一样，对PRD文档有特定的规范规范，这类状况或许是需求存档归类。不管什么样的规范规范，PRD文档的意图都是附近的，因而功用描绘的办法也是类似的，所以在这儿我共享了三种编撰PRD文档的办法。

　　《产品需求文档(PRD)的写作办法》的弥补文章，首要解说PRD文档中的重要辅佐文档“用例文档”。