和任何生产管理工作一样，产品管理工作并不简简单单地是个流程管理。产品管理即需要管理形式和流程，也需要管理业务和内容。

对于传统软件业务、项目型业务（一般通过项目孵化软件产品），需要重点抓产品规范。对于单款产品，组织做规范的难度不大，移动公司做规范有悠久的传统，我本人也参加过。但是如果多个产品部门都涉及到某个领域的时候，就会有问题：一方面大家的需求有些差异、一方面大家的基础也有所不同，协调起来的难度会比较大。但是这种情况下依然要坚持统一，否则遗患无穷。我们也认真思考了一下，有那么几个规范是所有产品部门都需要的，其中之一就是运维规范。如何把一个规范写的即有效，又覆盖完整，绝对是个挑战！

开展公有云业务后，很多内容都发生了变化。经历了最初的忙乱后，我们决定流程和内容一起抓，这才发现转型是一个巨大的变化：原先我们每个产品部门有20-30个产品，现在被统一成移动云一个产品，原先的多个产品变成了公有云产品下的多个功能（为了便于理解，后面还是称为产品）。同时在双百攻坚期间，我们有又新增了大量的产品。这一下子把事情变得更加复杂了。这也是我们要面临的一个挑战。因此我们在内容管理方面开展了多级跳提升计划。目标是通过管理多级跳实现产品提升多级跳。

第一跳：产品三级功能梳理。我们注意到各个产品部门、各个其他条线部门都在开展对标 – 毕竟公有云是个人人可见的业务，好坏优劣都挂在脸上，一目了然。那么从最容易看到的功能开始梳理产品内容就是一个科学的入手点。于是我们就发现有些产品的功能计划和预期结果就存在较多的差异了。

第二跳：深入研究了功能，接下来就对产品的全面刻画。我们称之为产品指标体系，这个体系我们不敢自己拍脑袋，于是就研究了ISO9126和升级版ISO25010，我们注意到虽然有所变化，但是公有云也并不是不可捉摸的。公有云也是符合指标体系的，但是，更为复杂一些。

第三跳：在关注单一产品之后，我们开始研究产品之间的关系。这个关系我们还没有考虑好如何命名，暂时称之为产品配套。这有些类似标准软件的兼容性或者API，但是更进一步，公有云产品还要调用这些API完成集成工作。这是一个多连接关系，如果仅仅是2个产品的组合，那么就存在C（N，2）个组合，这个是一个巨大的数字，也会带来巨大的研发工作量。想想，为什么一个软件企业几千人都不少了，但是一个公有云公司动辄上万人呢？

第四跳：进一步研究发现，如果仅仅考虑2个产品之间的配套，还是相对简单，但是一旦出现多个产品配套的时候，就不是那么简单了。而且产品配套也存在如果配套设置过多，可能造成维护困难的问题：两两配套是N*（N-1）的复杂度。因此除了少数重要的配套之外，要采用产品编排的方式来定义组合，把难点放到一个地方。这也是AWS上线几年后就推出CloudFormation的一个原因。后来进一步推出了BeanStalk。

第五跳和后面的N-4跳，我们还在不断探索，有希望共同研究、或者加入我们的同行，请给我留言。