编辑导语：文档能力可以说是互联网产品经理的基本要求能力，文档能力的重要性不言而喻，本篇文章作者详细地讲述了文档能力的基本内容等，一起来学习一下，希望对你有帮助。
记忆中第一次听到文档，应该还是在大学时期跟师兄的交流中。
大学4年计科，跟文档相关的最多也就是代码注释，所以本能地把文档当做不必要的繁文缛节。
直到工作后，成了背锅侠，才慢慢意识到文档的重要性。
一、为什么要写文档
记得多年前的一个大型紧急项目，第一次体验了什么叫做先评审后需求。
在公司高层的压力下，产品团队被迫在只有框架流程图和几页原型图的情况下，强行完成了需求评审。
技术团队完成评估和分工后，项目已经进入实质性的开发阶段。按理说这个时候应该更加注重项目的跟进和协调沟通，但是leader仍然还是坚持要求我们跟随开发节奏完成PRD。
其实当时很难理解，甚至于消极抵触。
但到了多年之后，才逐渐明白了这么做的意义在哪。
除了产品岗位，各个工种或多或少都会涉及到各种专业的文档。
怎么写好文档，值得研究。知道为何而写，更值得深思。
1. 辅助思维
一个人的思维很难做到面面俱到。
我们在打造一个产品时，往往是由点到线，由线及面。
当若干条逻辑交织在一起，就不太容易找到逻辑的影响与关系，更不容易发现漏洞与疏忽。
做好文档工作，既能够时刻保持方向的正确性，也能够细致地对细节进行思考与判断。
一个人的思维更难做到一成不变。随着时间的推移、信息的增加，对待同一款产品，甚至同一个需求，我们也很难保证认知和想法的前后统一。
做好文档工作，能够帮助我们在思维上保持一致性。
2. 降低沟通
当我们做小项目、小需求的时候，一人一嘴尚能应付。
但当我们面对规模化的需求和大量人力时，光靠沟通肯定很难解决问题、完成产品。
文档的又一重要作用就在于，能够作为项目的指导意见客观呈现，而避免无穷无尽的沟通陷阱。
我记得上面提到的项目，做到第二期时有人员调整，很多新人进入团队。
因为他们对第一期版本以及项目背景不熟悉，所以产品团队还需要再做一次信息同步工作。这个时候文档就起到了关键作用，一份完善细致的文档，就可以极大地降低沟通成本。
3. 留据溯源
一位产品前辈曾经告诫过，“做好产品文档工作，能够避免90%的矛盾与冲突”。
都说口说无凭，文档的又一个重要作用，就是能够明确记录己方的真实历史行为。一旦出现问题或者发生误会，好的文档就是能够帮助产品经理。
虽然在个人的认知里面，很多产研矛盾更像是小孩子为了鸡毛蒜皮的事斗嘴，而不粘锅的工作风格也很难有所作为。但如果确实可以避免不必要的麻烦，又何乐而不为呢。
4. 知识传承
文档的又一个重要作用，就是能够进行知识的归档与传承。
一个团队里面，每一个人都有自己的想法与风格。如果产出只是为了自己看，那文档就少了很多意义。
现在很多公司都会自建wiki，目的之一就是在于文档能够标准化的产出，并且被归档被存储。
二、要写哪些文档
正所谓，产品文档写不好，不如辞职开淘宝。常规认知中，产品的主要产出文档就是原型图与PRD了。
但除了这些，很多环节仍然也是需要文档产出的。
1. BRD与MRD
一个比较全面的产品经理，实际需要涉及到的文档还会包括BRD和MRD两种文档。
BRD（商业需求说明）一般是在项目开始之前，对项目的商业目标和价值进行分析。
其主要受众就是负责人、投资人、核心干系人。
其本身就是概括性地阐释，做什么、怎么做、投入、产出等问题，帮助上头做决策。
MRD（市场需求说明）一般是在项目启动前，对整个市场的调研、分析与总结。
其主要说明三个问题，即市场是什么、客户要什么、别人有什么。最终帮助企业结合自身实际，得出自己做什么的结论。
一般情况下这类文档“轮不到”产品来做，因为这更偏向于是公司决策层的活儿。
但是这并不意味着产品经理可以忽视这两种文档，相反，产品经理的个人价值可以直接体现在这两种文档。
具体的市场相关内容，我们将在后续的市场相关文章中详细介绍。
2. 需求池
需求池是产品团队进行需求管理的有效手段，主要对需求进行记录归档、分析判断、进度跟进、反馈等处理。
PRD重点在于需求的具体方案，需求池的重点在于需求的状态呈现。
产品与横向团队沟通的主体都是需求，所以需求池不应该仅仅是产品团队内部工具，也应该是产品工作的对外展示看板。
具体的需求相关内容，我们将在后续的相关文章中详细介绍。
4. 通知与确认
另一种非传统意义上的文档，就是产品工作中的通知与确认了。
这种文档往往通过IM、邮件的方式进行，一般比较随意。
单独拎出来说，是因为他们实际上很容易挖坑。
通知主要是重要节点的信息同步，确认主要是重要阶段的多方“确权”。
需求方不买账的情况时有发生，抛开具体工作的细节，很多时候都是因为需求确认问题造成的。
需求确认是必要环节，明确需求是什么，产品怎么做，双方签字画押，才能保证对齐，才能杜绝后期扯皮。
很多时候因为各种原因，产品不作需求确认，往往做了一堆事，还让自己成了背锅侠。
通知不到位也是造成麻烦的主要原因。
产品推进并不只是产研团队的事，还会包括到相关的各个部门。
一旦信息不同步，准备不充分，就容易造成很多问题。
通知与确认很难作为传统文档进行维护，但是对日常工作却有着关键性的作用，不可忽视。
5. 其他
产品经理还会使用到很多其他文档，这里就不一一罗列了。
三、怎么写文档
同样都是互联网企业，每家公司都有着自己的业务模式、企业文化。
同样是产品经理，每一个人都有着自己的思维方式、工作风格。
现实的矛盾在于，我们经常因为条条框框，抹杀个性与差异。
又经常因为个体差异，影响执行的统一。写文档和写需求一样，都需要考虑向什么人在什么场景提供什么东西到达什么目的。
1. 标准文档
原型、PRD是产品最常用到的文档，而这种标准文档往往最需要规范化管理。
这种文档更讲究内容的逻辑与结构性，就像讲故事一样，讲得乱、讲不全，都会对读者造成困扰。
而且，文档本身也需要考虑传承性，就像前面所说的，如果产品文档仅仅是为了悦己，那就少了意义。
另外，文档在管理上也需要有标准规范，小到命名与目录，大到版本与系列，都需要有具体要求。
标准文档的规范，在各个团队各个个体间，都会存在差异，有用即可，不作赘述。
2. 非标文档
电影《中国合伙人》中有一句台词，学英语不仅仅是学习如何表达，更重要的是学习英语背后的思维。
产品写文档也一样，很多时候不应该拘泥于文档的形式，更应该侧重于思维的组织与呈现。
之前在做某个新项目时，线下部分需要根据客流情况，以此来制定推广和物料计划。
因为行业整体还处于初级阶段，无法直接获得客流信息，所以只能靠自己去搜集。当时的做法是：
第一步，明确方式。直接获取行不通，但可以间接通过相关领域的商户情况获取。
商户通常聚集在商业体、写字楼，所以通过商户聚集指数，也能够间接反馈客户的聚集程度。
所以目标就变成了，通过相关商户分布，间接获取线下客流分布。
第二步，获取信息。因为信息结构不标准，所以很难直接在地图上搜到商户分布情况。
但是有专门的B2C撮合平台，已经帮忙整理了很多商户信息。
于是选择了几个比较大型的平台，通过爬虫把所有信息都尽可能收集到本地。
第三步，信息清洗。因为各个平台的数据结构并不统一，且存在很多纰漏。
所以拿到的商户数据并不能够直接使用，需要批量对数据进行简单清理。简单来说就是合并、统一、去重、去错。
第四步，信息呈现。最终的商户信息收到之后，就可以直接导入到地图工具进行展示了。
通过一些基本的参数调整，就可以得到如下的分布图。而团队也根据该图，制定了详细的推广计划并最终完成线下获客。
上述主要是从思维到执行，简单描述了一个文档执行的实例。
这种文档，并不是上述所说的任何标准产品文档模板。而在繁杂的产品工作中，也经常会遇到各种非标的问题。
四、总结
工欲善其事，必先利其器。产品文档作为产品经理主要的产出，需要大家足够重视，充分打磨。