微软的管理模式真的值得吹嘘么？
最近有个叫人月神话的博客写了一个吹嘘微软管理艺术的博闻。这篇看似美好的文章，被CSDN誉为“最佳实践”。我对这篇博闻的评论只有一个字—Naïve！！我在微软做合同工做了一年；随后进入一个小公司里为微软搞了一个外包项目；然后又进入微软作了两个月的咨询。我对微软内部的管理是有了解的。微软的管理模式真的值得吹嘘么？我的答案是“不能。”答案显而易见，Windows Vista延迟了几次了就说明微软的管理模式有极大的问题。
“微软的三个阶段更像是风险驱动的、渐进的“螺旋”式的生命周期模型” 这个观点真如人月神话所说的么？非也！以我在微软搞Windows Vista MUI API测试的经验来说，微软的周期性（或里程性）开发周期更像变态的流水设计模式（Water Fall）。冠其变态是因为它的属性不伦不类，它既不像周期性（或里程性）开发模式，又不像标准的流水设计模式。想象这么一个小组，在周期前期写好了一个Vista部件的设计构思，到了周期末，等到设计变成程序后，测试才能赶上进度，随后测试发现这个设计往往不可行，怎么办？下个周期整个设计会被推翻，从头再来。这就是为什么Vista会一直推迟。每个部件至少重新设计两次到三次。“一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化”是根本不可能的，因为微软中各小组设计的东西都非常复杂，性能太多，测试往往没有时间将所有的性能所有重的边角条件（Corner Case, Boundary Conditions）都测试到。所以测试根本不能在一个固定周期里查找所有的问题，给设计周期1/3的时间进行稳定化。事实上，很多公司都有这种问题。
微软的设计组在设计一个部件的时候往往会花费太多的时间在计划书的写作上，不同于人月神话所说的那样“运用想象性描述和对特性的概要说明指导项目”，一个项目的设计往往要先进行细化性的计划书的写作，所有的细节都将在计划书列出来，然后才能进行程序设计。我听说有人花费三个月在写计划书上。这不是玩笑，我加入那家小公司后，一个大头跟我说的。当时我的下巴掉了三分钟合不上。微软可能有过写粗略计划书要越短越好，尽量说明产品不做什么。但是经常出现的是产品究竟做些什么不出现在计划书中，结果测试发现某些界面函数的行为不对，却不知道这些界面函数的标准行为是什么，原来管理层认为某些行为是标准行为，而开发者则认为自己认为的行为才是标准行为，结果开发者自以为是地编写了函数的行为。然后测试向高层报告程序异常，然后高层通知开发者进行更改，开发者反而回击高层的决定。最后大家开会，一开两小时，哪个嗓门大，哪个雄辩就能决定函数的行为。结果等到其他小组使用了这些函数后，才发现这些行为必须重新修改才能适应其他小组的应用。然后错误循环再次出现。可以看出Vista推迟的原因了吧。
微软内部的源码控制就是Perforce的翻版，听说微软买下了某个公司的一部分，然后修改了Perforce将其变成一个名叫SourceDepot的源码控制软件。它使用得的命令就是:
sd edit <文件名>
sd diff <文件名>
sd integrate <文件名>
sd delete <文件名>
sd help command。。。。
所谓的开发人员每天将源码check in，然后第二天测试人员再将新的build 进行测试，这个看起来很让人觉得很正确，但是你想象过其中难度没有？让我给你一点内部信息：
Windows Vista需要10 到12 小时的构造时间，我所在的组在每晚7点开始构造时间，到早上9点多才能完成构造。这时大家都进公司了，可以开始测试了。究竟有多少种Vista builds？局外人肯定不知道，到我离开时：
Vista x86 Pro Chk
Vista x86 Pro Fre
Vista x64 Pro Chk
Vista x64 Pro Fre
Vista x86 Ads Chk
Vista x86 Ads Fre
Vista x64 Ads Chk
Vista x64 Ads Fre
Vista IA64 Ads Chk
Vista IA64 Ads Fre
算算，这里总共有十个Builds。装这些builds需要四五小时。有时，这些builds 需要一天才能装好。然后进行测试，两百个测试程序需要两小时才能完成。这些测试一天基本上能够完成，手动测试花费时间更多。一天能做完所有测试只是最好的情况下才能做到。要是碰到一个Build出了问题，一天的测试就只能做到部分测试。要是其他组出了问题，比如一个硬件的驱动出了问题，每次安装都会导致蓝屏甚至红屏，这个驱动又上传到高层的源码分支中，然后又下放到底层的源码分支里，嘿嘿，你所遇到的是一个星期甚至一个月都无法安装测试的问题。我在的近一年中，这样的问题出现了三次，可以看出Vista为何会推迟了吧。（一点内部信息，Windows Vista的源码分支至少分三层：Winmain, VBL_CORE, VBL_CORE_<小组分支>，每个小组在周期结束时，就要将自己的源码从自己的分支往上上传，然后其他小组每天将上层的源码变化下传到自己的分支里）。
“微软的开发人员通常采用VB构造用户界面原型，但是对于构造计算机屏幕模型之类的工作，画笔（Paint brush）也是一个很好用的工具。死板的说明变成有生命的文件，说明不应过于详细以至限制了发明创造。”这纯粹就是放屁，所有产品有关源码都是C和Win32 API所写成，要么是ATL和C++，好像内部连MFC都不用。所有的测试代码是用C++或C#编写。为什么这样？因为要保证程序的运行速度。用户界面的图形展示都是第三方公司用PhotoShop这样的专业软件拼凑后交给开发者去设计。这些第三方公司一般都是进行用户互动研究的专业公司。至少我看到的Windows Vista源码里，所有的都是用C写的。
微软并不是非常强调迭代开发和逐步细化，很多组强调不能使用跌迭代开发模式。有些组的确使用了迭代开发，但是他们的做法还是流水模式，并不是很专业的迭代开发。这个局外人根本不可能知道。所以不要轻易下结论。
我所在的组里对文档的要求特别高，一个函数的行为往往要进行四五次两三小时的会议来决定。这里面就经常出现领头的程序员和PM争论多种不同的行为。最后领头的程序员能够在争论中胜出，或是僵局出现，下个会议再继续争论。这样的犹豫不决往往导致工程的拖延，将一些性能推到下个开发周期导致工程的延误。决定一个性能的行为拖上一两个星期是常事，测试往往被搞得手足无措，不知道如何测试，于是测试人员就去搞别的测试，过几天要向开发者问问究竟这个性能决定下来没有。
最让测试人员头疼的就是微软的高手，微软雇佣开发人往往都是很能设计难懂，却又能精巧运行的程序段的能人，我承认我不能和这些人比，所以最终没有拿到全职工作。但是我发现这些人很喜欢将简单的设计复杂化，微软的口号可能是不复杂的程序不是好程序。所以才会出现Windows Vista需要1.0GHZ的CPU, 1GB内存，至少128MB的显存的显卡的机器，你不升级你就别想运行Windows Vista的局面。猜猜看怎么样？能Vista出来时，我偏偏就要装Linux，把自己变成Linux用户。我已经给夫人来了MacBook，我已经没有什么好留恋Windows了。
话转回来，我所测试过的函数或是Windows Live!的登陆届面，都是无比复杂。一个简单的Windows Live!的登陆届面有五六十种行为，然后和其他功能如AJAX合并，就有两三百种行为，我在两个月内写了一百多个测试，也没有把能覆盖的边界情况给一一测试。最糟糕的是没有人能够指点我究竟什么行为是正确行为，我在写测试单元时就像是在混水摸鱼。后还我夫人要到San Diego进行博士研究生学习，我才在Intuit找到了一份正式工作，逃离了微软的测试地狱。最后两个月我感觉非常地Miserable。我测试过几个MUI API也是这样，没有完善的文档说明一个函数的具体行为，你只能参加各种各样的会议，通过会议获取有关的信息来制定测试单元，不停地返工测试单元。
最让我可笑的是，每个管理者都有自己的计划，有时进了一个会议以为某个议题是会议中心，结果其中一个管理者会占据会议，并展示自以为是的议题，搞得所有人都不知道会议方向具体是什么。我记得很深刻的一次是我们测试组织的头叫Jae Choi。我参加的会议是讨论MUI API的performance。我辛辛苦苦作了三天的测试，带了一堆的数据进了会议，大家看都没有看，随后Jae Choi将整个会议控制了，发表大篇演说说我们要设计复杂完美的performance测试框架，将所有的测试自动化，然后在每一设计周期中考察performance数据。我一听，这么一个框架要至少三年才能建立，到时候，Vista早上市了，根本不可行。也不知道他对我做的工作了解多少，然后就来自以为是地指手画脚。我的一个同事听了也是无奈地摇摇头，后来还是我的直系领导劝他把不切实际的计划放到一边。我后来接触的前任员工都跟我说，微软内部高手有的是，傻必领导也有的是。这种参差不齐的组合往往会将一个设计领导到牛角尖里。等到要退回重新起步时，时间已被浪费掉了。
在微软也不是到处都是问题，微软就像南泥湾，一切自力更生，每个组都有自己的测试框架，微软自己有自动化测试工具，叫WTT（Windows Test Technology），每个人都有机会接触源代码，每个人都能给同事帮助，提供测试工具，或是建议。你在里面跌爬滚打一年，你就能学到很多东西。你学到的是技术，和生存所需的做事方式，有了这两个，你基本上能在美国软件业的任何领域成功。但是微软的管理模式值得提倡么？并不值得。
Original Post: http://blog.csdn.net/RichardSundusky/archive/2006/07/18/936001.aspx
问题点数：20、回复次数：45Top
1 楼CARLTOON（乖乖老虎不咬人）回复于 2006-07-19 09:53:41 得分 0
开眼界了Top
2 楼frank_lee_cn（Frank）回复于 2006-07-19 12:41:15 得分 0
酷！确实是开眼界了！Top
3 楼optman（optman）回复于 2006-07-19 18:22:19 得分 0
我相信，公司大了，官僚作风总是会有的。我也相信，不是每个部门都那么先进。我也愿意相信，作者看到的只是一个小小的局部，并不能代表全局。Top
4 楼constantine（飘遥的安吉儿）回复于 2006-07-20 14:57:23 得分 0
看看再说Top
5 楼FEEDOMING（小不点）回复于 2006-07-20 15:08:03 得分 0
看到作者这样一段话：
------------------------------------------
“微软的开发人员通常采用VB构造用户界面原型，但是对于构造计算机屏幕模型之类的工作，画笔（Paint brush）也是一个很好用的工具。死板的说明变成有生命的文件，说明不应过于详细以至限制了发明创造。”这纯粹就是放屁，所有产品有关源码都是C和 Win32 API所写成，要么是ATL和C++，好像内部连MFC都不用。所有的测试代码是用C++或C#编写。为什么这样？因为要保证程序的运行速度。用户界面的图形展示都是第三方公司用PhotoShop这样的专业软件拼凑后交给开发者去设计。这些第三方公司一般都是进行用户互动研究的专业公司。至少我看到的 Windows Vista源码里，所有的都是用C写的。
-----------------------------------------
“采用VB构造用户界面原型” 和 “我看到的 Windows Vista源码里，所有的都是用C写的。”
并不矛盾。在一个源码中看不到原形代码我认为是正确的。
Top
6 楼fzd999（花差花差）回复于 2006-07-20 16:18:26 得分 0
哇~~~Top
7 楼songlife33（美女，偶们结婚吧）回复于 2006-07-20 16:21:50 得分 0
我怎么越看越晕啊，我们到底该用那一个开发工具？C? C++? ATL? C#? MFC不用？Top
8 楼gogowhy（123）回复于 2006-07-20 17:07:20 得分 0
mTop
9 楼Rockyloxinheng（两忘烟水里）回复于 2006-07-20 17:29:24 得分 0
毫无疑问，ms是一家成功的公司。Top
10 楼TonnyQ（逆暗求明）回复于 2006-07-20 17:34:36 得分 0
楼主好牛啊。Top
11 楼lzfly（梦想成真）回复于 2006-07-20 17:45:03 得分 0
大开眼界!Top
12 楼ensoniq（）回复于 2006-07-20 18:10:13 得分 0
关注Top
13 楼jyk（今天由我来写的代码，明天就让程序自己完成！喜欢编程。和气生财。共同提高。共同进步！）回复于 2006-07-20 19:00:44 得分 0
to:songlife33(roger)
你有微软的实力吗？没有的话就不要考虑用 c,c++ 这类“基础”的语言了。
看看微软的开发速度，放在一般的公司早就黄了。Top
14 楼net205（人不可以无耻到这种地步）回复于 2006-07-20 20:21:57 得分 0
真的不？？？？Top
15 楼Elandsong（）回复于 2006-07-20 21:54:33 得分 0
呵呵，很正常，没什么大惊小怪的。Top
16 楼leo2003（【健者天行】谁伴我闯荡）回复于 2006-07-21 00:09:27 得分 0
微软内部高手有的是，傻必领导也有的是。
也算开眼界了，
公司大了，就会这样。
Top
17 楼U2USoft（）回复于 2006-07-21 08:59:44 得分 0
我觉得用C#可能性不大。微软能有更高性能的C++，而且也熟悉API干吗要用.net 来虚拟运行。这不是很滑稽吗？Top
18 楼huitouren519（细节决定成败）回复于 2006-07-21 09:05:32 得分 0
学习Top
19 楼linuxbing（翅膀）回复于 2006-07-21 10:00:44 得分 0
有意思Top
20 楼myminimouse（坚决不用baidu）回复于 2006-07-21 10:27:10 得分 0
可笑Top
21 楼befree（似有似无）回复于 2006-07-21 10:27:21 得分 0
才两年,短了点Top
22 楼wjlsmail（小脖领）回复于 2006-07-21 11:24:08 得分 0
感觉作者主要针对的是Vista开发过程中目标不明确、沟通渠道狭窄，造成了项目管理上的混乱。
试用了Vista几个Beta版，整体感觉不如XP，不知以后会如何。Top
23 楼wjlsmail（小脖领）回复于 2006-07-21 11:24:20 得分 0
感觉作者主要针对的是Vista开发过程中目标不明确、沟通渠道狭窄，造成了项目管理上的混乱。
试用了Vista几个Beta版，整体感觉不如XP，不知以后会如何。
Top
24 楼ICeeYeS（酷顽）回复于 2006-07-21 11:43:48 得分 0
markTop
25 楼iamcaicainiao（老菜，长征）回复于 2006-07-21 11:48:01 得分 0
可笑
Top
26 楼femalelover（楼主, 请把用不着的可用分捐给我1/3 ：（）回复于 2006-07-21 11:52:19 得分 0
听说google不论是管理还是人文,都远远超过MSTop
27 楼jjkk168（老加班的人--好好学习,天天吃饭）回复于 2006-07-21 12:56:16 得分 0
但愿不是因为当不了微软的全职工而在这里发牢骚Top
28 楼CEO_ZHU（JAVA朱朱）回复于 2006-07-21 14:50:32 得分 0
佩服啊！
人才啊！Top
29 楼wd_6532（用frontpage写asp,jsp,php,ace）回复于 2006-07-21 15:01:55 得分 0
Windows Vista需要10 到12 小时的构造时间，我所在的组在每晚7点开始构造时间，到早上9点多才能完成构造。
=======================
那是因为你们太白痴了吧。
就算源代码有3G,目标文件有1G。
难道你们不会申请20G内存的服务器吗？
有10G内存的服务器，所有的操作都放到内存里，再弄最好的64个CPU.
我就不信还需要10个小时。Top
30 楼wd_6532（用frontpage写asp,jsp,php,ace）回复于 2006-07-21 15:02:24 得分 0
另外，是你们组白痴，而不是微软这个整体白痴。Top
31 楼SamuelKevin（曼陀罗）回复于 2006-07-21 15:39:20 得分 0
好文章啊Top
32 楼Sunmast（速马@Redmond, WA）回复于 2006-07-21 15:50:33 得分 0
>>> 但是我发现这些人很喜欢将简单的设计复杂化，微软的口号可能是不复杂的程序不是好程序。
既然你承认你的开发能力不如他们，你怎么知道复杂的设计是不是有背景原因呢？“很喜欢将简单的设计复杂化”这只是你看到的表面现象，你把天才看成了傻子，只能说明你自己视界局促。
>>> 所以才会出现Windows Vista需要1.0GHZ的CPU, 1GB内存，至少128MB的显存的显卡的机器，你不升级你就别想运行Windows Vista的局面。
上个礼拜我买了一条笔记本电脑的现代DDR2 667的内存，1GB，才620RMB。到Vista上市的时候这个价钱很可能跌到500左右了，台式PC的应该更加便宜。没记错的话，相当于98年前后一条PC100 64M SDRAM内存的价格，而当时64MB内存就是顺利运行Win98的推荐配置。
另一方面，更好的软件构件设计，其中一个后果就是代码调用路径更长。一次简单功能的函数调用可能穿越好多个层次和模块，在我看来，这是内存占用大的根本原因。但你不可否认Java和.NET在速度、内存占用处于劣势的情况下依然取得了巨大的成功。换句话说，利用进步换取更好的软件设计，是一种明智的行为。当年Excel打败Lotus的故事，可以引以为鉴。Top
33 楼Sunmast（速马@Redmond, WA）回复于 2006-07-21 15:51:40 得分 0
利用进步换取更好的软件设计
>>>
利用硬件进步换取更好的软件设计Top
34 楼weixing979（★★★闪电侠★★★）回复于 2006-07-21 16:49:35 得分 0
不错,呵Top
35 楼aosen（前世总统）回复于 2006-07-21 19:47:41 得分 0
你个傻B,你以为是COPY文件啊?它的10个小时指的是编译时间啊!木头!
==============================================
回复人：wd_6532(胜败有常) ( 一级(初级)) 信誉：100 2006-07-21 15:01:00 得分:0
那是因为你们太白痴了吧。
就算源代码有3G,目标文件有1G。
难道你们不会申请20G内存的服务器吗？
有10G内存的服务器，所有的操作都放到内存里，再弄最好的64个CPU.
我就不信还需要10个小时。Top
36 楼icuc88（职业特种兵）回复于 2006-07-22 08:53:13 得分 0
有些事情是非常正常的，一个系统大了以后考虑的问题会很多。
不是一个小系统所能够承受的。
工作流程的复杂度并不能证明管理的混乱，虽然他拖延了时间和进度。Top
37 楼U2USoft（）回复于 2006-07-22 20:22:55 得分 0
垃圾楼住，扮什么高手。抄袭CNBlogs中的日志，我现在通知管理员处理Top
38 楼lping1986（我是好学生）回复于 2006-07-22 21:26:53 得分 0
牛人Top
39 楼midthinker（呵呵）回复于 2006-07-23 09:36:08 得分 0
呵呵，公司大了，发应就会迟缓，作风就会官僚，发现微软也是文山会海啊
可惜，是不是世界上得公司大了，都会这样...就管理来说还得向美国GE多多学习啊
@.@||~Top
40 楼binglex（）回复于 2006-07-23 14:33:32 得分 0
U2USoft() : 笨笨，lz写了原文出处的；
Top
41 楼wd_6532（用frontpage写asp,jsp,php,ace）回复于 2006-07-24 13:22:48 得分 0
你个傻B,你以为是COPY文件啊?它的10个小时指的是编译时间啊!木头!
============
你个傻吊，哈哈。
他是在编译操作系统吧，
难道他还没有一台高性能的服务器来进行编译工作吗？
难道是拿一台几万块钱的破服务器来做？
10个小时阿，你算算10个小时的人工是多少美元。
对于高性能的服务器来说，cpu绝对不会是瓶颈。Top
42 楼ensoniq（）回复于 2006-07-24 17:32:15 得分 0
c/c++的项目分布式编译应该不是很困难的事情吧？Top
43 楼simonw（代码@痕记）回复于 2006-07-25 10:33:20 得分 0
深有感触，虽然带点情绪，但事实的确如此。
越是处于软件工程末端环节的team这些问题就越严重，而且很官僚。Top
44 楼luojin101（祥子2）回复于 2006-07-26 11:54:13 得分 0
开了眼界了 呵呵Top
45 楼budeyi（）回复于 2006-08-07 09:56:25 得分 0
接触过微软的一些人，印象不好Top
