黑白色的华为（2）- 窘境

窘境

 

华为公司和外部软件公司，特别是平台软件公司最大差异点是：在华为，软件是硬件的一个部件，是盒子上的一个零件。和一个螺丝钉，一条电路，一个芯片没有任何差别。

 

华为的各级领导对于软件的看法和看待一个螺丝钉，一个电路，一个芯片，一个紧固件一样，对于部件来说，当把一个螺丝钉的强度做到最强，重量最轻，一个芯片性能做到最好，电容做到最稳定，….。最终把每一个零件的有限属性都做到最优，结合“盒子思维”的top-down的设计理念，这个盒子一定不会差。

 

在这样的一个思路下，软件也被拆解成为一个个零件。对于软件的要求就和对一个螺丝钉的要求一样，我们所能看到的基本诉求是： 

l  这个模块是不是性能最高，一般是时延和吞吐量？

l  这个模块是不是比友商的feature多?

l  这个模块的DFX是否合格？

l  这个模块是不是足够安全？

l  。。。

  如果我么做一个图来做一个对照的话，大家看看是不是和一个螺丝钉很类似？

 

 

华为的对软件的整体认知是：每一个软件系统要分解为有限个模块，每一个模块的性能都做到最优，功能做到最多，那么这个软件系统一定是最优的。事实上，华为就是用这样的设计模式和设计理念从一个胜利走向另外一个胜利的。所以，大家对这种思路深信不疑。

 

但是，现在的问题是：在公司从1000亿美元迈向3000亿美元的过程中，这种做法是否还能行得通？在云化，IT化的大潮下，单纯这种模式是否还能支撑公司的未来？这是一个极其宏大的问题，作为一个码农，我无法回答这么宏大和长期的问题。但我们不妨把这个问题稍微缩小为下面的两个问题：

 

1.       公司不断在拷问：2012实验室，各个产品线和BU的软件部门，你们到底做出了什么创新性的软件技术？为公司提供了什么样的核心竞争力。

2.       各个软件部门，各个平台部门越做越累，但是越做越丧失方向感，最后连自己都在疑惑：自己的工作和外包团队有什么区别？

 

这两个在公司内若隐若现，但大家又都心知肚明的两个大问题，几乎就是华为软件的阿琉斯之踵。

 

在巨型公司做平台软件的感觉

 

其实，上述两个问题并不是华为独有的问题，几乎所有大型公司的平台部门，业务支撑部门都面临着类似的拷问。我的同学，同事，同行散布在不同的公司，大家坐在一起的时候，讲起来也都是摇头叹息。Why?

 

原因倒也很简单，我们做一个类比的例子：当一个计算机系毕业的学生进入到了工商银行的话。他最好的结果应该是工行信息处的处长。但是如果是学金融出身的，那么最终的天花板是工商银行的行长了。这个例子的核心是：信息处是支持工商银行业务的，但是不幸的是，工商银行的业务不是IT，是金融。

 

如果从这个来类比华为的话，大家可以很清晰的明白，本质上公司的软件不是他的“业务”。软件部门的作用和工商银行信息处的定位差不多。

 

这几乎是所有公司里软件，平台，公共组件部门的阿琉斯之踵。

 

那么就因为这个阿琉斯之踵，大公司做平台，做软件的部门就没有出路了么？这个问题我们留待后面来做一个探讨。在这里，我先抛出一个问题：颠覆金融行业规则的在线支付体系，支付宝和微信支付为什么不是工商银行信息处做出来的？

 

先放放工商银行，回到我们自己的那两个阿琉斯之踵问题，事实上，这两个阿琉斯之踵难题等价于下面的两个关键问题：

1.       公司对平台软件的定位应该是什么？

2.       什么是软件的创新？

   而问题1更为核心，因为问题2软件的创新一定程度上是和公司对软件本身的定位所决定的。

 

在讨论这两个问题之前，我们再回到上一章我们提到的软件开发和硬件开发之间的差异。我们不妨从硬件的维度来做一些假设来看看软件，可能视角会变得很有趣。

 

我们以芯片行业为例子，芯片行业的集中度越来越高，公司也越来越少，芯片开发的难度越来越大，开发周期越来越长，Why?原因可能会拉出来一大箩筐。但是如果我们做这样的一些假设：

l  芯片投片的周期是一天，也就是今天给出设计，明天能拿到样片。

l  投片一次的价格降低到1美元。

