技术与商业案例解读
徐飞
华为云资深总监,大数据专家
立即订阅
10163 人已学习
课程目录
已完结 163 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 突破技术思维,站在商业的角度看问题
免费
001 | 西雅图IT公司之RealNetworks:一个帝国的兴衰(上)
002 | 西雅图IT公司之RealNetworks:一个帝国的兴衰(下)
003 | 以RealNetworks为例,谈谈初创公司如何应对巨头碾压
004 | 可视化分析鼻祖Tableau
005 | 从Tableau上市,看学术界和工业界人士创业
006 | 在线旅游帝国Expedia崛起的背后
007 | 房产经纪的颠覆者Redfin:在“传统”与“现代”间徘徊
008 | 房产经纪的“协作者”Zillow:一个地产数据平台
009 | 颠覆还是协作,房地产市场上Redfin和Zillow的抉择
010 | 应用交付网络大厂F5:“一招鲜”之殇
011 | 在线差旅报销鼻祖Concur:在转型中获得发展
012 | 漫谈企业转型:在市场变迁中寻找生机
013 | 克雷公司沉浮录:行走在超级计算机市场
014 | “单一化”的隐忧:从克雷公司看“一条腿走路”
015 | Halo的开发者Bungie:与微软的聚散
016 | “卖身”须谨慎:创业公司面临的抉择
017 | 亚马逊领导力准则之要有硬骨头
018 | 亚马逊领导力准则之决策正确
019 | 亚马逊领导力准则之客户至尚
020 | 亚马逊领导力准则之勤俭节约
021 | 亚马逊领导力准则之主人翁精神
022 | 亚马逊领导力准则之选贤育能
023 | 亚马逊领导力准则之最高标准
024 | 亚马逊领导力准则之创新简化
025 | 亚马逊领导力准则之崇尚行动
026 | 亚马逊领导力准则之远见卓识
027 | 亚马逊领导力准则之好奇求知与赢得信任
028 | 亚马逊领导力准则之刨根问底与达成业绩
029 | 智能音箱的战斗:亚马逊的硬件路
030 | 智能音箱的战斗:Echo攻城略地
031 | 智能音箱的战斗:语音助手Alexa
032 | 智能音箱的战斗:谷歌的杀入
033 | 智能音箱的战斗:亚马逊的战略布局
034 | 智能音箱的战斗:巨头纷纷入场
035 | 智能音箱的战斗:白马非马
036 | 如何透过一个领域去联合分析多家企业?
037 | 管中窥豹之从面试看企业文化:微软
038 | 管中窥豹之从面试看企业文化:亚马逊
039 | 管中窥豹之从面试看企业文化:谷歌
040 | 管中窥豹之从面试看企业文化:甲骨文
041 | 管中窥豹之从面试看企业文化:Facebook
042 | 透过企业用人之道看企业发展
043 | 办公软件的战斗:开篇
044 | VisiCalc:第一个电子表格软件的诞生
045 | WordStar:第一个字处理软件的故事
046 | 微软:办公软件战场的螳螂
047 | WordPerfect:字处理软件的新秀
048 | Lotus 1-2-3:莲花公司的电子表格帝国
049 | 红狮会战:微软的反击
050 | 大杀器Lotus Notes 和被收购的莲花公司
051 | 无敌寂寞的微软之为创新而创新
052 | 办公软件的新时代:微软和谷歌的战斗
053 | 异军突起的Slack
054 | 办公软件战斗的启示:内忧总是强于外患
055 | 办公软件战斗的启示:敌人的出现常常出其不意
056 | 半条命的Dota帝国Valve:半条命
057 | 半条命的Dota帝国Valve:Steam平台
058 | 半条命的Dota帝国Valve:Dota 2
059 | 半条命的Dota帝国Valve:无领导管理
060 | 半条命的Dota帝国Valve:虚拟现实
061 | Gabe Newell:Valve帝国制度的利弊
062 | 文档数据库的缔造者MongoDB(上)
063 | 文档数据库的缔造者MongoDB(下)
064 | 以MongoDB为例,看基础架构类产品创业
065 | 直面MongoDB,谈微软的NoSQL战略
066 | Hadoop三国之魏国Cloudera
067 | Hadoop三国之吴国MapR
068 | Hadoop三国之蜀国Hortonworks
069 | Hadoop及其发行商的未来
070 | 谷歌的大数据路:从“三驾马车”到一无所有
071 | 谷歌的大数据路:一场影响深远的论战
072 | 谷歌的大数据路:谷歌的“黑科技”
073 | 如何读懂类似谷歌“三驾马车”这样的技术论文?
074 | 雅虎:大数据领域的“活雷锋”
075 | IBM的大数据路之起早贪黑赶了晚集
076 | 社交公司们的大数据贡献
077 | 微软的大数据发展史:微软硅谷研究院
078 | 微软的大数据发展史:必应的Cosmos
079 | 微软的大数据发展史:Azure的大数据发展
080 | 亚马逊的大数据故事:从先驱者到插管吸血开源
081 | 亚马逊的大数据故事:创新和拿来并存的云服务
082 | 阿里巴巴的大数据故事:数据分析平台发展史
083 | 阿里巴巴的大数据故事:流计算引擎发展史
084 | 大公司的大数据战略得失:自建轮子成本高
085 | 大公司的大数据战略得失:抱团取暖难敌插管吸血者
086 | Palantir:神秘的大数据独角兽
087| Splunk:机器大数据的分析帝国
088 | Confluent:在Kafka上飞驰的数据交换者
089 | Powerset:HBase的老东家
090 | Cassandra和DataStax的故事
091 | Databricks之Spark的数据金砖王国
092 | Data Artisans:浴火重生的新一代大数据计算引擎Flink
093 | Dremio:在Drill和Arrow上的大数据公司
094 | Imply:基于Druid的大数据分析公司
095 | Kyligence:阿帕奇麒麟背后的大数据公司
096 | Snowflake:云端的弹性数据仓库
097 | TiDB:一个国产新数据库的创业故事
098 | 大数据创业公司的前景:红海创业多艰辛
099 | 如何通过企业技术积累去分析一家企业?
技术与商业案例解读
登录|注册

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

