微软产品开发中的“战争与和平”

冲突是微软开发工作时的常态,每个微软新产品的孕育过程概莫能外地充斥着质疑、抗争、苦闷、忐忑……理念的交击、智慧的冲撞让软件开发的各个阶段都弥漫着硝烟,直至产品发布,然后又要迈入下一个循环。对于微软工程师们来说,这样的经历就仿佛是一次次痛苦但不乏惊喜的涅槃。

  这篇博客记录了微软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并没有因为对方是“权威”而放弃质疑。他再次回信分析,最终说服了美国同事在相应的组件中修正了错误,消失已久的右键菜单项又恢复如初了。

  类似的情景,在服务器与开发工具事业部中国团队,在整个微软中国研发集团,每天都在上演且永远不会结束。驱策我们不断克服困难、努力前行的动力是身为中国软件工程师的责任感和以创新影响全球用户的成就感。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-10-03 13:40:54

微软产品开发中的“战争与和平”的相关文章

解析精益产品开发:产品开发中的价值

本文是<解析精益产品开发>系列的第二篇.第一篇中我们介绍了看板方法,看板方法帮助组织持续改进,实现顺畅和持续的价值流动.但是,只有基于正确价值的流动才有意义,这是精益产品开发的前提.在本篇中,我们将揭示产品开发中的价值本质,并以此为基础,分享一个适合精益产品开发的价值定义和发现实践--影响地图(Impact Mapping). 1. 产品开发中价值的本质 传统项目管理强调预先定义.分解和估计价值,以此为基础计划项目,然后按计划执行就可以实现价值.这一理念应用在诸如生产或建筑之类的工程项目上是有

腾讯产品开发中那些鲜为人知的敏捷

腾讯在十几年的成长过程中,给用户带来了很多惊喜和体验,也为自己带来了无数收获,在这其中,敏捷方法功不可没!本文就将为您揭开其中不为人知的敏捷故事. 天生敏捷基因 企鹅出生在极速变化的互联网行业,出生之时便面临着四大挑战. 海量用户的需求:企鹅服务于数以亿计的互联网用户,在保证业务稳定的前提下,更要满足海量用户不断变化的需求,因此企鹅必须要竭尽全力快速实现一个个新需求,如果采用传统的开发方法,用户是无法接受的. 行业的迅速变化:互联网上新概念.新玩法.新应用层出不穷,一会儿SNS.一会儿团购.一会

详解互联网产品开发中的“快”字诀

当今互联网的发展,已不是大鱼吃小鱼的时代,而是快鱼吃慢鱼的时代.互联网产品的制胜原则就是一个字--"快".在各种形态的产品研发中,我们始终贯彻如一的价值观之一就是"快",我们应该如何来理解和诠释"快"?又会从哪些方面来执行贯彻这个原则呢? 一.快速迭代,快做快发 互联网产品不同于传统软件开发,我们面对的是上亿用户这样一个庞大的使用群体,他们是谁,有什么喜好,有何种习惯,会怎样使用我们的产品,是否喜欢我们的产品--这些情况我们并不能准确地知道.因此

需求采集为小公司敏捷开发中的用户服务

网页制作Webjx文章简介:最近也许是因为大家面试很多,讨论用户需求采集的话题越来越多,好像突然大家一下子都在关注产品的这一流程.当然需求采集的方法很多,众多前辈们也都总结了许多,完全可以参考甚至搬到自己的项目中来实现.这些方法用到大公司大项目上,只要把握的好,数据分析工作做 最近也许是因为大家面试很多,讨论用户需求采集的话题越来越多,好像突然大家一下子都在关注产品的这一流程.当然需求采集的方法很多,众多前辈们也都总结了许多,完全可以参考甚至搬到自己的项目中来实现.这些方法用到大公司大项目上,只

解析精益产品开发:面向价值的可视化

用户故事图谱和任务看板.版本和迭代燃尽图,可视化已经成为敏捷和精益产品开发必选实践.可视化真的重要吗?我们将从一个真实团队的实践开始,探讨可视化的作用,以及如何让可视化发挥效用. 1. 一个团队实例 这是一个50人左右的团队,做企业级存储和数据管理产品,他们通过实施产品开发中的价值.技术风险和价值流动过程的可视化,促进了团队的沟通.决策.自我管理和持续改进. 1.1 可视化价值 图1是团队使用的用户故事图谱,它集成了产品目标.产品功能项以及产品的发布计划. 图1 用户故事图谱实例 图中左上部的两

解析Android开发中多点触摸的实现方法_Android

多点触摸技术在实际开发过程中,用的最多的就是放大缩小功能.比如有一些图片浏览器,就可以用多个手指在屏幕上操作,对图片进行放大或者缩小.再比如一些浏览器,也可以通过多点触摸放大或者缩小字体.其实放大缩小也只是多点触摸的实际应用样例之一,有了多点触摸技术,在一定程度上就可以创新出更多的操作方式来,实现更酷的人机交互. 理论上,Android系统本身可以处理多达256个手指的触摸,这主要取决于手机硬件的支持.当然,支持多点触摸的手机,也不会支持这么多点,一般是支持2个点或者4个点.对于开发者来说,编写

《产品设计与开发(原书第5版)》——2.6 产品开发组织

2.6 产品开发组织 除了精心编制一个有效的开发流程,成功的企业还必须组织其产品开发人员,有效地实施流程计划.在本节中,我们将介绍几种用于产品开发的组织,并为如何选择提供指引.2.6.1 通过建立个人之间的联系形成组织产品开发组织是一个将单个设计者和开发者联系起来成为团队的体系.个体之间的联系可以是正式的或非正式的,包括以下类型:报告关系:报告关系产生了传统的上下级关系,这是组织结构图上最常见的正式联系.财务安排:个体通过成为同一个财务实体的一部分联系在一起,如一个商业单元或公司的一个部门.物理

解析Android开发中多点触摸的实现方法

多点触摸技术在实际开发过程中,用的最多的就是放大缩小功能.比如有一些图片浏览器,就可以用多个手指在屏幕上操作,对图片进行放大或者缩小.再比如一些浏览器,也可以通过多点触摸放大或者缩小字体.其实放大缩小也只是多点触摸的实际应用样例之一,有了多点触摸技术,在一定程度上就可以创新出更多的操作方式来,实现更酷的人机交互. 理论上,Android系统本身可以处理多达256个手指的触摸,这主要取决于手机硬件的支持.当然,支持多点触摸的手机,也不会支持这么多点,一般是支持2个点或者4个点.对于开发者来说,编写

产品经理在软件开发中起到了十分重要的作用

提到产品经理的职责,我们首先想到的就是其要对整个产品周期负责,从市场调查.产品规划.设计.项目管理.产品上线.上线推广.产品改版升级等产品的全过程管理,可以说产品经理在软件开发中起到了十分重要的作用. 近日,专为企业挖掘潜在销售的大数据分析公司Infer的CEO兼创始人Vik Singh根据自身所闻和经历,就公司喜欢招募的产品经理.如何招到优秀的产品经理以及怎样成为优秀的产品经理撰文.Infer公司用户包括Tableau.SurveyMonkey.Zendesk.New Relic.AdRoll