139 | 微软的综合工程师改革

Aug 22, 2018

139 | 微软的综合工程师改革-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

139 | 微软的综合工程师改革

2018-08-22 徐飞来自北京

《技术与商业案例解读》

课程介绍



讲述：秭明

时长07:27大小4.63M



陆奇在就职于微软的那几年里，于微软内部进行了一次意义深远的综合工程师改革。这场改革，起始于陆奇领导的 Online Service Division，经过若干年的努力后终于在全公司范围内实施，并对微软以后的发展产生了不可估量的影响。今天我就来聊聊这场改革。
改革背景微软功成名就的年代里，正是个人计算机的软件行业飞黄腾达的年代。
微软最初是以“软件帝国”而知名。那时互联网才刚刚开始，软件的分发形式一开始是主销软盘的，后来又以光盘为主，这种传播方式对软件开发提出了很多要求，而这些要求里面最重要的有两个。
首先，软件发行不可能太频繁。微软的平均软件开发周期是三年。这也可以理解。如果发行太频繁了，用户肯定也不愿意买。
其次，在软件不能发行太频繁的前提下，必须注重客户需求和软件质量。前者意味着每次大版本的升级，都需要顾及到很多客户进一步的需求。后者意味着软件在卖出去的时候，本身必须已经通过了严格的测试，不会有什么严重的 Bug 出现了。因为严重的 Bug 往往会导致不得不召回所有的软盘、光盘，这种代价是非常巨大的。
为了应对上述要求，微软培养出了一套非常成功的、并且有自身特色的软件开发模式：人事上的三权分立。
在微软里面，有三种不同的角色：开发、测试和项目经理。和其他公司不同的是，微软是真正意义上的三权分立。这三种角色在公司里面并行存在，级别一路可以到副总裁。最后三个副总裁再汇报给一个部门的总负责人，比如 Online Service Division 的陆奇。在微软内部，部门负责人数目是个位数。
微软不仅有非常庞大的开发队伍，同时还有非常庞大的测试队伍和项目经理队伍。这三者构成了微软在“软件帝国”时代的软件研发模式，且各自都有着庞大的群体和诉求。在这个“软件帝国”里，办公室人际关系错综复杂，而微软的三权分立的架构，给这里的办公室政治带来了更为复杂的设定。比如说，项目经理、测试和开发这三组人出现分歧时，到底应该谁听谁的呢？
开发模式的弊端进入互联网发达的时代以后，这个开发模式的优势逐渐失去，不仅如此，其弊端还越发凸显出来。
单纯从传统软件的开发来看，软件的发布不再需要每次都寄光盘了，因为互联网下载也是一个选项；软件的测试不需要那么仔细了，因为发布补丁让用户通过互联网下载安装这个事情也是可行的；软件的发布也不需要那么久了，很多功能完全可以一边开发、一边发布。
相对于软件公司来说，互联网公司对测试的要求比较低。哪怕有什么问题没有测试出来，软件更新的成本也非常低。
作为必应搜索引擎的开发部门，其运作方式是互联网公司的方式，对测试要求很低。而陆奇到来的时候，见到的却是一个三权分立的、测试人员很多的传统软件公司开发团队。这个团队效率低下，产品难产，一年才能发布一次。
大量的测试人员在微软的其他机构，是软件品质保证所必须的。但是在这个互联网公司运作模式的必应开发部门，确是冗余人员和效率低的代名词。所以陆奇的改革势在必行。这些庞大的测试队伍必然首当其冲。
综合工程师改革用一句话总结这次微软的综合工程师改革，那就是：把微软整个测试的部门和开发部门合并，只剩下开发和项目经理两个组织；而测试和开发人员合并以后，每个人就既要负责测试又要负责开发。
这个做法当然是非常有难度的。因为测试组织在微软根深蒂固，是自从微软诞生以后就有了。而且不同于其他公司，微软的测试组织是完全独立的，并且里面的关系盘根错节，有无数既得利益者。
陆奇选择在他的 Online Service Division 推广这个改革。因为必应搜索引擎如果只能半年一次小的发布、一年一次大的发布的话，那等到发布出来后“黄花菜都凉了”。为了让必应搜索引擎能够正常的发展，陆奇的这个改革势在必行。
陆奇的做法是先选了他的地盘 Online Service Division 下面的一个铁杆部门开始试点。因为他知道这种试点的压力很大。在铁杆部门获得成功后，陆奇又陆陆续续推广到 Online Service Division 的其他部门去。最终用了两年时间，整个 Online Service Division 的测试和开发就完全合并了。
在 Online Service Division 推广以后，陆奇又得到了整个微软高层的支持，把这个改革在整个微软推广开来了。这个改革虽然说静悄悄的，但是对微软的影响却是深远的。
改革的影响此次改革最大的影响是：微软的开发再也不需要经过那么繁琐的测试历程，软件的发布迅速了很多。这对微软无疑是非常重要的一步。后面微软能够在云计算上迅速推进，就和微软的这次悄无声息的改革是有很大关系的。
但此次改革带来的影响也不完全是积极的。
改革的副作用之一是变相地大量裁撤了测试人员。这些测试人员是微软招进来专门给软件做测试的。其中很多人在微软 20 来年里，唯一会的技能是使用微软内部的工具和手动测试软件。
作为测试人员，这些人是很高效的。但是当他们和开发人员合并以后，绩效考评自然而然就排在了末尾。很多人就因为连续两次绩效考核不合格，被微软开除了。我认识一个在微软工作了 17 年的测试人员，就是在这次改革中离开了微软。离开微软的他因为技能落后找不到软件开发工作，最后成为了一个卡车司机。
而测试人员的裁撤也产生了另外一些副作用。一些基础软件，比如 Windows 和 Visual Studio 等等，其实是需要很认真测试的，尤其需要专职人员的测试。但是因为此次机构改革，测试人员的话语权也失去了。和过去的微软比起来，这些软件普遍都没有认真测试够。
近两年来这些软件质量下降是有目共睹的。前段时间甚至还出现了微软发布的一个补丁导致机器蓝屏无法恢复只能格式化的“囧事”，若在早年，因为有充足的测试人员进行充分的测试，这种事情是不会发生的。
总而言之，这场改革对微软的影响是深刻而深远的。微软轻装上阵，为新时代的到来做好了准备。但是同时你也可以看到，这个改革有点矫枉过正了，出现了“很多软件质量下降、Bug 增多等”改革副作用。
测试人员作为三权分立的机构之一正式退出了微软。整个事情的发展过程中，最叹惋的无疑是那些被改革所淘汰的测试人员。他们毕生都贡献给了微软，却被微软辞退，又因为技能单薄，找不到下一份工作。这些人最终落入这样的局面，是微软的锅，是这些人自己的问题，还是时代变迁必然的产物呢？

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 2

