编辑导语：产品业务文档应该如何整理才能让产品新人快速上手、让文档分类清晰从而能够轻松地继续查询、让研发新人了解过去的逻辑，保证迭代的质量呢？本文作者为我们总结了三个步骤，帮助我们有效避免重复造轮子，提升文档撰写效率和价值。

在创业公司中，当产品由v1.0版本逐渐稳步迭代至2.0、3.0甚至更高版本时，后续的迭代肯定不再是百分百在创造新的东西，而是在原有的基础业务和数据架构上进行延伸和再创新。

那么在这种背景下，我们就很容易遇到下述3种问题：

问题一：产品新人上手难

刚入职的产品新人对系统的架构和业务逻辑不熟悉，这时往往需要产品leader花大量的时间去解答其提出的各类问题；同时，新人也难以在零散的问答中快速把握整个系统全貌，很难快速开展新工作。

问题二：文档分布零散、难以统一查询

当原来专门负责某模块的同事离职后，产品小黑被派至接替他的迭代。但是此前该同事在很多版本都零散地迭代优化过这一模块的功能，文档十分分散，难以进行统一的查询和追溯。

这就导致了小黑需要东一块西一块地自行拼凑文档来了解这部分的逻辑，很大程度上耽误了该模块的迭代进度。

问题三：研发新人不熟悉老逻辑，影响迭代质量

新来的前端小绿在入职后的第一份迭代文档中，发现产品文档里很多处都只写了个“遵循原逻辑”，而小绿对原来的老逻辑几乎完全不清楚。

但是他又想着这一块可能不需要做改动，在新版本中就直接忽略掉了这一部分，仅关注了列出需要改动的前端逻辑，结果导致最终代码质量不佳，从而影响了迭代质量。

从上述3个场景来看，当团队出现了人员变动（流失or扩张）时，我们就需要尽快对产品业务文档进行归档整理，以帮助新人快速上手并保证后续的迭代质量。

解决了为什么要做产品业务文档整理归档的问题，下面我们就步入正题：产品业务文档应该如何整理归档？

首先，我们要明确做这件事的核心思路：即把归档整理后的产出——「产品业务文档知识库」当作一个产品来看。

核心用户：产品和研发新人。

核心需求：

• 对系统很陌生，需要快速掌握系统全貌；
• 针对同一模块的业务逻辑，需要支持统一集中查询。

针对上述需求，我们可以按照下面3个步骤去逐一实现：

一、梳理业务架构图

为了帮助新人快速掌握系统全貌，我们需要给出一个经过产研团队共同确认过后的业务架构图，帮助他们从系统地角度去看待产品，更清晰地了解产品各个模块的划分、价值以及模块之间的交互关系。

与此同时，根据业务架构图，我们也能更容易就接下来按模块对文档进行分类达成共识。

下图为一个脱敏之后的业务架构图，仅供大家参考：

二、迭代文档整理

此前，我们都是以迭代版本号为主，对迭代文档按时间顺序进行了纵向归档，但这样却不便于按模块进行横向查询。因此在第一步完成业务架构图梳理之后，我们需要把已有的迭代文档按模块进行统一汇总。

下图为笔者的迭代文档归类表格，仅供参考：

当我们按模块整理完迭代文档之后，短期内能够方便产研新人按模块对业务逻辑进行熟悉。

但我们仍旧面临着一个不可避免的问题：每一个迭代都较为零散，只是将文档简单汇总在一起，还是难以快速为业务有一个全局的掌握。为了解决这个问题，因此我们要完成接下来的第三步：模块核心逻辑撰写。

三、核心模块逻辑撰写

1. 划分优先级

在资源和时间有限的前提下，我们需要为核心模块逻辑的撰写划分优先级，以快速打造一个mvp知识库给到产研新人，这里也同样遵循了二八原则，用20%的时间完成80%价值的核心模块逻辑撰写，后续再逐步补全剩余优先级略低的模块文档。

那么优先级应该怎么划分呢？评估优先级的角度和方法有很多，但是无论按照何等标准进行划分，我们都应该围绕我们的用户和产品目标来展开。

• 产品研发新人能够上手开展工作之前，他们必须要了解的产品业务是哪些？
• 不熟悉哪些业务会大概率影响到他们的迭代质量和进度？

下面给出一种广为认知的评估思路：按照紧急/重要四象限来对模块优先级进行划分。这个方法想必大家已经很熟悉了，此处不再赘述。

2. 逻辑撰写

在确定好优先级之后，我们就需要开始着手完成核心模块的逻辑撰写工作了。

下面给出笔者的撰写框架，供大家参考：

1）版本记录

从使用场景可以判断得出，此处的文档肯定后续会经历持续的完善和优化，因此我们需要在每一篇核心模块逻辑文档的第一部分就加入该文档的版本记录。

文档版本记录需要包含文档版本号、修改记录、修改人及修改时间。

2）文档正文

接下来就步入文档的正文撰写阶段，此处给出笔者的正文撰写结构供大家参考，共包含4部分：需求场景、数据字典、业务逻辑和相关迭代文档链接。

• 需求场景：旨在解决用户在什么场景下的问题；
• 数据字典：对于陌生和特定的数据名词进行统一的概念讲解；
• 业务逻辑：该模块具体的业务逻辑；
• 相关迭代文档链接：该模块涉及到的迭代版本号及链接。

其中，需求场景、数据字典和相关迭代文档链接都是建议尽可能完善的部分，而业务逻辑则可以按需优先梳理出核心逻辑，剩余细节可以及时告知读者在具体的迭代文档中查看。

这样，能够有效避免重复造轮子，提升文档撰写效率和价值。

在完成上述3步之后，我们就上线了产品v1.0版本，交付给了产研新人第一版的产品业务文档知识库。

当然，遵循pdca原则，我们需要通过监测和反馈收集，对该知识库进行持续的优化，以保证知识库的效能最大化，而不是最终沦为一座沉睡的地下图书馆。

作者：冰冰酱；公众号：setmefree

本文由 @冰冰酱 原创发布于人人都是产品经理，未经许可，禁止转载

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