如果这两个假设成立，那么芯片行业会是怎么样的一番景象？是否会出现一日千里的发展速度？会不会有海量的小公司雨后春笋？或者再延展思考一下，如果世界变成这样，华为的芯片部门是否还能保持现有的竞争力？

 

同样，如果我们设计，制作，投产一个硬件盒子也有上面的架设，我们的盒子是否也能保持相应的竞争力呢？

 

大约我们可以得出一个结论，硬件的门槛很大程度上是由于长周期的，海量的前期投入构筑起来的。

 

幸运又不幸的是，软件行业却是一个低投入，低门槛的行业。任何一个软件领域，任何一个做软件的人或者团队。他们面临的竞争对手是：

l google，facebook，microsoft这样员工数以万计，具有软件基因的软件巨头。

l redhat, suse, WindRiver, Vmware这样的领域专业公司。

l 数不清的创业公司。

l 某个或者一群github上的软件偏执狂，重度代码幽闭症患者，code洁癖偏执狂，甚至是Linus这样的粗口王（最近突然转身变nice了）。

   最后，上述的这些公司，团队，个人的数量层出不穷，比如github上的每天都有成千上万的软件上线。

 

当一个软件概念出来的时候，比如service mesh，大约的情况是第一天你听到了这个软件概念，第二天睡醒以后github上已经有超过10个开源项目在进行。第二天晚上刷牙上床的时候已经有超过5个创业公司宣布他们的service mesh上线运行了。

 

在这种堪称光速的软件模式下？我们的软件创新和竞争力定义到底是什么？像华为这样步履蹒跚的缓慢大象如何同体态轻盈的蝴蝶共舞？

 

除了上述的这些矛盾，还有其他很多的问题需要讨论。我们不妨看一下现在公司平台软件部门的生存状况，分析一下他们所处的困境，就这个点出发来开始我们的“软件之旅”吧。

 

平台软件：What’s The Profile

 

   先看看华为软件平台目前的profile是什么样的，或者说在产品业务部门看起来是什么样的profile。千言万语不如一幅图更能说明问题。

 

锦囊的窘境

 

 

  不用解释了，一切尽在不言中。

 

事情是怎么走到这步田地的？我们先还原一下软件部门的生存状态吧，各个软件部门的工作大约流程是这样的：

 

1.    年初开始拜访各个业务线，姑且我叫做拜访，实际过程我感觉更像是化缘，挨个敲门问：你们需要点啥？

2.    业务线扒拉扒拉口袋，掏出两个锦囊，递给软件部门。

3.    软件部门拆开一看：一个锦囊里是一张去年的欠条，上面写着：我的秘籍能帮你干掉xxx，统治世界。另外一个锦囊里面写着：下水道总是堵，能每天过来通一通么？

4.    经过一番argue，最后两边达成一致：欠条继续欠着，不过一个月过来通一次下水道。

5.    年底，两边一起向公司汇报，我们在征服世界的道路上又前进了一大步。

6.    下一年初，goto 1

 

不论是从外面工业界招聘的好手，还是从学术界来的教授，亦或是从业务线调来的业务能手，最终都不可避免的走到了这条道路上。Why? 结合我前面讲的软件和硬件的差别。我们大约可以看出一些门道。

 

软件本身由于快速演进的特点，软件没有秘密可言。这是一条非常重要的法则。这个法则就如同任何物体的运行速度都没有办法超过光速一样在软件行业内通行。

 

总体来说，我在华为的体验是，公司希望一个个软件作为零件，能做出别人做不出来的功能和特性。这些功能和特性也许在领导的想象空间中是一堆逻辑复杂，拥有数学基因的神秘代码。我只要守住这些代码不让别人知道，我的软件能力就可以独步天下。可不幸的是，似乎软件竞争力的本质不是这样子的。

 

通常讲到这一点的时候，有人会拿出Oracle和Vmware这样的软件来反驳我。但实际上，oracle已经是30多年前的作品了，vmware也有20年的历史了，并不是现在人做不出来，而是oracle，vmware所在的传统IT领域已经没有空间容纳第二家厂商了，或者这么讲，市场空间不足以让华尔街的投资人打起精神来了。从创新的角度来说，反而是互联网巨头在数据库领域做出了很多新颖的创新。而传统如oracle自己反而在自己擅长的领域举步维艰。

 

所以，当公司要求软件进行超光速时空旅行的时候，锦囊之策也就毫不奇怪了。

 

对于这种说法有不少人也还是不同意，毕竟公司的软件配套公司硬件系统在过去的20年里披荆斩棘，攻城略地，怎么这个总结似乎一棍子打死了呢？

 