提建议

138 | 企业不上市为哪般

140 | SaaS先驱Salesforce

 写留言

精选留言(10)

有铭
2018-10-27
啊，闹了半天微软开掉测试人员导致win10 bug成灾的根源在陆奇这啊。业界一直说是阿三CEO上台导致的
7
佳伦
2018-08-22
这种改革难道不应该只针对需要快速迭代的部门么，对于传统软件，虽然也可以通过升级包更新，但是质量的要求还是不一样的，只能说部分功能可以慢慢加，但是不应该降低测试力度
6
拉欧
2019-06-12
测试失业不能说是陆奇的锅吧，在这个时代，只会一门技术本来就是很恐怖的事情
作者回复: 我们都觉得是他的锅
4
长发姑娘
2020-08-13
改革过于激进，短期内可以看到一些改变，对长期的伤害却不能及时暴露出来。微软这样的大公司，本来就是船大难掉头，加上这种激进的操作方式势必会出现“翻船”的可能，平稳过渡也不是不可以。逐利是资本的天性，保护弱者却是人性的光辉，慢一点也许就不会造成很多人的悲剧。
1
Jxin
2020-05-23
1.无论是微软的测试部门还是目前各个互联网公司的业务测试工程师。技能单薄都无可厚非。因为在这样一个工作范围内，把活干好干棒，本身就很容易造成个人技能单薄的结果。而扩展自己技能槽，把自己武装的面面俱到，很多时候是牺牲把工作做到更好换来的。 2.所以，合并部门没毛病，但过度粗暴，把真正能保证质量的老手以不合理的衡量标准同其他混子一起清楚，无论是微软还是员工个人都是一种损失。毕竟微软在栽跟头前可能连自己损失了什么都不知道。而忠心于业务的优秀测试公司，脱离这块业务后，跟混子也没太大差别。
展开
2
夜空中最亮的星
2018-12-10
好悲伤，最后去了卡车司机。
1
武塘
2019-12-27
做IT岁数大了之后怎样才不会被淘汰，是个难题
演绎人
2019-10-19
我已经在送外卖的路上了！
修心时
2019-01-16
温水煮青蛙
joseph.herder💭.
2018-08-26
不同类型项目用不同方式。另外问下飞哥：微软的技术经理，项目经理，产品经理有合并吗？

