产品经理：如何构建“优秀”的需求文档框架
需求文档/产品文档是每个产品经理的必经之路，优秀的产品文档可以避免部分项目的重复沟通和编写无效代码，提高项目开发效率。
1. 构建需求文档的目的
写需求文档前，首先要确定的是文档的受众群体和时间要求。受众群体（谁去看）确定了文档的框架架构和排版要求；时间要求限制了需求文档的精细度和美观度。
1.1 需求文档的受众群体
一般来说，需求文档有三个受众群体：
- 开发团队：包括产品团队、UI、UX、技术和测试；这也是需求文档最常规的受众群体，毕竟需求文档是要阐述项目要实现的功能和实现的方法、规则；
- 企业内部：如老板、商务团队、运营团队等；通常这部分群体不会在乎产品规则，他们只关心项目实现的功能和效果。
- 其他：例如公司制度要求留档、公司上市审计流程所需。
1.2 时间限制
如果只是开发团队使用的需求文档，框架会比较简单，排版也没有非常严谨的要求，只需要做到逻辑闭环，场景尽善，表达清晰即可。如果是企业内部或其他用途的需求文档（以下简称为商用文档），除了开发用文档的内容外，还需补充项目概述、需求分析等栏目。
在写文档前，产品经理心中必须要有期限和计划，合理安排文档的进度，不能在项目前期就发生延期的情况。
如果时间紧迫，首先要把关键的逻辑写清楚，其他的细节可以在开发时或项目结束后补充，例如搜索功能、填写字段的字符长度、页面确定、关闭和返回等交互。特别是当项目团队已有一定的合作经验，建立了一定的工作默契时，这些细节在时间不允许情况下是可以省略；但是，如果时间充裕或者是新的开发团队，还是建议需求文档尽量精细，需求文档不清不楚，会让设计师与架构师工作难以开展。再者，详细的需求文档，可以大大地减少开发团队的理解误区，一定程度上，既能避免无效设计和无效代码，还能避免产品经理在投入下一个迭代工作时被开发“咨询”过多。
2. 产品需求文档的构成
产品需求文档由开发用文档和商业文档两部分组成，产品需求文档也是对其二者用更加专业的语言进行描述；
2.1 开发用文档
开发用的文档只有一个宗旨：把需求说清楚说明白，大家知道要做什么功能，做到什么程度。
常见的开发用文档主要包括以下内容：版本迭代记录、版本修改记录、流程图、全局说明、正文；
2.1.1 版本迭代记录
主要是记录一个项目各个产品版本的迭代情况，如V1.0，V1.1……V2.0……。这里强调的产品版本，主要是指产品功能的迭代。如果一个迭代只单纯涉及到bug修复、交互优化、性能优化，记不记录都可以，看个人意愿。
需要记录的内容包括：版本号、更新日期（文档定稿日期或者版本上线日期，更建议用版本上线日期）、主责产品经理、迭代的功能简介（从业务场景出发，一句话描述一个功能模块）。
2.1.2 版本修改记录
主要是记录单个版本（划重点）的修改记录。因为每个需求文档都会经历初稿、产品评审、技术评审、开发过程中N次细节调整、终稿这几个过程，需要把每次修改的地方记录下来，特别是当文档已经对项目团队公开后发生的修改。
需要记录的内容包括：更新日期（每次文档修改的日期）、产品经理（不等同该版本的主产品经理，特别是大项目有一个主产品经理，多个初中级产品经理）、修改说明（动了哪些逻辑，哪些页面）。
版本迭代记录是为了给以后的项目团队使用，无论是产品还是开发，方便新成员或项目交接时快速了解项目的前世今生；版本修改记录是给当前的开发团队使用，方便快速了解产品又改了哪些逻辑，增加了哪些需求。
2.1.3 流程图
一般写在文档里的流程图包括两种：业务流程图和逻辑流程图，都是“非必填项”，视实际情况判断是否需要用流程图进行说明。因为在开发用文档内，任何元素都是为了帮助产品经理清晰说明需求，如果业务很简单，能用线框图或者文字即可说明清楚，那么就没必要费力气去弄一个流程图了。
业务流程图：一般单个任务模块从0-1的时候需要使用，帮助开发理解任务的每一个环节，通常会涉及到多个角色协作。
逻辑流程图：单个任务或者单个环节涉及多重逻辑判断时使用，帮助开发梳理if else后的操作行为。
2.1.4 全局说明
在同一个系统内，在多个场景或者页面内需要使用到相同的组件或者交互，把这类组件/交互的需求说明归纳到全局说明内，在正文内出现时做相关引用即可。
【举个例子】
列表的排序规则，如果多个页面的列表排序规则都是一样，则在全局说明内新增一个版块对其进行详细说明，而在正文的相关页面注明“排序规则请参照全局说明XXXX”即可。
又如系统管理后台，编辑页面的保存/取消功能，直接在全局说明内说明，点击保存/取消时会出现XXX提示，确认后系统的执行结果；即使在实际页面中，保存/取消属于不同的内容编辑页面，但其交互几乎都是一致的，就没有必要在多个页面重复说明。如果遇到特例，与全局说明内的需求不一样，在对应的页面再另行说明。
建立全局说明板块，不仅能在写需求文档是节省重复劳动的时间，而且在修改需求文档过程中也能省掉很多繁琐的事，就如Axure中“母版”一样便捷，改一处即把相关的地方都完成修改。
2.1.5 正文
就是每个页面的需求细节，包括线框图/高保真，逻辑说明和交互说明。
关于交互说明，一般大公司才会有专职的交互设计师并撰写交互文档，其他公司通常由产品经理和UI设计师一起承担交互设计。但无论是否有专职的交互设计师，作为一名产品经理，在需求文档内也要明确指出部分交互说明，提供一个大方向给设计师工作，特别是对于系统的空白页或类空白页。
2.2 商用文档
相对于开发用文档，商用文档几乎是面面俱到，尽善尽美，能摆到桌面上的需求文档，以下列出了二者的框架对比：
商用文档一般包括：
封面
每一份商业化文档，都会要求有一个封面，简单罗列系统名称、文档名称、文档设计者（企业或者个人）、定稿时间即可。
目录
目录的粒度，需要细致到哪级标题，按需设置即可。
概述
包括项目背景、项目介绍，用一两段话简要说明。
使用人群
给谁看就列明谁，如系统开发团队，相关行业设计师等。
需求分析
主要写项目前期开展的调研和分析而得出的结论，包括产品定位——项目核心用户群、市场竞争优势，和用户故事——用5W1H方法表明解决的痛点。
系统字典
对系统或者文档内的一些专业用词进行解释，或对同一事物进行命名规范。系统字典不仅是一个项目内使用，甚至每个部门或每间公司都可以用相关概念，特别当团队刚刚组建时，使用系统字典概念能够解决很多沟通上的误会。
3. 结语
优秀的产品需求文档需要多次的修改与完善，同时也需要书写者长年累月工作经验的积累，还有不断的实践，才能真正锻炼出具体问题具体分析的本领，创造出优秀的需求文档。