历久弥新 - 微软万亿市值背后的文化支撑（上）|DevOps案例研究 - DevOps案例

摘要：微软更像是由很多小型快艇组成的快速反应部队。实际上，微软内部的敏捷转型早在2007年就已经开始初见萌芽。

内容来源：DevOps案例深度研究-Microsoft文化支撑研究战队（本文只展示部分PPT研究成果，更多细节请关注案例分享会，及本公众号。）
本案例内容贡献者：陈飞（Topic Leader）、陈雨卿、郭子奇、刘晨胜、善园林、赵英美、周银燕
本次案例解读：徐磊

devops-micrsoft-1

“墓有重开之日，人无再少之年。”这句话对于一个人来说是多么的无奈，但对于一家企业而言却不是不可能。微软这样一家44岁已经步入中年的公司，能够在不惑之年取得万亿市值，迎来第二春，看上去好似非常轻松，却也让很多目光盯住互联网公司光环的人大跌眼镜......

凭什么这样一家已经“过时”、“臃肿”、“毫无创新”的公司能够超越光鲜亮丽的苹果、才华横溢的谷歌和充满睿智的IBM，实现万亿市值？微软到底是凭借什么实现了自己的华丽转身？这恐怕是每个人都想要探寻的问题。

上图是从2014年至今，微软、苹果、谷歌和IBM的市值比较。其实大家都只看到微软今天的万亿市值，却没发现这个趋势在2014年就已经逐渐明晰了。这中间到底发生了什么，就是我们这次“历久弥新-Microsoft文化支撑”案例研究希望帮助大家回答的问题。

什么是企业文化？

企业文化是很多企业管理者经常挂在嘴边的一个词，也是我们在谈论DevOps、敏捷和精益的时候都不可避免触及的一个话题。但到底什么是企业文化？如果对这个问题的理解有偏差，恐怕很多的讨论都会变成无根之水。

艾德佳·沙因（Edgar Henry Schein）是美国麻省理工大学斯隆商学院的教授，我们在案例研究的过程中发现，他针对企业文化的三个层次的描述是最准确的。在组织文化领域中，他率先提出了文化本质的概念，并对文化的构成因素进行分析，对文化的形成、文化间的转化过程提出了独到的见解。

沙因将组织文化分为以下三个层次

1）人工制品（Artifact）
人工制品是那些外显的文化产品，能够看得见、听得见、摸得着（如制服），但却不易被理解。

2）信仰与价值（Espoused Values）
藏于人工制品之下的，便是组织的“信仰与价值”，它们是组织的战略、目标和哲学。

3）基本隐性假设与价值（Basic Assumptions and Values）
组织文化的核心或精华是早已在人们头脑中生根的不被意识到的假设、价值、信仰、规范等，由于它们大部分出于一种无意识的层次，所以很难被观察到。然而，正是由于它们的存在，我们才得以理解每一个具体组织事件为什么会以特定的形式发生。这些基本隐性假设存在于人们的自然属性、人际关系与活动、现实与事实之中。

对于第一个层次-人工制品，其实非常好理解，一个企业的员工制服、企业的logo、主视觉颜色等都构成了这些看得见、摸得着的东西。
而第二个层面的表现就要依赖企业价值观来解释，这个价值观在企业文化中经常会表现为一句口号，比如：微软曾经的口号是“让每个家庭的桌子上都有一台计算机”，而当前微软的口号则是“予力全球每一个人，每一个组织，成就不凡”。这种口号上的变化，会直接带来企业的表现变化。对于微软来说，之前的重点在于Windows、Office等软件产品的销售，而现在的微软则是采取“云为先”的策略。
以上两个层次都还比较容易理解和观察到，最后一个层次就不是那么容易理解了。我们不妨将这第三层简单理解为“假设”，也就是组织成员互相沟通的时候那些无需表达、沟通即可达成的共识。而这些，才是一个企业真正的属性。“在微软，这个基本假设是什么”就是这篇案例研究将为你揭示的核心。

康威定律

devops-micrsoft-5

这是一张非常经典的对比不同企业的不同文化特点的图，不必仔细琢磨，大概一眼就可以体会到这些不同组织之间的做事方式。

康威定律也是我们在谈论组织变革的时候经常谈到的，简单来说，就是：有什么文化就有什么组织结构，有什么组织结构就有怎样的系统架构。

相比于其他组织，微软最显眼之处就在于不同部门之间的那几把枪，这种各自为战的状态即便到了今天纳德拉时代的微软也仍然存在。

在大多数人看来，这恐怕是微软最大的问题，而事实也确实如大家所看到的，这确实造成了大量的内耗。但从另外一个角度来看，这也为微软转型创造了机会，这一点后续会有详细说明。

大瀑布时代的微软

对于做DevOps的人来说，看到“瀑布”这两个字几乎是直接排斥的，因为DevOps以敏捷为根基，而敏捷提倡的是小步快跑、持续迭代。从这个角度来看，大瀑布时代的微软似乎没有什么值得我们借鉴的，那么我们就来分析一下2010年以前微软的做事方式。

