产品文档一优秀的文档框架

　　需求文档产品文档是每个产品经理的必经之路，优秀的产品文档可以避免部分项目的重复沟通和编写无效代码，提高项目开发效率。
　　这里是不是少了功能按钮？这段话是什么意思？不行呀！你的文档需要补充，不然怎么测试？口头的需求文档不算数，开发要见文字版文档。
　　关于产品文档，我们总会遇到这样的对话。那么如何避免呢，下文将仔细说到。
　　本文献给01岁的产品经理，从需求文档的目的、与用户手册的区别、需求文档的构成的维度对需求文档进行整体介绍，希望各位PM都可以输出高效精简、清晰明了的文档。
　　一、目的
　　写需求文档前，首先要确定的是文档的受众群体和时间要求。受众群体（谁去看）确定了文档的框架架构和排版要求；时间要求限制了需求文档的精细度和美观度。
　　1。1受众群体
　　一般来说，需求文档有三个受众群体：
　　（1）开发团队：包括产品团队、UI、UX、技术和测试；这也是最常规的受众群体，毕竟需求文档是要阐述项目要实现的功能和实现的方法、规则。
　　（2）企业内部：如老板、商务团队、运营团队等；通常这部分群体不会在乎产品规则，他们只关心项目实现的功能和效果。
　　（3）其他：例如公司制度要求留档、公司上市审计流程所需。我还见识过另一种过程：面试。如果在面试时提交的作品是需求文档，那么请看商用文档部分。
　　1。2时间限制
　　如果只是开发团队使用的需求文档（以下简称开发用文档），框架会比较简单，排版也没有非常严谨的要求，只需要做到逻辑闭环，场景尽善，表达清晰即可。如果是企业内部或其他用途的需求文档（以下简称为商用文档），除了开发用文档的内容外，还需补充项目概述、需求分析等栏目，这部分将在下文商用文档再详细解释。
　　在写文档前，PM心中必须要有期限和计划，合理安排文档的进度，不能在项目前期就发生延期的情况。
　　如果时间紧迫，首先要把关键的逻辑写清楚，其他的细节可以在开发时或项目结束后补充，例如搜索功能、填写字段的字符长度、页面确定、关闭和返回等交互。特别是当项目团队已有一定的合作经验，建立了一定的工作默契时，这些细节在时间不允许情况下是可以省略，毕竟PM也有很多更值得做的事情。
　　但是，如果时间充裕或者是新的开发团队，个人还是建议需求文档尽量精细，毕竟见过很多设计师、开发和测试吐槽需求文档不清不楚，工作难以开展。再者，详细的需求文档，可以大大地减少开发团队的理解误区，一定程度上，既能避免无效设计和无效代码，还能避免产品经理在投入下一个迭代工作时被开发咨询过多。
　　二、题外话：使用手册
　　有些1到0。5岁的产品不是很清楚需求文档和用户手册的区别。我曾经让0岁的助理写2B项目的用户手册，由于时间紧迫，加上他对项目还不算熟悉，我就把需求文档的原文件发给了他，希望起帮助作用，结果最后交过来的作业却是一个简化版的需求文档。
　　需求文档描述的是项目的功能和产品逻辑、规则，偏向逻辑描述；而用户手册是描述项目的功能和使用流程，偏向操作流程说明。两者间都需要告诉各自的读者，功能是什么、有什么用；但出于目的不同，所以主题内容和详细程度也会不一样。看看家里的电器使用说明书，就知道怎么写使用手册了。
　　三、PRD的构成
　　前文提及，因受众群体不一样，PRD可分为开发用文档和商用文档，除了在排版、美观等有区别外，在内容上也有一定的区别。文终将会放上这两个类型的文档作为样例给各位读者参考。
　　3。1开发用文档
　　开发用的文档只有一个宗旨：把需求说清楚说明白，大家知道要做什么功能，做到什么程度。
　　我个人也是写开发用文档比较多，慢慢形成了自己的框架规范。以后随着经验的积累，也会继续优化这套方法论。
　　版本迭代记录
　　主要是记录一个项目各个产品版本的迭代情况，如V1。0，V1。1V2。0。这里强调的产品版本，主要是指产品功能的迭代。如果一个迭代只单纯涉及到bug修复、交互优化、性能优化，记不记录都可以，看个人意愿。
　　需要记录的内容包括：版本号、更新日期（文档定稿日期或者版本上线日期，个人更建议用版本上线日期）、主责产品经理、迭代的功能简介（从业务场景出发，一句话描述一个功能模块）。
　　版本修改记录
　　主要是记录单个版本（划重点）的修改记录。因为每个需求文档都会经历初稿、产品评审、技术评审、开发过程中N次细节调整、终稿这几个过程，需要把每次修改的地方记录下来，特别是当文档已经对项目团队公开后发生的修改。
　　需要记录的内容包括：更新日期（每次文档修改的日期）、产品经理（不等同该版本的主产品经理，特别是大项目有一个主产品经理，多个初中级产品经理）、修改说明（动了哪些逻辑，哪些页面）。
　　版本迭代记录是为了给以后的项目团队使用，无论是产品还是开发，方便新成员或项目交接时快速了解项目的前世今生；版本修改记录是给当前的开发团队使用，方便快速了解产品又改了哪些逻辑，增加了哪些需求（温馨提示：投入开发后真不要轻易加需求）。
　　流程图
　　一般写在文档里的流程图包括两种：业务流程图和逻辑流程图，都是非必填项，视实际情况判断是否需要用流程图进行说明。因为在开发用文档内，任何元素都是为了帮助产品经理清晰说明需求，如果业务很简单，能用线框图或者文字即可说明清楚，那么就没必要费力气去弄一个流程图了。
　　业务流程图：一般单个任务模块从01的时候需要使用，帮助开发理解任务的每一个环节。通常会涉及到多个角色协作。例子见文末开发用需求文档。
　　逻辑流程图：单个任务或者单个环节涉及多重逻辑判断时使用，帮助开发梳理ifelse后的操作行为。如果单纯用文字描述这种逻辑判断，开发还没绕晕，产品自己可能就先绕晕了。
　　全局说明
　　在同一个系统内，在多个场景或者页面内需要使用到相同的组件或者交互，把这类组件交互的需求说明归纳到全局说明内，在正文内出现时做相关引用即可。
　　【举个例子】
　　列表的排序规则，如果多个页面的列表排序规则都是一样，则在全局说明内新增一个版块对其进行详细说明，而在正文的相关页面注明排序规则请参照全局说明XXXX即可。
　　又如系统管理后台，编辑页面的保存取消功能，直接在全局说明内说明，点击保存取消时会出现XXX提示，确认后系统的执行结果；即使在实际页面中，保存取消属于不同的内容编辑页面，但其交互几乎都是一致的，就没有必要在多个页面重复说明。如果遇到特例，与全局说明内的需求不一样，在对应的页面再另行说明。
　　建立全局说明板块，不仅能在写需求文档是节省重复劳动的时间，而且在修改需求文档过程中也能省掉很多繁琐的事，就如Axure中母版一样便捷，改一处即把相关的地方都完成修改。
　　正文
　　就是每个页面的需求细节，包括线框图高保真，逻辑说明和交互说明。
　　关于交互说明，一般大公司才会有专职的交互设计师并撰写交互文档，其他公司通常由产品经理和UI设计师一起承担交互设计。但无论是否有专职的交互设计师，我认为作为一名产品经理，在需求文档内也要明确指出部分交互说明，提供一个大方向给设计师工作，特别是对于系统的空白页或类空白页。
　　【举个例子】
　　前段时间在处理一个小功能：在非电话客服工作时间内，用户点击电话客服按钮时，需弹出提示并引导用户在线留言。
　　以下是第一版和第二版设计的效果：最终使用的是第二版。
　　由于当时需求内没有详细说明交互意图，UI设计师被线框图误导，出了第一版本；我看了设计后不太满意，与UI设计师沟通想法后，最终修改为第二版并投入开发。
　　两个版本的信息内容是一样的，但由于信息侧重点相反，因此这两个提示的功能也不一致。第一版侧重于告诉用户当前客服不在线；第二版侧重于引导用户在线留言。产品是要为用户提供解决方案，而不是把问题抛回给用户。
　　3。2商用文档
　　相对于开发用文档，商用文档几乎是面面俱到，尽善尽美，能摆到桌面上的需求文档，以下列出了二者的框架对比。
　　写商用文档无形中也会给产品经理增加非常大的工作量，因此可按公司要求和个人习惯结合去选择即可。
　　封面
　　每一份商业化文档，都会要求有一个封面，简单罗列系统名称、文档名称、文档设计者（企业或者个人）、定稿时间即可。
　　目录
　　目录的粒度，需要细致到哪级标题，按需设置即可。
　　概述
　　包括项目背景、项目介绍，用一两段话简要说明。
　　使用人群
　　给谁看就列明谁，如系统开发团队，相关行业设计师等。
　　需求分析
　　主要写项目前期开展的调研和分析而得出的结论，包括产品定位项目核心用户群、市场竞争优势，和用户故事用5W1H方法表明解决的痛点。
　　系统字典
　　对系统或者文档内的一些专业用词进行解释，或对同一事物进行命名规范。系统字典不仅是一个项目内使用，甚至每个部门或每间公司都可以用相关概念，特别当团队刚刚组建时，使用系统字典概念能够解决很多沟通上的误会。
　　【举个例子】
　　就如上文的全局说明，这里用全局代指整个系统的概念。但实际，更多的公司团队用全域来指代整个系统。但由于公司是旅游行业，全域一词是行业内的专有术语，并且也是公司的业务术语，如果用全域来表示整个系统，在沟通时常常会引起误解，因此公司内部都习惯使用全局来指代整个项目系统。
　　结语
　　以上便是从大框架层面介绍优秀的产品文档需要涵盖的内容，后续将在系列（二）中，从需求文档正文的角度介绍本人写产品文档的小技巧和tips。整个系列均属作者本人的见解，欢迎交流。
　　另附样例作为参考：
　　开发用文档：https：h82yzy。axshare。comg1amp；amp；pE78988E69CACE8AEB0E5BD95
　　商用文档：（提取码：rqff）
　　https：pan。baidu。coms12qjRKPzqpQgt2R0MJ2A