功能设计文档_好的文档到底是什么样的-CSDN博客

本文链接：https://blog.csdn.net/weixin_39737240/article/details/111339624

不同公司的产品文档之间差别很大。我加入嘟嘟美甲时产品还是在草创阶段，我们的文档就是几页纸，标注着整体的逻辑并描述了功能细节。而诸如BAT这样的大企业的主产品，一个小的产品改动可能就要经历BRD、MRD和PRD。我们去评判到底哪种格式正确，就好像讨论哪种口红颜色最好看一样，没有意义。如同哪种颜色的口红好看要看涂在谁的唇上一样，哪种文档好要看用在怎样的项目中。

我了解过很多产品经理的文档格式，也使用过很多不同的文档格式，但想对好的产品文档下个定义真的很难。锤子科技的项目经理周老师很有经验，我刚去公司的时候他正在努力让还称不上正规的产品设计研发流程通畅起来，他告诉我一个检验方法：能够减少甚至免除在开发过程中技术人员跟产品经理沟通的文档就是好的文档。

这是基于文档的根本意义的检验。严格来说，文档不是必需的，完全可以不写，只需要产品经理不断跟技术人员沟通，时刻跟进研发的每个步骤，做出来的产品自然是没有问题的，但这个过程的效率太低了。而文档的作用就是高效地传递产品经理对产品功能的描述并予以记录。为什么不好的文档并不能让成本降低呢？因为这些文档对功能的描述不清楚、对细节逻辑梳理得不清楚或者存在很多缺漏，导致技术人员在依照文档进行开发时，需要不断找产品经理核对或者要求补充。

优质的产品文档应该是提交给技术研发人员后再也不用来回确认沟通的文档。由于现实因素这几乎不可能实现，不过我们要尽力做到让需要确认的情况减少。

有了这条准则，我们就可以尝试抽象出好的文档应当满足的几个条件。

1. 没有逻辑硬伤

硬伤指文档的内容前后不一或者逻辑不通。一旦出现硬伤，那么文档显然就不可用，因为会让技术人员搞不清楚到底该怎么做。

2. 没有疏漏

有经验的产品经理出现硬伤的概率不大，但存在疏漏的可能性还是有的。一个功能牵连的信息和逻辑越多就越会有考虑不周全的地方，如果没有定义清楚细节，那么技术人员开发到一半，发现有的功能应当有但文档中没描述，只好再找产品经理要求补充。

3. 逻辑清晰

文档内容零散会给技术人员造成困扰，使他们看过很多遍也不知道如何下手。产品设计可以松散，但如果不先从全局出发定义问题，技术人员开发时就无法展开工作，这就需要产品经理尽量做到文档逻辑清晰。

4. 可读性强

很多产品经理只是考虑把事情说出来，而不是友好地说出来。有很多数据、信息、流程用图表展现更清楚，但因为产品经理懒得做，就用几行字说一下，大大增加了理解成本。如果文档中有很多名词、解释都说得模棱两可、难以理解，就会导致技术人员在后续发展过程中还要反复向产品经理确认(有可能产生歧义的名词最好在文档开头予以解释)。

只要满足以上四点，具体的展现方式就不是最重要的了。

我们知道产品经理不仅要理解用户的需求，还要配合好技术人员，理解他们的需求。产品经理需要能够向技术人员输出有效、友好的具体功能描述。产品经理要达到这个要求，就要对技术层面的很多事有初步的理解，也要知道产品功能的实现逻辑、数据的结构和信息流。

如图7-2所示，上方的图示是很多产品经理自认为所处的位置。对于他们来说，产品经理主要就是跟用户打交道、发掘用户需求并设计功能。这是最核心的部分，但不会特别关心输出。需求文档只是单向描述设计时的结果。下方的图示则是我认为更合理的表述。对于产品经理，输入就是不断跟用户产生互动，输出就是不断跟技术研发人员产生互动。在互动中，完成需求分析、产品功能设计及协助产品实现的工作，前后两端同样重要。只关注用户端的输入却不关注技术研发端的输出就会失衡。