devops-micrsoft-6

这个时代最典型的产品是Windows，从Windows的第一个成熟版本3.1开始，一直到Windows7，都是以这种模式进行开发的。每个版本都需要经历多个Milestone，每个Milestone中需要完成从特性的构思、任务计划、开发、测试/稳定到版本发布/部署的整个生命周期。

你也许会发现，这个大瀑布时代的产品开发模型其实已经有了一定的迭代概念，只是每个迭代的周期相对敏捷的模式要长得多，会有3-4个月之久。

要说微软历史上最失败的产品，Windows Vista一定会位列其中。但很多人不知道的是，Vista在长达5年的研发过程中，经历过一次完全的项目重置。

当时参与项目的工程师在安装了前一天的daily build之后，发现整个产品恢复到原来XP的样子，所有人都被吓呆了，以为系统出了问题。但当他们联系总部的工程师后才得知，原来是由于整个产品运行过于缓慢而被整体重置。当时的Windows开发工程师过于追求技术上的先进性，在内核中添加了太多的功能，使得整个系统运行极其缓慢，不得不推倒重来。

在这个故事的背后隐藏了一些大家不太注意的事实，那就是Windows团队当时的工程实践就算在现在看来也已经是非常之先进，比如：

Windows的所有代码均会有自动执行的Daily Build来构建最新版本，测试人员第二天就可以拿到头一天的版本进行测试；
Windows几乎所有的代码都可以通过自动化测试进行验证；
Windows使用了非常成熟的分支管理机制，同时在分支上启用了持续集成(CI)策略，所有开发人员签入的代码均会触发自动化构建，并执行BVT(Build Verification Test)测试，也就是单元测试。

以上这几点恐怕是现在很多团队仍然无法做到的，但微软于2002年就已经在Windows这样规模的系统级软件上全面实现了这样完备的工程实践，可见软件工程是深深烙印在微软文化深处的基因记忆。

微软另外一个失败的产品当然就是Windows Mobile和Windows Phone系列手机及其系统，这些故事相信大家都早有了解，本文就不再多作赘述。

这里不得不提到一位大神级人物Sinofsky，因为就是他叫停了不断变得臃肿的Vista，让这个产品可以最终上市；也是他在暴怒的鲍尔默面前力挽狂澜，才使得Windows Phone 7可以最终面世。虽然这些都阻挡不了这两款产品位列微软最失败产品的首位，但我们也同样不能忽视微软在开发这两款产品的过程中的优秀工程实践。

Windows Vista 的失败在于过于激进的技术，而Windows Phone的失败则是零和博弈的结果。这些市场上的失败也让微软内部开始重新审视自己的很多做法，更为先进的实践也开始逐渐萌芽。

敏捷在微软萌芽

上面的2张图片来自于2015年Steven Denning发布于福布斯杂志的2篇文章：《惊讶：微软是敏捷的》和《微软规模化敏捷的16点核心实践》。在来自Scrum联盟的研究小组进入微软进行调研之前，大家都以为微软这家拥有12万名员工的公司是一艘巨型战舰，而经过调研后，小组成员惊讶地发现，微软更像是由很多小型快艇组成的快速反应部队。实际上，微软内部的敏捷转型早在2007年就已经开始初见萌芽。

早期阶段微软内部敏捷转型的一个典型团队是Visual Studio开发工具团队，也包括微软DevOps工具链（当时叫做Team Foundation Server，现已改名为Azure DevOps）。下图是2013年Visual Studio产品交付周期的统计数据。

devops-micrsoft-11

可以看到，从2012年开始，Visual Studio 就将原来2-3年的版本发布周期缩短至3个月，同时TFS的在线版本（也就是现在的Azure DevOps的前身）的发布周期缩短为3个星期。

你需要知道的是，VS团队有近5000名开发人员，整个产品完成一次Full Build需要8个小时的时间，在这样规模的产品上将发布周期从2-3年降低到3周，这样的敏捷转型无论是从管理流程上还是工程实践上都是巨大的考验。

更何况Visaul Studio并不是什么无关紧要的产品，它支撑着包括Windows、Office在内的微软主要产品的研发，这些产品的每日构建量在2013年就已经高达3万次以上。到了2018年，这一数字竟然到了惊人的78000次/每天，而且不仅包括构建，还包括产品部署，因为这个时候微软的产品形态已经全面转向云端。

参考资料

https://www.barryovereem.com/microsofts-agile-transformation-journey/
https://www.forbes.com/sites/stevedenning/2015/10/27/surprise-microsoft-is-agile/#1efc856a2867
https://www.forbes.com/sites/stevedenning/2015/10/29/microsofts-sixteen-keys-to-becoming-agile-at-scale/#583c8c7115ce
https://stories.visualstudio.com/scaling-agile-across-the-enterprise/
https://stories.visualstudio.com/devops/#