集中力量办大事的软件交付方式

前段时间听到某些组织是这样做决策的：

1.大大大大领导决定做一个平台2.大大大领导“心领神会”后，思考平台要解决的问题3.大大领导拿到“方向”后，进行业务分析4.架构师根据业务分析的结果进行架构分析设计5.PMO开始制定计划6.程序员开始写代码、设计师开始设计界面……

边听别人的描述，脑海边浮现“集中力量办大事”的场景。经过这样的交付出来的软件经常被用户骂，但是又不得不用。各位读者是否感同深受？

这样的场景在我的身边经常以不同的形式出现：

1.一个刚入职的同事听说我是做DevOps的，就问我要不要做一个DevOps平台；2.在一个ToC的平台需求会议上，经常出现这些的话术：领导觉得这样好、领导说要一个平台等等。

我从《SRE：Google运维解密》书中了解到一个案例：Auxon。它是Google内部基于意图的容量规划和资源分配解决方案，用于规划谷歌数百万美元的机器资源。然而，Auxon一开始只是一个SRE工程师和一个技术项目经理想象出来的。

image.png

他们分别被各自的团队委以重任，负责对谷歌的大部分基础设施进行容量规划。一开始还使用电子表格手动的进行容量规则。正因为这样，他们拥有大量的一手低效率经验。

两年的时间里，SRE内部的一小群工程师和一个技术项目经理持续的开发Auxon。Auxon开发过程中，他们即是Auxon的消费者，也是生产者。

Auxon并不是两年前领导决定搞一个平台后立项出来，而是从两年前一个（些）工程师决定解决眼前的低效率问题的第一行代码开始的。

由于“SRE”书中并没有交待过多的细节，但是已经很能体现思维方式上的不同。

那么，本文的意思是让我们学谷歌Auxon的案例吗？我的答案是否定的。每一家公司所处的文化、思维方式都不一样。我只是想告诉大家，世界上还有另一种软件交付方式。它可能与你大脑中的观念不一样。

如果你刚好是Auxon案例中的工程师，又刚好处于“集中力量办大事”的文化中，我建议你可以考虑先立个项。

欢迎关注 持续交付实践指南 公众号