产品经理在工作时，所必须要必备的技能之一——文档撰写能力，要如何整理出一份完整的产品文档呢？下面这篇是笔者分享的关于此的内容，大家一起往下看看。

一、撰写有根有据的产品文档

文档撰写能力是产品经理必须具备的最基本的能力之一。在工作中，产品要输出各种类型的文档，如BRD商业需求文档，MRD市场需求文档，PRD产品需求文档，产品体验/分析文档跟竞品分析分档等等。写作的本质是要把自己的思路，想法，IDEA形成文字，以文字的方式表达出来，然后让阅读对象阅读并理解文档里面的内容。这才是一个文档的完整过程。所以如何才能出一份，合格，优良的产品文档呢？

写文档也是有一定的技巧，套路，除了公司发你那一个标准的模板，本人总结了以下3步曲：

1. 确定范围

当要写一个产品文档之前，首先要定好文档的范围，通常要明确以下几点：

1. 文档标题：要定位清晰，内容明确，还要加上迭代的版本号
2. 文档目的：用清晰简洁的语言描述文档的目的跟用途
3. 文档归属，阅读对象
4. 创建时间/更新时间
5. 其它补充

2. 选模板

除了上面提到的文档类型，还有用户调研报告，行业分析报告等等，公司的模板不一定能很好的表达自己的IDEA，可以选择合适自己的模板，最好是在自己的日常工作中做好积累。

3. 守规范

规划化是产品经理在职业成长过程中需要具备的一项基本职业素养。小到文档撰写，原型设计的规范，大到用户调研，需求分析以及产品设计，都有一定的规定可以遵循，这样往往能事半功倍。

4. 命名规范

例如：SCRM系统产品需求文档V10.0，这样通用标准的格式来命名，就可以准确的表达文档的定位和类型。也不容易引起歧义。

5. 表达规范

要注意文字表达的规范，尽量结构化的语言阐述，用行业术语表达，而不是口语化，随意的想到什么就说什么，这样会表现得很不专业，很业余，没有意思做产品应有的严谨与专业精神。

6. 版本迭代的规范

文档不单单是写给自己，领导看的，还会写给开发、测试、运营等整条产品线，做好迭代的规范才会减少沟通的误会，引起不必要的内耗，也是对其他同事的尊重。

二、绘制思维清晰的流程图

画得好的流程图，可以很好的体现业务逻辑和产品逻辑；相反，画歪了，就是无形中增加团队的理解成本跟内耗，还会影响产品的个人形象，对于下一次的产品评审沟通等都会起到减分作用。

当面对复杂的业务流程和流转逻辑时，语言描述和文字描述，往往没有流程图表达的清晰和简洁，一张清晰简明的流程图不仅能更好的描述业务逻辑，还能查漏补缺。避免功能流程上、逻辑上出现遗漏，确保流程的完整性。流程图在沟通的过程中思路更加清晰，逻辑更加清楚，有助于程序逻辑的实现和有效解决实际问题。

1. 按表达的主体划分

1. 业务流程图：描述的主体是业务逻辑。
2. 数据流程图：描述的主体是数据流。
3. 程序流程图：描述的主体是软件程序的操作流程。
4. 系统流程图： 同时体现系统的操作流程和数据流。

2. 按表现形式划分

• 一般流程图：不区分角色在其中的穿插，只关注业务、功能本身的闭环。
• 泳道流程图：业务、功能在多个角色之前穿插交互、流转。

3. 按复杂程度划分

• 基本流程图：只描述流程的关键节点，忽略细节阐述。
• 完整流程图：详细的画出整体流程的每一个环节。

三、绘制产品原型图

原型设计在整个产品方案的输出流程中处于很重要的位置，有这承上启下的作用。进行原型设计之前，需求描述相对比较抽象，原型设计的过程就是将抽象的需求描述转化成为具象的产品方案的过程，之后再配合PRD和流程图对原型图中的功能逻辑、交互逻辑及视觉逻辑进行描述和说明。

原型图的最大优点在于，它可以有效的避免重要的元素被忽略，将需求逻辑可视化，促进整个团队间的理解。

四、功能结构图、信息架构图、产品结构图

对比各种产品输出物（文档、原型、流程图）可以看出，产品结构图的形式最简单，其实也就是一个思维导图，简称脑图，但其复杂程度，涉及的范围，抽象程度都是最高的，对产品整体的把握能力，思维能力也是最高的。

在进行产品设计时，首先应该产出的是产品结构图，思考这张图如何画的过程，就是帮助你梳理产品设计思路以及确定产品形态的过程。

其次，产品上线之后，无论是进行内部的宣讲还是对外的推广，都需要使用高度抽象，简洁易懂的载体来介绍产品的整个情况，推广信息不可能用繁杂的页面和文字去描述，因此，产品结构图就是介绍整个产品的理念，功能和设计的最好媒介。

常见的产品结构图有功能结构图，信息架构图，产品结构图，业务架构图，混合结构图等等。

主要有以下4个步骤：

1. 确定对象：确定业务对象。
2. 拆解架构：化整为零，拆分各个功能。
3. 挖掘关系：理清个功能之间的干系，并列，父子，支撑，辅助等等。
4. 输出表达：逆向思维查漏补缺。

五、如何更好的研究和分析用户

1. 问卷调研

问卷调研是用户调研过程中应用最广泛的形式之一，其中最重要的环节是设计调研问卷。问卷设计主要包括：合理性，一般性、逻辑性、明确性、非诱导性、便于理解分析等。

2. 用户访谈

1）访谈时，访谈者要去适应被访谈者，不要让被访谈者适应自己。

2）提问不要带有主观的诱导性。