上面的锦囊描述只是说明我们现在面临的窘境，但是不否认软件助力产品攻城略地。软硬件一体化设计达到性能极致本身是一个很好的工作，也是难度很大的工作，是一个高级活，但是问题的核心是：

 

为啥这个活只有你能做？别人做不了？对于一个具体的软件feature或者是性能指标，难道产品线自己雇人不能做？我们外包给一些外部专业公司不能做？核心是要分清“因为这个任务分给我干了，所以我成功了，还是因为我干了产品线干不了，外部公司干不了的事情所以我成功了”。

 

那么问题又来了，软件方面，啥是产品线干不了的事情呢？这个问题我们先放一放，留待后面来讨论。我们先讨论除了锦囊窘境以外的另外一个窘境：人力陷阱。

 

人力陷阱

 

产品线和平台部门很大的分歧点是：平台为什么养了那么多人，而且越来人越多，最后支撑还是不让我满意。除去华为评级体系的导向就直接导致各级主管都有无穷的动力去扩张队伍（全公司皆是如此）以外。人力陷阱这个问题的始作俑者恰恰是业务部门本身而非平台部门。大体的过程如此：

1.    业务部门：市场上有一个需求了，对手现在性能是xxx，我们要求超越对手30%,挑战100%，平台部门要满足xxx条件。

2.    平台部门：我们是平台部门，需要保证分层解耦，不能接太多的定制需求。

3.    业务部门：不达成目标，性能不提升XXX，如何体现竞争力，那你们和我们到外面引入一个第三方的软件有什么区别？和我们用开源有什么区别，你们这帮高端砖家是干什么吃的？

4.    平台部门：好吧，常规手段肯定不行了，只能定制了。甚至是从分层模式改为紧耦合模式了。这个开发量要xx人力

5.    业务部门：给，给，给。

6.    Goto 1 day by day.

7.    一年后：软件部门：那个xx特性还需要维护，要xx人

8.    业务部门：为啥我还要投钱。

9.    软件部门：管生不管养呀？没人投入出了问题我找谁去？最少我得保证开发这些xx的人当你出问题的时候还在公司呀。你们不是要升级么？这么多特性我不得移植么？

10. 吵架

11. 不欢而散。

12. Goto 1 Day by day

 

周而复始，平台部门积累了一大堆“特性”“竞争力”，随着产品线的一代代产品迭代，平台部门自己软件的更新换代。这些特性和竞争力对所有人都成为了巨大的负担。但是产品生出来了还要养活呀，这样一来，从业务部门到平台部门的人力需求越来越大。最后所谓的平台部门，实际上微观上是一个个产品线，一个个盒子的配套零件，不同的盒子，不同的产品线之间的共性越来越少，最后都变成了一个个垂直的烟囱。

 

每一根烟囱下面都矗立着一大票工程师和团队。

 

最开始进入华为，我很惊讶平台部门的人力规模，因为我从来没有见到过这么多的工程师。但是后续我逐步理解了：工程师确实不够用。以OS团队为例，就算把Redhat + SUSE + WindRiver的工程团队都搬过来，也不够用，而且是真的不够用。怎么能够用呢？华为的目标是ICT基础设施，连接全球，端管云芯片全覆盖，后续还有车。各位发挥一下想象力，有多少根烟囱需要树立起来，需要多少平台工程师？

 

这几乎是一个死结，成也萧何败也萧何。就像福尔摩斯探案揭秘出最终的凶手就是福尔摩斯本人一样。

 

甚至更为严重的是，业务线和平台部门有时候会在某种程度上达成了一种微妙的默契。业务部门乐于提出一些夸张的指标（没人知道这些东西在市场上有用没用），平台部门乐意去接受这种定制化开发，既是自己的舒适区，又能配合讲故事。皆大欢喜。

 

锦囊窘境和人力陷阱是两个困扰软件部门两个最大的issue。但这两个issue却又是支撑了华为之前20年技术领先的基础。我为什么用英文issue是实在找不出来合适的词语来表达。这两个issue并不是problem，他们并不完全是不合理的，硬件开发的先天属性要求就会导致这种问题的发生。但是这种issue的膨胀又会极大阻碍公司的成长，导致产品线和平台部门冲突不断，互相指责，各自都有一肚子苦水，部门墙越来越厚重。

 

Issue明确了，但是生活总要继续，我们不妨先看看其他软件公司的一些做法，从中看看是否可以有一些解题的线索。就从我最熟悉的WindRiver公司说起吧，从我对如何做平台软件的逐步认识开始吧。它山之石