谈谈你知道的发布上线（二）

“一个货架两个标准两个评审”清晰的定义了产品发布到上线的两个重要阶段和两个重要控制点，以质量标准为基本要求也可以构建起用于评估产品版本上线质量的指标集。

很多时候产品的发布上线过程发布阶段和上线阶段并不是十分清晰，需要我们根据经验和个人的理解进行划分。举个例子：一款APP的版本完成版本测试之后就可以向应用市场发布或者通过后台进行自动升级，感觉好像它的发布和上线两个阶段一气呵成。事实上，我们仍然可以把它分解成两个阶段。版本测试完成后，版本经过发布评审归档到版本仓库准备进行应用市场发布或者自动升级，这就是发布阶段。运营人员和产品经理发起上线评审，充分评估app发布上线条件的完备性和风险，然后通过应用市场或者后台完成发布，这个过程就是上线阶段。通过这样详细的分解，可以把“一个货架两个标准两个评审”的方法论应用于绝大多数产品的发布上线场景。

上面举的例子相对比较简单，下面再来看一个更为复杂的例子：

A产品是一款面向企业的OA系统，需要由专业的交付实施团队私有化部署到客户单位，产研团队可以在家里通过远程的方式对其做维护，包括日常的版本更新、功能升级、问题排查等。随着交付的客户单位越来越多，经常会出现在客户不知情的情况下升级了版本，升级版本质量达不到现场客户要求，大的版本更新未通知到交付实施人员导致客户问询起新功能来交付实施人员不知道该怎么回答，大版本交付到客户现场却没有最新的部署和交付手册等等诸多问题。

为了解决这些问题，我们首先对整个问题参考上面app发布的这个案例进行详细分解。

“A产品的发布阶段”：产研项目组完成版本开发，测试通过并且达到发布质量标准，上架等待交付实施“取货”交付。

“发布质量标准”：交付实施代表参与标准的制定，跟产研一起就版本应该达到的质量底线要求进行明确。标准里需要明确提供哪些文档，比如部署手册、交付手册、FAQ、产品销售工具包、架构设计等。

“发布评审”：全要素角色参与发布评审，包括市场经理、交付实施代表、产研侧代表、运营人员等角色一起完成版本的发布评审（最终由产品经理或端到端的项目经理完成发布决策）。确保版本达到发布的标准和条件。

“A产品的上线阶段”：交付实施人员从货架“取货”，发起上线评审，完成现场的部署。

“上线质量标准”：交付实施项目经理跟销售、商务、系统架构师等根据合同要求，共同制定的上线质量标准。交付实施人员依据上线质量标准对产品发布版本进行验收和熟悉。

“上线评审”：对上线进行多方面尤其是风险方面的评估，由交付实施项目经理最终决策。评审通过后完成客户现场的部署实施和交付。

如果A产品能够按照上面的这几个环节新交付到一个企业，其实就可以控制甚至是解决类似于版本质量达不到现场要求、交付实施人员对版本功能不熟悉、关键文档缺失等问题。事实上新上企业还是比较简单的，复杂的是大小版本的更新、功能升级场景下怎么控制质量。

首先，发布阶段的定义没有变化，发布质量标准可以根据大小版本进行设定。小迭代没有必要像大版本那样有很多的质量要求。比如我就提交一个js脚本，没必要重新提供一个包含全部质量指标的完整质量报告。

其次，发布评审和上线评审一定是存在的，形式视情况进行简化。无论大小版本，评审的决策人跟新交付到一个客户场景下的评审决策人也是一致的。即发布阶段由产品经理或者端到端的项目经理决策发布，上线阶段的由交付实施项目经理决策。这意味着，无论大小版本，你的升级都要同制到交付实施项目经理，他必须知晓并且同意上线。回到案例中，A产品的小迭代升级是由产研在家里完成的，并不意味着产研能够直接决定版本的上线。产研需要发起上线评审并交给交付实施项目经理进行决策。如果100个客户现场中，有20个交付实施项目经理Say NO，那么这个产品就只能升级80个客户。这样一来就解决了版本升级现场不知情的问题。总之，产研对发布负责，交付实施对现场上线负责。

最后，套用流程会让大家感觉很重，尤其是评审过程。没有必要为所有的迭代上线都组织线下的会议评审，可以根据情况在不丧失控制功能的前提下，在不同的场景下简化评审过程。但要尽可能保留记录，用于问题的后期追溯和问责。

这里其实多了一个概念，即我们往往会为发布阶段和上线阶段分别定义一个质量负责人或者决策人。发布阶段往往是由产品经理或者端到端的项目经理来承担，上线阶段往往是对现场直接负责的交付实施项目经理来承担。