3）让被访谈者说出自己的真正需求，而不是他自己想出的解决方案。

3. 构建用户画像

1）战略角度：用户画像做好，可以帮助企业进行市场洞察，预估市场规模，制定阶段性目标，指导重大决策，提升ROI投资回报率。

2）产品角度：可以对用户进行人群细分，确定产品的核心人群，从而更加准确的做产品定位并优化产品功能。

3）数据分析的角度：有助于建立数据资产，挖掘数据的价值，是数据分析更加准确，可以进行数据交易，促进数据流通。

六、管理需求的的方法

1. 挖掘用户的真实需求

所以的产品的诞生都是基于用户的需求设计出来的，但用户往往只会提出眼前的，表面上的诉求，而真正的，本质上的需求用户往往没有有意识的深思考，不考虑需求的实现前提到底是充分条件，还是必要条件等等。

2. 评估需求的价值

用户只考虑当下的问题，但是产品往往要考虑用户维度，研发维度，商业维度等等，都是要综合量化产品的ROI，所以必须要有清晰的价值认识。

3. 评估需求的优先级

价值权重，紧急程度，实现的难以程度，上级的指示，先后顺序等等。

4. 开好产品的需求评审会

5. 需求池的应用

6. 父需求与子需求的平衡

7. 需求研发过程中的进度跟进

8. 需求上线后的项目复盘

七、设计优秀的产品

1. 构建自己的产品设计模型库

工作中会经常遇到一些通用的产品设计方案，这些方案同时具备可迁移性和可复用性，作用于具体的行业和业务，只有数据上的不同，基于这些独立的模块，需要构建出自己的产品设计知识地图，自己的产品设计模型。

2. 交互设计自查表

3. 产品的完整性与业务的闭环

4. 产品的高内聚与低耦合

保证产品单一功能模块具备相对丰富的功能，且各模块之间足够独立，一个模块的改动对其他模块影响不大，例如在RBAC模型中，账户管理，角色管理，权限管理三大模块就具有高内聚低耦合的特性，具体体现在账户管理模块的变更，角色管理模块的变更，权限管理模块的变更，三者相互独立，互不影响。

又如在电商体系的产品设计中，下单流程通常涉及商品模块，用户模块和订单模块，在电商管理后台中，这三大模块都是完整的功能模块，呈现出高内聚低耦合的特性，这三大模块都支持各自的增删查改，都不会对其他模块造成影响，却共同支撑整用户的整个下单操作流程。

5. 产品交互的7大定律

1）菲茨定律：指点到达一个目标的时间，与设备当前的位置，和目标的距离，和 目标的宽度有关。

2）希克定律：一个人面临的选择越多，需要做决定的时间就越长。

3）7+-2法则：人类大脑在最好的状态下能记住5~9项信息后，后面还有就会容易出错。

4）接近法则：如果2个或多个对象离得很近时，人的潜意识会认为他们是相关的。

5）防错原则：我们不可能消除差错，但是可以人为的发现并纠正差错，最大限度避免损失。

6）复杂守恒定律：每一个过程都有其固有的复杂度，存在其临界点，超过这个点就没办法简化了，只能将复杂从一个地方转移到另一个地方。

7）奥卡姆剃刀原则：如无必要，勿增实体，简单即有限原则。

6. 雅各布·尼尔森10大交互原则

7. 输出一份完整的产品分析报告

8. 产品用户体验的定义与思考

八、怎么进行数据分析

数据通常可以分为结构性数据和非结构性数据，结构化数据是指可以按一定的规则可以格式化存储的业务数据或用户基础数据，这些数据通常存储在关系型的数据库中，而非结构型数据通常是指那些非格式化处理的数据，如用户的评论数据，这些数据通常存储在非关系型的数据库中。

数据分析是指用适当的统计分析方法对收集起来的大量数据进行分析，从中提取出有用的数据及形成结论的过程。数据分析通常分为描述性数据分析、探索性数据分析和验证性数据分析。其中描述性分析是指侧重于对现有的数据进行事实或结论的陈述。探索性分析侧重于在数据之中发现新的特指，验证性分析侧重于对已有的假设验证或证伪。

完整的数据分析过程分为：

1. 明确目标
2. 获取数据
3. 处理数据
4. 展现数据
5. 分析数据
6. 输出报告

在数据分析过程中，指标是指衡量事物发展程度的单位或方法，通过需要经过计算或统计才能得到，比如PV、UV；维度是指事物本身所带有的某种特征或属性，抑或是一种描述事物的角度，如性别，时间，年龄，收入等。

九、如何做项目管理

瀑布模型将软件生命周期划分为需求分析、方案设计、实施/编码、测试/评估、运维这5个基本活动，并且规定了它们自上而下，相互衔接的固定顺序，如同瀑布流水，逐级下落。

物极必反，实现需求的目标的明确，研发流程的规范以及项目流程的严格控制，也牺牲了对需求变动响应的灵活性。导致在项目各个阶段之间极少的反馈。只有在结束的后期才看到结果，如果最终结果与用户的期望不一致，则会产生巨大的返工成本。瀑布模型的致命缺点就是不能用户需求的变化。

敏捷是一种应对快速变化的需求的软件开发能力。敏捷不仅强调技术人员与产品及客户之间的紧密协助，还重视面对面的沟通，认为这比书面文档沟通更加有效，同时要求频繁交付新的软件版本并且不断的反馈。更注重软件开发过程中人的作用。

十、总结

以上，只是总结的一些方法，最重要的是产品在日常的工作中不断的实践，思考和应用，举一反三，不断的自我革新，相信都能成为一个优秀的产品经理。