互联网产品经理能力矩阵:基本能力之文档能力

6 评论 4623 浏览 16 收藏 13 分钟

编辑导语:文档能力可以说是互联网产品经理的基本要求能力,文档能力的重要性不言而喻,本篇文章作者详细地讲述了文档能力的基本内容等,一起来学习一下,希望对你有帮助。

记忆中第一次听到文档,应该还是在大学时期跟师兄的交流中。

大学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撮合平台,已经帮忙整理了很多商户信息。

于是选择了几个比较大型的平台,通过爬虫把所有信息都尽可能收集到本地。

第三步,信息清洗。因为各个平台的数据结构并不统一,且存在很多纰漏。

所以拿到的商户数据并不能够直接使用,需要批量对数据进行简单清理。简单来说就是合并、统一、去重、去错。

第四步,信息呈现。最终的商户信息收到之后,就可以直接导入到地图工具进行展示了。

通过一些基本的参数调整,就可以得到如下的分布图。而团队也根据该图,制定了详细的推广计划并最终完成线下获客。

上述主要是从思维到执行,简单描述了一个文档执行的实例。

这种文档,并不是上述所说的任何标准产品文档模板。而在繁杂的产品工作中,也经常会遇到各种非标的问题。

四、总结

工欲善其事,必先利其器。产品文档作为产品经理主要的产出,需要大家足够重视,充分打磨。

 

本文由 @绵竹县吴彦祖 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash ,基于 CC0 协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 是这样了,从各个方面来说都是好记性不如烂笔头,虽然不是真的写,但是思维逻辑罗列下来就会比头脑里清晰很多(ps只有我是被作者的名字吸引进来的吗

    来自福建 回复
    1. 不只是你,我也被吸引了

      回复
  2. 来自产品小白的肯定,反手一个关注

    来自广东 回复
    1. 客气,客气

      回复
  3. 用好文档确实能降低沟通成本,因为很多时候团队需要信息同步。

    来自广东 回复
    1. 没错了,说千遍不如写一遍

      回复