产品需求文档是产品项目由“观点化”阶段进入到“图纸化”阶段的最紧张的一个文档，其浸染便是“对MRD中的内容进行指标化和技能化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
产品需求文档是产品职员非常核心的基本功！
是折衷研发、测试、UED、业务非常主要的主要工具。但是，每每很多新入行的PM与互联网领域的PM，产出的文档每每不尽人意，紧张表示在：
而涌现这种缘故原由在于：
新人入职，没有经由严谨的文档撰写、流程设计演习；大多数的PM非研发出身，对前后台的业务逻辑、数据构造理解不清晰；分工细，版本迭代迅速，对功能点理解不足透彻；完善的产品需求文档，不但利于PM对所承接的功能进行有效的管控，将业务逻辑梳理清晰，对分解的功能点，进行折衷测试、研发、设计、运营同时开展事情；
模块化的功能点（倒爷当年做的一个功能）
虽然，不同的公司拥有不同的产品需求文档模板！
但，不论模板格式如何，文档的实质在于：“有效的将功能清晰的表达出来，并且能支撑后续的业务交卸与版本迭代参考，对上与下进行代价通报。\公众并且，随着平台业务的发展，归档、仓储起来的业务文档，便是极其有代价的知识库，里面汇总了各个期间里PM、研发、测试、项目经理、设计….对业务是如何进行思考，对文档研究的本身，侧面也反应了企业是如何将计策进行细节落实。
而，“业务描述、功能描述、其它需求”是组成产品需求文档非常主要的模块；本篇章，将以通用版的角度，对这些模块行先容；
二、业务描述
任何的业务或需求，都有业务提出方，业务提出是干系的业务部门或产品经理自身。
业务来源的实质，便是希望通过这个业务办理那些实际的问题，达到提升某些转化率或某些目的；业务描述清晰的表达出来即可，不须要多繁芜，但常规包括：
业务背景产品功能概述产品前景剖析产品功能整体流程产品逻辑关系面向工具运用工具名词阐明参考文档上述的这些层面，以通用版的角度，将产品的代价通报给研发方与业务方，实现之间有效的衔接。
为什么，我们须要进行业务、功能、概述这些偏宏不雅观不实际的描述呢？这样不是很麻烦，且摧残浪费蹂躏韶光？
我们要知道，每新增或删除一个功能，狭义来看也没啥大不了。但站在宏不雅观的角度去看，功能研发是须要耗资企业运营本钱。如果处理不完善，摧残浪费蹂躏运营本钱同时，乃至影响全体用户体验与开拓规则。
身为产品职员在未传达产品的业务代价条件条件下，便强势驱动研发职员进入开拓阶段，这是缺点的！
我假如研发，我也会拍去世这位PM。那么业务描述的实质便很清晰了，便将业务代价，通报给团队成员。
另一方面，非常多的企业，内部的项目流程是不完善的，且并非每一位研发职员都是善类。产品经理每每须要兼备着项目经理的职责，推动着项目实现研发上线。在这种情形下，如果业务代价描述不清晰，功能在开拓与上线后涌现问题，这个锅注定是要背的。
BTW，这些我就不都说了，自己事情中逐步积累！
下面，我对组成业务描述的组成元素进行描述：
业务背景描述：
这里，你必须将业务提出方描写出来，并且细致到业务方为什么将这个需求提出来！
为什么？一方面，你要见告研发职员，你为什么设计这个产品或功能，这个需求从来源到设计是有缘故原由的。另一方面，拉上干系业务部门，你至少不是一个人在战斗。
产品功能描述：
对当前功能进行概述，所设计的产品或功能的功能模块，新增、完善、优化那些产品功能；
产品前景描述：
本产品或功能，希望对那些转化率指标或实现那些目的；
产品的整体流程：
Visio、Axure（Axure画的流程图好丑）。
通过而言，大略的需求将主业务流与逻辑关系流表达出来便可以；但涉及繁芜的业务，便将产品或功能涉及的紧张流程绘制出来；而流程目的，紧张是清晰的将前后台的逻辑关系与数据构造表达出来；一方面方便开拓理解业务与数据流，另一方面也方便产品职员梳理自身需求的业务逻辑；利于后续与研发进行沟通。
详细的流程数量，根据业务的繁芜程度决定，一样平常只须要将核心的流程绘制出来便可；
前台：紧张是交互、数据流程；后台：紧张是业务逻辑判断、数据流；前后台的流程凑在一起，能清晰的看到前后台的模块之间，是如何进行耦合的，数据储存、提取、处理、剖析。
功能框架：
Mindjet Minmanager、Xmind画的框架图好丑。
框架图的意义在于，能让查看或理解业务的人，全方位的理解功能之间的功能点的逻辑关系。同时，一份精良的框架图，能让PM站在全局的基本面上，对个人所卖力的产品进行全局的方案，对前后台的功能进行把握，达到支撑平台业务。
产品架构：对前后台的各个别系与管理模块的逻辑关系，一样平常是对业务极其熟习的业务构架师与资深的产品总监搭建，里面涉及每个接口如何进行对接耦合。功能架构：所卖力的产品或功能的前后台功能的逻辑关系，大略点的便是一个产品或功能的前后台，大一点便是一个别系涉及的功能点之间的耦合。功能框架：功能点所涉及的逻辑关系。功能构造：功能点所涉及的逻辑关系。而“架构、框架、构造”区分在于，所卖力的业务究竟有多大。但不论如何，它们的表现的事理是同等的。将分解的功能点，之间是如何联系的功能构造关系清晰、简练的表达即可。
关于架构，包含“功能分解、面向用户”就够用了。若再深入，可将分为：“运用工具、BI剖析（BI需求也写上去）、系统集成….”。后续可根据BI数据，对产品进行版本迭代与优化。
面向工具
表达产品或功能紧张是为那类用户做事的。将面向用户是谁，拥有哪些权限清晰的表达出来即可，对个人进行功能设计也有很大的帮助。
运用工具
本功能须要在那些运用端或版本进行上线，清晰的描述出来，方便后续进行业务交卸。
名词阐明
将本次文档涉及一些奇葩的明词进行阐明，这点很主要！
有些PM喜好将一些非常大略的内容包装成非常牛逼，让人看起来很难懂，而事实上也就做哪些一件大略事，但是看的人会很痛楚：看PRD时会想：“这玩意，究竟想表达什么。
参考文档
将所做的本次功能，所参考的那些文档，附属上来；目的的在于，方便后续的业务方、研发方进行查看。
三、功能描述
功能描述能否描写清晰，描写清晰，开拓找茬都不怕了。如何才能完全的对功能点进行描述呢？环绕三个点“功能是谁？功能来自哪里？功能要到哪里去？
同时，功能需求紧张分为核心功能、其它功能。不论是核心功能还是其它功能，都可以由以下元素构成：
功能名称面向用户用例图（Axure、mocking（适宜移动端进行敏捷性开拓）)前置条件后置条件功能简述详情描述而详细的功能描述内容，则根据业务（功能点）的繁芜程度，进行筛选描写。可以全写，也可以不全写。但务必记住：不论何种办法，目的在于将业务代价完全、清晰、有条理的通报给查看文档的参与角色。
功能名称（我是谁）
本功能在系统里的命名。
面向用户
本功能的利用工具。（在前台，功能的参与者是少数的；但后台与企业级运用里，功能的参与者是多个的）
用例图
表达功能在表现层的逻辑图；可以是传统意义上的用例图，或者是简化版的原型图、流程图；
前置条件（我来自哪里）
利用该功能的条件、逻辑关系解释；公司大了后，每个开拓都只写个人所卖力的业务，以是一定要将每个模块来源都清清楚楚的表达出来，方便开拓之间的衔接。
后置条件（我要到那里去）
利用该功能后，对业务、数据功能，产生的影响与结果；
功能简述
描写本功能须要实现的商业代价或目的；
详情描述
将功能”我怎么来，我怎么去“清清楚楚的表达出来。变成打算机逻辑便是，页面布局、操作逻辑进行详细的解释。常规而言：
前台：紧张是字段、交互逻辑组成；后台：紧张是判断逻辑、列表表单、查询条件、交互逻辑组成；四、其它功能其它功能目的在于，功能描述针对付本次产品功能的核心业务，而其它功能针对付触发或须要其它功能变动的业务。功能描述清晰的让开发理解核心，而其它功能便让开发清晰的理解非核心。
而其它功能，紧张由以下内容组成
其他接口
对其它系统产生“字段、业务流程”进行解释；本次产品或业务，对前后台那些非主流程模块产生影响；
系统风险评估
当前设计的功能存在哪些毛病、把稳事变与后期的功能拓展如何办理这些问题；
其它需求
对一些非核心的功能点进行详情描述。如：一些需过滤的关键字、新增某个栏目字段。
五、综述
通过上述内容，能以通用版的形式，清晰的将所卖力产品与功能表达出来，而业务描述、功能描述、其它功能。是产品需求文档主要的组成部份，将产品需求较为全面、有效的描述出来。
同时，能演习PM逻辑思维，提升笔墨表达能力、业务理解能力，从整体上让PM在需求管理上，明显更加专业，所卖力功能的逻辑关系、数据流的来与去都能很好的把控。
六、附语
不论是什么格式，倒爷坚持一个不雅观点，适宜团队才是好的模板。当前很多的公司在进行MVP迭代的时候会利用Axure+内容描述的形式。虽然，这种形式，是很难将逻辑关系表达清晰，同时会有非常多的思维漏洞。在进行文档归档时，也很难对根据关键字进行检索。但，确实挺适宜进行MVP迭代，涌现问题修正起来也方便，这种办法比较适宜项目流程完善的企业平台利用。
而在敏捷性开拓汇总，倒爷习气流程图+功能框架（功能点）+Axure（原型图绘制），从核心的业务流开始，逐渐迭代至功能完善，这个过程也将文档补齐。
但有些公司会在EXCEL里进行需求文档撰写，进行版本管理（这个也不错）。
但，作为新人，须要记住：你能写繁芜的东西，大略的东西也能能写；但当然一开始只写大略的东西，那你一辈子只能做大略的东西。
大道至简，简难而繁易；经历过繁芜的演习与哀求，才能简化再简化。
作者：倒爷，微信：ftl_keen。
本文由 @倒爷 原创发布于大家都是产品经理。未经容许，禁止转载。
