微软产品开发中的“战争与和平”
冲突是微软开发工作时的常态，每个微软新产品的孕育过程概莫能外地充斥着质疑、抗争、苦闷、忐忑……理念的交击、智慧的冲撞让软件开发的各个阶段都弥漫着硝烟，直至产品发布，然后又要迈入下一个循环。对于微软工程师们来说，这样的经历就仿佛是一次次痛苦但不乏惊喜的涅槃。
这篇博客记录了微软Windows Server 2008 R2*中国团队的一些真实经历与感悟，例如“暗藏杀机”的季度性产品评审会议；微软工程师如何“向用户学习”；软件开发过程中只有对错、没有“权威”……
*Windows Server 2008 R2是与Windows 7同步研发、同时面世的微软新一代服务器操作系统。
Windows Server 2008 R2今天在北京正式发布，由我们负责开发的Active Directory Administrative Center（活动目录管理中心，以下简称“ADAC”）也将真正开始接受IT管理员们的检验。
为迎接这一天，我们准备了非同寻常的一年半。有过重重压力，有过混乱无序，甚至怀疑过这是否是“不可能完成的任务”。而当Windows Server 2008 R2预发布版本问市后，美国权威IT技术信息杂志《Windows IT Po》在一篇新功能点评文章中，将ADAC评价为最受关注新功能第一名，这让我们高兴了好一阵子——我们收获的不仅仅是一件令团队成员自豪的产品，更重要的是，我们证明了中国研发团队的能力。
在我们在踏上新的征程之时，谨以三个幕后故事来记录我们的努力和过往那些“硝烟弥漫”的日子。
测试主管Jun的故事：从虚无缥缈到事实
Windows Server 2008 R2即将发布第一个测试版时，Jun正在美国参加一个季度性产品评审会议。当时，他的测试团队因为对ADAC采取了与美国不一样的测试策略，在产品开发前期更激进地寻找bug，最后挖出了538个，“荣登”活动目录整个产品线所有新旧产品bug数榜首，并几乎与“活动目录”其他产品的总bug量相当——作为团队代表，如果Jun无法让管理层信服，整个中国开发团队能够在Windows Server 2008 R2发布前解决这些问题，那么这个项目很可能会被砍掉，这意味着十多位工程师一年多的努力将化为泡影。
当Jun不厌其烦地阐述、分析，并反复强调ADAC一定能够和Windows Server 2008 R2一起发布的时候，“活动目录”产品线的总经理，一位白胡子老者（真的很像圣诞老人）笑眯眯地转过头说：“你知道在英语中我如何来描述你的结论（可以和Windows Server 2008 R2 一起发布）吗？我比较喜欢这个单词：illusion (虚无缥缈)”。
那一刻，虽然Jun嘴上依然挂着笑容，但是阵阵冷汗已在后背泛起… …在强迫自己冷静之后，Jun回答道：“我们看到的不只是静态的数据，还是一个发展的趋势，基于bug数量递减的速度和趋势，我依然有信心，我们能够完成这一产品。”
不知道是被中国团队的执着所打动，还是真的相信了Jun的“趋势论”，总之“圣诞老人”在会后并未将这个项目从Windows Server 2008 R2里砍去。但他设置了一个非常严格的时间表，要求中国团队在相应时间内将bug数量降低到可控的范围之内。像很多故事一样，不懈努力的结局是美好的。最终，Jun的测试团队因为出色的表现（自动化测试的稳定性和测试的代码覆盖率都超过了微软的标准）而受到了“圣诞老人“的特别肯定。
开发人员Elfe的故事：用户是最好的老师
在产品开发过程中，开发、测试人员和项目经理之间常常会有很多的争论：争论产品的某一表现究竟是错误还是本该如此的特性；受时间所限，开发人员不可能修正所有的bug，因此对于bug大家会争论它的严重程度与优先级，以决定是否需要修正。有时候实在是各有各的理，谁都说服不了谁，问题就只能暂时搁置。
当产品第三个里程碑结束时，用户体验小组邀请了几位IT管理员用户，请他们在产品上完成拟定的几项操作任务。用户体验小组架起了三个摄像头，分别对着电脑屏幕、鼠标与用户的脸部，通过录像分析用户执行任务的顺利程度，以衡量产品的设计。研究结束后，用户体验小组给所有开发团队发了长长的报告，列出产品所有成功与失败的地方；此外还精选了一部分录像供大家参考。
录像中是一张张困惑、受挫、惊奇甚至绝望的脸。有用户在一个没有提示的输入框里进行了十几次尝试却无一成功；有用户对一条简略的出错报告信息上天入地怎么都找不到错误的具体原因；有用户成功执行了操作却因界面未及时刷新而停在那里苦苦等待；有用户误操作不可恢复地删除了重要数据，把嘴张成O形呆坐在那里。
这些录像就像整蛊视频一样，实在是搞笑。在镜头前，可怜的IT管理员们就像不知情的被整对象手足无措。大家看得乐呀——“这么简单的事他们怎么就不会呢？”
但在笑过之后，大家又都脸上发烧：这可都是因为我们的错啊。赶紧回头找找，为什么有些问题我们在设计时没能考虑到，为什么有些bug我们没能发现，为什么有些bug我们会认为无关紧要而不去修正。用户是最权威的裁判，告诉了我们什么是对什么是错。
开发人员 Elfe 感叹：“此后每有争论，我脑海中就会出现用户那张绝望的脸。于是，慎重地从用户角度来考虑事情，而不敢为了追求进度推诿掩藏问题。用户的受挫体验，给我上了最生动的一课。”
测试人员Li的故事：不惧权威的质疑
除了开发新一代的活动目录管理工具外，中国团队还要维护一个从Windows NT4开始，被一代又一代的管理员沿用了十多年传统管理工具。确保它能在Windows Server 2008 R2上稳定运行，是一项至关重要的任务。
项目开始不久，Li就发现旧工具上的一个右键菜单项未作任何改动就莫名其妙失踪了！检查相关代码后也没有发现什么异常。这难道是其它小组的代码改动所致？虽然中国团队只负责ADAC的开发，但是同样有权限查阅和修改Windows的任何代码。没有理由说怀疑上述问题是别人导致的就放任不管。既然有了代码，Li就主动请缨负责寻找问题的根源。在结合多种排错手段后，终于把问题定位到美国团队负责的界面代码中。
接下来，Li把问题描述、对应的代码、代码修改前后的比较和逻辑分析发给了相应的美国团队。对方很快就着手分析，一名合伙人级别的开发工程师（微软某产品线或技术的首席代表）为此发信询问更详细的来龙去脉。他坚持认为，根据他原先的设计，相应的问题是不应该出现的，他怀疑是我们团队工程师的不当调用造成的——但Li并没有因为对方是“权威”而放弃质疑。他再次回信分析，最终说服了美国同事在相应的组件中修正了错误，消失已久的右键菜单项又恢复如初了。
类似的情景，在服务器与开发工具事业部中国团队，在整个微软中国研发集团，每天都在上演且永远不会结束。驱策我们不断克服困难、努力前行的动力是身为中国软件工程师的责任感和以创新影响全球用户的成就感。
徐雁斐
Comments
Anonymous
November 05, 2009
I don't know why a test guy should commit for the bug fix time. Or it is a different role that this test guy is taking - China team representor?Anonymous
November 07, 2009
The test guy was indeed representing the feature team in the review.Anonymous
November 08, 2009
Yes. Because this China team owned the ADAC, Jun represented the whole feature team in this review meeting and committed for the bug fix time. PM, Group Manager and etc. represented the China team in the later product review meetings respectively. Thanks.Anonymous
November 29, 2009
嗯，写的很生动。类似的经历我也有过。测试人员和开发人员，不同模块开发人员之间的斗争，现在回想，依然历历在目。