编辑导语：产物业务文档应该如何整理才气让产物新人快速上手、让文档分类清晰从而可以或许轻松地继承查询、让研发新人相识已往的逻辑，担保迭代的质量呢？本文作者为我们总结了三个步调，辅佐我们有效制止反复造轮子，晋升文档撰写效率和代价。

在创业公司中，当产物由v1.0版本逐渐稳步迭代至2.0、3.0甚至更高版本时，后续的迭代必定不再是百分百在缔造新的对象，而是在原有的基本业务和数据架构长举办延伸和再创新。

那么在这种配景下，我们就很容易碰着下述3种问题：

问题一：产物新人上手难

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

问题二：文档漫衍零星、难以统一查询

当本来专门认真某模块的同事去职后，产物小黑被派至接替他的迭代。可是此前该同事在许多版本都零星地迭代优化过这一模块的成果，文档十分分手，难以举办统一的查询和追溯。

这就导致了小黑需要东一块西一块地自行拼凑文档来相识这部门的逻辑，很洪流平上延长了该模块的迭代进度。

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

新来的前端小绿在入职后的之一份迭代文档中，发明产物文档里许多处都只写了个“遵循原逻辑”，而小绿对本来的老逻辑险些完全不清楚。

可是他又想着这一块大概不需要做窜改，在新版本中就直接忽略掉了这一部门，仅存眷了列出需要窜改的前端逻辑，功效导致最终代码质量不佳，从而影响了迭代质量。

从上述3个场景来看，当团队呈现了人员变换（流失or扩张）时，我们就需要尽快对产物业务文档举办归档整理，以辅佐新人快速上手并担保后续的迭代质量。

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

首先，我们要明晰做这件事的焦点思路：即把归档整理后的产出——「产物业务文档常识库」看成一个产物来看。

焦点用户：产物和研发新人。

焦点需求：

对系统很生疏，需要快速把握系统全貌；

针对同一模块的业务逻辑，需要支持统一会合查询。

针对上述需求，我们可以凭据下面3个步调去逐一实现：

一、梳理业务架构图

为了辅佐新人快速把握系统全貌，我们需要给出一个颠末产研团队配合确认事后的业务架构图，辅佐他们从系统地角度去对待产物，更清晰地相识产物各个模块的分别、代价以及模块之间的交互干系。

与此同时，按照业务架构图，我们也能更容易就接下来按模块对文档举办分类告竣共鸣。

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

二、迭代文档整理

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

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

当我们按模块整理完迭代文档之后，短期内可以或许利便产研新人按模块对业务逻辑举办熟悉。

但我们仍旧面对着一个不行制止的问题：每一个迭代都较为零星，只是将文档简朴汇总在一起，照旧难以快速为业务有一个全局的把握。为了办理这个问题，因此我们要完成接下来的第三步：模块焦点逻辑撰写。

三、焦点模块逻辑撰写 1. 分别优先级

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

那么优先级应该怎么分别呢？评估优先级的角度和要领有许多，可是无论凭据多么尺度举办分别，我们都应该环绕我们的用户和产物方针来展开。

产物研发新人可以或许上手开展事情之前，他们必需要相识的产物业务是哪些？

不熟悉哪些业务会或许率影响到他们的迭代质量和进度？

下面给出一种广为认知的评估思路：凭据紧张/重要四象限来对模块优先级举办分别。这个要领想必各人已经很熟悉了，此处不再赘述。

2. 逻辑撰写

在确定好优先级之后，我们就需要开始着手完成焦点模块的逻辑撰写事情了。

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

1）版本记录