产品文档怎么写

传播蛙

困在家里,每天起床 – 开早会 – 开项目会议 – 刷牙洗脸 – 看文档邮件 – 开项目会议 – 循环往复直至睡觉,不胖都难…

每天干的最多的就是沟通、看文档,最经常遇到的也是在沟通过程中对文档的各种“Diss”。

今天抽点时间,总结下写文档的思路,希望对大家有点启发。

在写文档之前

大家很容易在网上看见各种眼花缭乱,格式规整,精美无比的文档,显得很专业。不可否认,这种文档但凡谁第一眼看见,都会觉得很专业。

但是,文档的矛盾往往是在细节review和沟通中才会爆发的。

所以,文档主要是搞定看的人。

从日常沟通频率来看,产品和研发之间关于文档的矛盾最多,先来盘点「给研发看的文档」。

一、先讲故事

我是从研发转做产品的,搞研发的,多半逻辑思维比较强,喜欢剖析事物的本质(这个事情本质上…)、引经据典(我见过的产品没这么做的…)、列举可能性(当xx情况下,万一…)等等等。

产品经理如果直接搭话,后果就是在逻辑的灵魂拷问中败下阵来。

那么面对这种情况,我总结的原因有几种:

  • 1、直接写产品功能。这种就是变相的告诉研发,别BB,按我说的做。
  • 2、文档描述的文字不严谨,前后概念定义不相同,需求范围边界不清晰,约束条件不讲明。任何一个细节的点被抓住,整个文档的严肃性就没了,开始迎接各种挑战。
  • 3、过多用技术化的语言来写文档,以为研发能看懂。这种仅适用于技术功底较深的产品经理,否则进入对方的绝对领域就是找虐。

写给研发看的文档,最重要是说明为什么要做和做什么。多讲讲故事。

在任何大小沟通之前,先准备好一两个典型故事,最好出自典型客户需求或者经典案例,开门见山的和研发聊一下我们的实际需求和业内情况。

一个好的产品经理,自己就是个故事大王,应该储备大量的案例、行业见解和解决方案。这些故事不会引起别人反感的原因在于:故事都是第三方的,不是自己的;而沟通中最怕上来就讲自己的观点,“我”和“你”是对立面,“他”不是。

二、再说策略

明确了需求和要解决的问题,不要一上来就直接给出解决方案。原因很简单:

  • 1、你给的方案技术不可行。研发直接给你打上一个“外行指导内行”的标签。
  • 2、你给的方案在目前市场或者产品中没有竞争力。这个最可怕,直接关系到大家对你能力的判断。
  • 3、你给的方案太初级,是个人就能想到。敷衍了事,无解。

讲故事获得共情后,要进一步获取信任,把业界情况、自身目的和限制、初步决策的原则说清楚。

很多时候,排到计划里的解决方案往往是修改了若干次之后的结果,这和网上设计师的作品被甲方来回修改并没有太大区别。

首先,我们要认识到,解决方案的修改是无法避免的,但是为了让方案尽可能落地,产品经理需要比任何人都思考的更多:

  • 1、业界经验如何解决这个问题,有哪些不同的做法。
  • 2、我们目前的条件如何,包括但不限于:时间、人力资源、已规划已执行的产品计划是什么样子的。
  • 3、和研发、市场等同学沟通完之后初步的可行性分析。
  • 4、(非常重要)如果不做会有什么不能接受的后果。这一点是为了进一步搞清楚这个需求的核心问题是什么。

最后的最后,给出的不是方案,而是拟定方案的选择策略。没有这个策略为大前提,后面细节的讨论会经常漫无边际的展开,3个小时的会不是梦。

三、做好细节

前面两点如果能很好的落实下去,影响文档质量的就是各种细节。这个问题没有捷径,就是花时间仔细做,反复推敲。我把经常会遇见的问题列举出来,引以为戒:

  • 1、一个人写的文档,基本没有统一的格式,每次都是随性发挥。
  • 2、产品概念随便定义:前后名称不统一,用非业界常规的命名,用冗长晦涩的文字去解释。
  • 3、在正规文档里画一些自创的图例。
  • 4、流程图或交互图不完整,用另外的文字去做“补充说明”。
  • 5、细节规则没有,以为大家都知道。
  • 6、文档不检查不推敲,留了一堆逻辑漏洞和错别字。
  • 7、文档存储的位置飘忽不定,网盘、wiki、本地文件、三方应用到处都有它的身影。

如果上述问题你都没中招,那么你写的文档应该堪称典范;但如果想都做好,你唯一无法缺失的就是时间。

文档需要时间,不要压缩时间来提前交付文档,这样后续扯皮的时间会更多。

四、定稿前多沟通

在产品经理编写的各种文档里,基本上都需要其他角色的意见作为输入,如果一个文档发布前都是出自自己的经验和理解,那会是什么天都不知道。

输出一份任何一份正式的文档,都可以划分为两个阶段:草稿阶段和打磨阶段。

草稿阶段的文档,形式不限媒介不限,以最快速度最有效的和相关人沟通讨论。没必要约正式的会议,避免大家过于扣细节。

打磨阶段的文档,需要你把之前草稿阶段的成果进一步揉碎了消化了满满撰写,反反复复推敲。

文档类型的选择和精力分配

从我个人经验以及产品经理圈子的实际情况来看,目前尚未发现能从头到尾输出完美文档的人,这是资源限制和能力限制的必然结果。

如何选择合适的文档,分配多少精力,主要看你的团队情况:

1、微型集中型团队

如果团队很小,一起办公,大家技能树比较均衡,那么文档最好的形式就是产品本身。每天输出一个版本的产品,最直接能反应出你的产品文档应有的结果。

2、中小型集中型团队

如果团队规模较大,有明确的职责分工,那么就要根据实际情况来选择:

如果团队缺少行业经验,那么把用户需求、竞品分析、成熟的领域模型编写的细致点。

如果缺少明确的需求来源或者复刻某个竞品,那么把功能需求和交互文档写的细致点。

如果团队磨合比较好,产品有固定的输出套路,那么把功能需求和数据模型定义好就可以开工了。

这也是为什么并没有什么统一的的文档规范的原因。企业为了生存下去,活法不一样,纠结形式本身首先就慢人一步了。当然,这和注重细节并不冲突。

产品经理的日常功课型文档

除了在产品研发过程中常用的用户需求文档、功能需求文档、交互文档、产品Roadmap及计划、产品验收文档等,还有一些文档需要输出,也可以视作对产品能力的锻炼。

  • 1、产品运营(运行)情况:验证产品是否达到预期目标,PMF有没有问题,接下来的改进目标是什么。
  • 2、产品市场及客户反馈:产品市场是否有变化,客户的反馈渠道建立及问题分析,产品和竞品的跟踪比较。
  • 3、产品定义的重新思考:未来五年、十年,目前的产品会有什么样的趋势变化,有没有实验性质的功能需要尝试。
  • 4、产品的包装:当把产品输出给客户、经销商、老板、亲人朋友时,它是什么样子。

说真的,写出无懈可击的文档,缺的只是时间,你说呢?

祝疫情期间,大家每天都能多输出5份文档,god bless U.

文:我是仔仔侠

本文由 传播蛙 作者:传播蛙 发表,其版权均为 传播蛙 所有,文章内容系作者个人观点,不代表 传播蛙 对观点赞同或支持。如需转载,请注明文章来源。
0

发表评论