【转载】微软的管理模式真的值得吹嘘么？

作者： Dick Sun的专栏
原载：http://blog.csdn.net/RichardSundusky/archive/2006/07/18/936001.aspx

最近有个叫人月神话的博客写了一个吹嘘微软管理艺术的博闻。这篇看似美好的文章，被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），每个人都有机会接触源代码，每个人都能给同事帮助，提供测试工具，或是建议。你在里面跌爬滚打一年，你就能学到很多东西。你学到的是技术，和生存所需的做事方式，有了这两个，你基本上能在美国软件业的任何领域成功。但是微软的管理模式值得提倡么？并不值得。