徐飞 2018-08-22
陆奇在就职于微软的那几年里,于微软内部进行了一次意义深远的综合工程师改革。这场改革,起始于陆奇领导的 Online Service Division,经过若干年的努力后终于在全公司范围内实施,并对微软以后的发展产生了不可估量的影响。今天我就来聊聊这场改革。

改革背景

微软功成名就的年代里,正是个人计算机的软件行业飞黄腾达的年代。
微软最初是以“软件帝国”而知名。那时互联网才刚刚开始,软件的分发形式一开始是主销软盘的,后来又以光盘为主,这种传播方式对软件开发提出了很多要求,而这些要求里面最重要的有两个。
首先,软件发行不可能太频繁。微软的平均软件开发周期是三年。这也可以理解。如果发行太频繁了,用户肯定也不愿意买。
其次,在软件不能发行太频繁的前提下,必须注重客户需求和软件质量。前者意味着每次大版本的升级,都需要顾及到很多客户进一步的需求。后者意味着软件在卖出去的时候,本身必须已经通过了严格的测试,不会有什么严重的 Bug 出现了。因为严重的 Bug 往往会导致不得不召回所有的软盘、光盘,这种代价是非常巨大的。
为了应对上述要求,微软培养出了一套非常成功的、并且有自身特色的软件开发模式:人事上的三权分立。
在微软里面,有三种不同的角色:开发、测试和项目经理。和其他公司不同的是,微软是真正意义上的三权分立。这三种角色在公司里面并行存在,级别一路可以到副总裁。最后三个副总裁再汇报给一个部门的总负责人,比如 Online Service Division 的陆奇。在微软内部,部门负责人数目是个位数。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《技术与商业案例解读》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • 有铭
    啊,闹了半天微软开掉测试人员导致win10 bug成灾的根源在陆奇这啊。业界一直说是阿三CEO上台导致的
    2018-10-27
    5
  • 顽石
    这种改革难道不应该只针对需要快速迭代的部门么,对于传统软件,虽然也可以通过升级包更新,但是质量的要求还是不一样的,只能说部分功能可以慢慢加,但是不应该降低测试力度
    2018-08-22
    5
  • 拉欧
    测试失业不能说是陆奇的锅吧,在这个时代,只会一门技术本来就是很恐怖的事情

    作者回复: 我们都觉得是他的锅

    2019-06-12
    2
  • 夜空中最亮的星(华仔)
    好悲伤,最后去了卡车司机。
    2018-12-10
    1
  • 演绎人
    我已经在送外卖的路上了!
    2019-10-19
  • 修心时
    温水煮青蛙
    2019-01-16
  • joseph.herder💭.
    不同类型项目用不同方式。另外问下飞哥:微软的技术经理,项目经理,产品经理有合并吗?
    2018-08-26
收起评论
7
返回
顶部