`
isaac
  • 浏览: 39418 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

潘正磊谈微软研发团队管理之道

阅读更多

潘正磊谈微软研发团队管理之道

概要
近日InfoQ有幸独家专访了微软Visual Studio Business Applications团队的总经理潘正磊,与她探讨了微软研发团队管理的相关问题:技术人员的职业发展、如何培养接班人、如何管理不同规模的研发团队等等。


个人简介

潘正磊女士是位于美国雷德蒙市的Visual Studio Business Applications团队的总经理。这个团队通过提供多种工具,使全球开发人员能便捷地在微软平台上搭建商业应用程序。她同时领导开发工具部门的中国研发团队,进行Visual StudioVisual Studio Team System等产品和技术的全球研发工作。92年,她以软件开发员的身份加盟微软,参与AccessVisual InterDev等产品的开发。1998年至2006年间,她先后担任Visual Basic.NET开发经理、Visual Studio产品线开发总监、Visual Studio Team Architect产品总经理和Visual Basic产品总经理,为专业开发人员提供在.NET平台上最高效的开发工具,使数百万Visual Basic 6.0用户迁移到.NET平台。


 

 

先给我们介绍一下你自己和你自己现在所做的事情吧?

我是在1992年大学一毕业就参加了微软,一开始是做开发程序员,就是Developer,最开始开发的项目是Microsoft Access,现在也是微软卖的很好的一款产品。在Access开发了几年之后,我转做另外一个产品叫Visual Interdev,那是我们微软第一款针对网络Web做的开发工具;那之后我在Visual Basic团队做Developer Manager,就是开发经理的职位,当时我们整个从VB6VB.NET 转型,所以跟.NET做平台开发,是一个非常艰苦的项目。之后还在Visual Studio里做了一系列的职务,包括开发总监,包括我们Visual Studio Team Architect的产品总经理,包括Visual Basic的产品总经理。现在是Visual Studio Applications的产品总经理,像我们刚才所说的,主要我们这个团队做的是针对企业的开发工具。

你是从一个基层的开发人员一直走到现在,那我想,在你整个过程中应该是有很多的感触,特别是从一个开发人员然后到一个管理职位,在整个过程中有没有什么比较难忘的事情?

因为已经工作十几年了,所以说,确实有很多故事了,我觉得比较难忘的几个故事,还是跟我们最高层打交道的时候比较有趣。我们在做Visual Interdev的时候,那是我们第一款针对Web的产品,当时微软对Web的定义、对Internet的战略不是非常清晰。记得我们跟Bill Gates在做产品Review时候,他一开始对我们这个产品是有些意见的。他说,你这个产品做出来以后,对Windows有什么好处或者是坏处。这是一个挺尖锐的问题,让我们所有人回去都要好好想一想。

还有最近我们在做另外一款产品Review的时候,也是跟我们Steve Ballmer,我们的CEO,跑上来我就要给他做一个演示Demo,我们的CEO就说现在所有演示都不要做,他叫我们最资深的副总裁,你就到黑板上面去,把你们这个产品要做出来的三个目标先给我写上去,写完以后我们再做演示,看你这演示有没有达到你这三个目标,这个跟Steve BallmerReview常常会碰到这种情况。

他会直接帮你梳理你的产品目标?

他会用你很意料不到的方法来问你,因为一般我们去做这种总裁Review都是有准备好一套PowerPoint,有一套我们自己的思路,他就会从你的思路之外问一些问题,保证你确实能够解释出来你为什么要做这个东西,然后你的思路是什么,你的战略是什么,这是一些蛮有挑战性的东西。

在你的个人从开发人员到一个团队管理的过程中,在做团队管理的时候有没有遇到一些困难、一些比较难忘的事情?

做团队管理的时候,因为团队管理最主要的是几大块:第一,你要造就一个非常强的团队。这中间有很多(差异),你这团队是你自己接手的,还是这个团队是你自己一个一个雇佣进来,这个完全是不同的。还有和你的Partner(合作)团队,因为微软很多项目需要好多几个团队来一起合做才能做好,那跟你Partner的这个运行过程中也有很多的这种Interaction(互动),有的时候如果大家的战略目标不一样,就会造成很多各种各样的问题,那所以这都是有很多故事的。我现在一下想不出来一个特别好的、最有挑战的。因为从组建团队中,这么多年走过来,基本上什么场景都碰到过了,所以我还真一下想不出来一个最好的故事,或者是说最有挑战性的故事。

其实我也了解到在你整个的发展过程中,到最后成为全球微软有两千多个总经理,你是为数不多的华人,那么从整个阶段来看,你是如何去总结自己的这段历史?

我觉得微软现在华人的总经理比较少,但是我觉得从长远来说肯定会越来越多,这实际上是我们在九几年有大量的大学毕业生开始出国,然后开始在美国,或者这种(国外的)地方开始就业有关。我相对来说出国比较早一些,所以我进微软也很早。那像九几年之后,9596,包括90年代末期,有大批的中国员工进入微软,所以我相信这以后的华人工程师或者华人总经理,各方面只会越来越多。那另一方面,在微软或者是在很多大企业里,自己的一步一步都是要慢慢走过来,然后都是要脚踏实地,最主要的是要想到说你对这个团队有什么贡献,你对你的客户有什么贡献,如果能够比较的专注于某方面工作的话,那我觉得在成长中是很有好处的。

进入微软的华人很多,工程师也很多,但我想也淘汰了很多,最终可能会有一个人冒上来,而且这个人就是你,我想问一个比较直接的问题,你觉得为什么会是你走到今天这个位置?

我觉得每个人的长处是不太一样的,我觉得我自己的长处,第一是技术方面还不错,因为一开始在做工程师,如果你技术上面做不好,是不可能往上走的。另一方面,我觉得我对资源整合这一方面是比较强的,我的一个强项是我很快就能看出我下面的员工他们最适合什么,他们不太适合什么,那把他们放在最适合于他们的工作岗位上。这样第一能够是最大的调动他们的积极性,第二整个团队可以成一个非常高效的团队。

而且我在管理人员方面,很多跟我做了很多年的员工,愿意跟我做很多年,所以这也是作为一个领导者应该比较重要的素质。

我觉得是这些是可以学的,但有些可能有的人就会比较容易一些,比较自然一些,有的人可能就是要学的更多一些。

但是我想在你的团队里面应该也有一些能力非常强的,比如说他的存在会让你有所威胁,那么在这种情况之下,你是如何和他们相处的?

你看,我这个考虑思路跟你完全不一样,我不会觉得我团队里面有谁对我是有所威胁的,我的出发点就是我希望能够培养一批人才,如果有一天我能够不用去上班了,而且我的团队还可以执行得非常好,这才是我的目标,所以我是希望有人能够来代替我。

因为微软里面包括很多公司是这样的,有挑战性的工作是非常多的,如果我这个工作做完了,如果我下面培养出一批人才,能够取代于我的话,那还有更加具有挑战性的工作在等着我去做,所以这个思路不是说有这个人会对我造成危险性,而是我如果有一天能够找到一个,或者请到一个比我更强的员工,这是一个非常高兴的事情,非常令人振奋的事情。

实际上在我的职业生涯中也确实有过这样的经历,我那时候在做Visual Basic开发经理的时候怀孕了,我知道会休蛮长的产假,而且一度还动过可能不回来上班的想法,做全职妈妈的这种心思,所以我那时候就把我下面的一个开发主管,一个开发主管一直培养他,而且当时就是培养他到最后,我去休假之前,说那这个团队就交给你了。等我五个月休完产假回来之后一看,那个团队虽然是我打造的,交给他之后他还是管理的非常好。我说太好了,那你就来做开发经理。那个时候我就去做了我们Division另外一个工作,整个部门的开发总监。

就像我说的,这世界需要能人的事情非常的多,所以你是一个能干的人你不要有这种危险感,因为需要你的地方是非常多的。

所以我想,一个人的自信对于他的整个的成长是非常有帮助的?

实际上我觉得如果在微软来说,如果你没有自信,那你可能很难从一个开发工程师往上走非常的远。因为在微软我们招的都是,真的是世界上英文词叫“cream of the crop”,都是最最顶尖的大学生,或者是外面有经验的人。在这样一种环境中,你怎么样能够跟大家交流,怎么样可以说服大家同意你的观点,怎么样听取别人的反馈,自信心实际上是一个非常基本的素质。如果你没有这个素质,就是作为一般的开发工程师也不会走的太远的。

另外我比较好奇的一点,比如说在你整个的几个阶段里面:有基本的开发人员,然后到一个比如说项目经理、一个产品的带头人,然后再成为一个产品的总监,最后成为总经理,那么这几个段它有什么特别的不同吗,除了你管理的人越来越多?

那是有非常大的不同的。作为一个开发工程师来说,你最主要的是要把你的代码写得越快越多越好。因为你对产品的贡献是鉴于你代码的数量,你写代码数量直接就反映成你对这个产品功能多少的体现,你的代码行写得多,那这个功能才增加得多,你写的代码行是最难的那部分,那才说明你对这个产品最主要的核心部分有贡献,这是作为开发工程师。

作为一个开发主管来说,就是我们叫Development Lead,第一方面,作为管理者,你对这个团队的价值,不仅仅是说你自己写了多少行代码,这相对来说是比较少的,最主要是你这个团队对整个产品的贡献是什么,那还是基于你这个开发的功能有多少,然后你这个功能是不是做得好,你架构是不是做得好,但是你的核心价值是把你这些资源都组合起来,然后能够帮助你团队的员工扫平障碍,让他们非常顺利地开发。

像我最开始做管理的时候,我只管理了三个员工,有一个员工如果做得慢一点,那我最多周末去加一加班,他没有做完帮他补做完就完成了,我觉得相当简单的一件事情。等我那个团队长到10个人的时候,你就发现,第一,不可能我周末再来加班,也不可能把10个人里面有两三个人可能要做的慢一点,如果按同样的比例来说,我不可能把这两三个人要做的东西都做完了。那这个时候你要做,就是我们从这个Skill来说,如果要整个团队都能够非常顺利高效,你就要想我怎么样让这十个人互相之间能够(协调好),就是很多程序是有顺序的问题,把顺序问题安排好,有些东西可能要需要一些决定,尽早的把决定做好,下面的架构可以做好,跟其他团队的关系要搞好,因为他们可能有些东西要拿来,他们先做完之后我们才能做,所以有很多东西Dependency Management,这些东西全部都要管理好,就像造房子,管理一个项目一样。这样管理好你这十个人才能都是马不停蹄、非常高效地把这个东西做好。

等你做开发经理的时候,开发经理因为不是一个第一线的管理者,而是第二线的管理者,这个时候最最有挑战性可能是,你很多东西要通过你第一线的开发主管传达到下面去,如果你开发主管对你说的话不认可,那你的观念、决定不一定真正能够传达到最下面的开发人员。而且你下面的开发主管可能每个人都还要管一摊不同的东西,你怎么样让他们之间能够互相配合、互相合作,从一个大局上面来看你整个这个开发团队缺什么,有的时候他们开发主管在那里面做,他不一定会知道说,我实际上比较缺一个真正能帮我把这个架构搞在一起的人,或者一个特别懂客户的人,那要把这个全部都想清楚,真正打造一个非常强的团队,这又是另外一套的艺术,我觉得。

在微软如果你不懂这产品(技术),你是没有办法做一个合格管理者的,你不仅要做人员的管理者,你还要做这个产品的定义,而且还要跟你的团队交流,什么地方是应该做的,什么地方是不应该做的。

是多重角色了?

对,因为从开发经理来说,我在美国喜欢说三个P,你要管理产品(Product),你要管理人员(People),你还要管理流程(Process),这三样东西都要抓起来,你才能作为一个合格的开发经理,然后让整个团队都能高效地运行。

他和现在的总经理有很大的区别吗?

非常大的区别,因为从开发经理来说,他还只是主要是管开发团队的。开发团队总的来说只是占了可能是1/3。总经理跟产品经理是两个不同的概念,产品经理是说你管一个产品,那总经理你是管多种产品,像我刚才所说的,实际上我现在这个组里面有三种不同的产品。

那这三种不同产品很多时候会有不同的进度表,发布时间会不一样。怎么样把里面相同的东西能够整合出来,让大家最有效地利用,而且还要针对每一个产品有他特别的开发。怎么样管理这一套产品线,而且跟我们的市场部,跟我们的营销部,跟我们的DPE(开发工具及平台事业部),那些合作都是在这个层面上面是完全不同的。而且在这上面你就更要想说,这几个产品,就像我们叫Portfolio(投资组合),就好像如果你要是投资,你可能有些放风险基金,有些放银行存款,有些是放外汇,你还要再从比较高的角度上,看你每一个产品到底里面放多少的资源进去,为什么这个产品放这么多资源,而且要看你成功的定义是什么。

而做一个产品的开发经理,这么多资源实际上已经分配给你的,你在这个资源的基础上面把它做到最大最好,所以这还是不同的概念。

更加强调统筹的作用,那我们回到技术层面来讲,在你的身上可以看到一个,我认为他是微软一个研发团队的技术变迁史,或者一个缩影。那么我想问的问题是,在你的理解当中,从你进入微软研发团队一直到现在,在整个的产品的开发过程中,主要经历了哪几个比较重大的阶段?

我觉得这个问题非常好,因为你让我回想了一下。确实有几个非常大的不同(阶段)。

在我进微软的时候还是微软比较新,很多产品还是刚刚第一代,像我那时候做Microsoft Access,现在已经无穷代了。那时候刚刚是第一版,当时发布时非常振奋人心的。如果打一个比喻,就比较像我们80年代刚刚开放的时候,那时候商品比较少,用计算机的人数少,相对来说需求也少。所以那个时候从微软来说,只要发布产品就会有很多的用户来使用。因为我们有很多很基本的需求,而市场上却都没有。那我们发布的产品只要大面上不错的话,就可以非常容易地满足用户的需求。从Word第一版开始发行的时候,前面几版你可以想有很多很多基本的功能是,现在觉得都是肯定是应该有的,但是当时都是很新的东西。

但是产品在做了时间久了之后,等你发布第五版、第六版、第七版、第八版的时候,这时有很多基本的用户需求已经满足了,在那个前提上怎么样把你的产品更上一层楼,这实际上就变成一个相对来说比较困难的问题。很多时候,像我们的Office团队最大竞争者不是别人,是前面一个版本的Office。所以在一开始我觉得我们在微软里边定义产品的时候,比方说90年代初,跟客户沟通之后我们就是用一个Waterfall(瀑布式开发模式)这种Model,因为我们觉得我们知道这个产品应该做什么,我们就把它做完了,然后放在外面市场上,相对来说一定是卖得不错的,卖得很好的,所以这是我们比较成功的一个模式。

自己可以主导?

当然我们还是要跟客户有反馈,一开始要跟客户研究,但是我觉得相对来说做得少,而且相对来说比较容易满足客户的需求。因为那时候大家的基本需求有很多都没有满足。等到我觉得差不多就是99年、2000年,就是差不多那个阶段,我们那时候很多产品已经开发了好几代了,等到那个时候我们就有一个危机,因为我记得是差不多是2000年的时候,那时候客户对我们的满意度相对来说比较低,而且我们跟合作伙伴的关系相对来说比较僵一点,在美国还有很多的诉讼案,那个时候我觉得实际上是微软处于一个比较低潮的阶段。但是从那之后,我们确实就开始转型了,我觉得一个最基本的理念,我自己有这个感受,一开始就觉得说我们可以定义这个产品,定义了以后就做,做完以后卖,这是我们最开始的运营模式。

大概是2000年之后,我们就发现对用户反馈的需求变得非常多,而且一个版本一开始跟用户反馈一次是远远不够的。从开发模式来说,开始时我知道什么是对的,我知道用户需要什么,我只要开发什么,这是我们本来的模式。在那之后,我们的模式时我不太确定用户确实需要的是什么,我们可能要先做一些prototype,试验品出来,让用户去体验一下,体验完了以后再给我们反馈,这是不是他们确实要的,我们在这个反馈基础上再更改。所以你可以看出来整个流程,一开始的想法跟后来想法是不太一样的,而且我们在2000年以后,在后面的开发中,对用户的反馈的需求比以前是大大增加了,而且我们fundamental mindset(最基本的理念),从一开始我绝对知道什么样是一个对的产品,到我不太确定,那我需要跟用户多次反馈,才能知道真正什么是对的产品,那这两个其实是非常不一样的开发模式。我们之后开始用这种开发模式之后,因为微软作为一个很大的团队,确实也碰到很多的挑战,因为很多时候你要想改一点东西实际上是非常难的。

涉及到方方面面。

方方面面,我就喜欢说,像你要是自己想在家里后院造一个小房子,你怎么改都没有关系。但是你要想造金茂大厦,造到一半想改一点什么东西,那你可以想到有很多的东西要配合。你如果要改一点东西,那对你的电梯、电路、楼层、重量,都有很多的考虑因素在里面。

那作为一个大的开发团队,你怎么样能够同时满足客户的需求,又能够在你的架构基础上能够做这种改动。因为最后你的产品还是要满足客户需求,才能够有卖点。你怎么样做这么一个调整,这也是我们在前七、八年中慢慢转型的过程。那相反过来,你如果看,拿我们Visual Studio作为一个例子,从08年,我们前面几个例子看到我们开始大量的出我们叫CTPCommunity Technology Preview,社区技术预览版),而且跟我们的客户、开发人员的交流变得非常的透明,很多时候我们很早就把我们想做什么,愿意做什么,有的时候把我们写的Spec,就是产品定义放在网上,给我们的MVP(微软最有价值专家)先让他们反馈,我们现在做很多这样的工作,在这之前都是没有的。

对于你们内部的开发团队来讲,产品的设计方面是有很大的挑战,也是一种很大的转型。那么你们在自己做开发的过程中是不是也有一些分为几个阶段来呢?

对!如果是按以前的开发模式,那你可以想到我们更多的是这种,我们现在决定要做这些feature(功能),这些功能需要这样,那就是一条线做下来,最后把它发布就可以了。

就像瀑布模型一样的?

对。如果你要是想象做的功能可能需要在做的过程中调整的话,你中间的每一个开发阶段,就要设计一个跟用户反馈的过程,然后真正把那反馈拿回来,然后在下面一个过程中做调整。同时你还不能把你的那个发布日期改动的太多,所以你就可以看到这个难度实际上是增加了很多。

在每一个改变的环节上,根据刚才我们的交流,他应该是客户来进行推动的。那还有一个问题是,在什么时候你们认为这是一个改变的时机,认为这个开发模式应该改变了,这个产品设计的模式应该改变了,你们做决定的时候,有没有某一个观点来刺激着你们去做这种改变呢?

没有,因为微软很多事情不是Top-Down,不是从上面这么Drive(推动)下来的。第一,从管理层来说,我们比较注重抓的是用户的满意度,看他的满意度如何,就能体现我们跟他一开始交流的够不够。另一方面,比方说我们这个产品真正是有多少用户反馈,而且是把这些反馈做到了产品里面去,这也是我们可以衡量的、量化的。而且很多时候微软有一个团队开始做一个比较好的模式,那其他团队会说,这个模式不错,他也开始借鉴。所以我们这个转型也是慢慢转型,不是说一下子,整个全部团队开始转型,不是这么一个过程。

可能是某一个团队他先采用了某一种方法,然后其他团队开始慢慢的效仿,应该从底下往上推?然后从小到大这么一种方式?

说的非常对,因为我们不是Top-Down。从上面管理来说,你要抓的是最后的那个结果,你想看到的结果是什么,那么你鼓励下面团队去实验不同的方法能够达到这个结果,有的试验可能比较成功,有的试验可能不是很成功,那么你再把成功的这种方法,然后再在其他团队里面推广,一般多半都是使用这种模式比较多。

微软的高层他不会认为就是,OK了,所有的开发团队应该采用这么一种统一的开发方法来去做,他没有这么一种强制的要求吗?

绝对没有,因为微软的产品线非常的长,有各种各样的产品。开发方式实际上就是我们说的Process(流程),很多时候根据你这个产品不一样,各方面会不一样的。那我对Process理解是这样,就说Process是应该帮助你的开发更有效、更快,很多时候我们觉得Process非常烦琐,时间上会让你慢下来,实际上这个不是它的(目的),它就是没有达到要求。用另外一个比喻,其实像我们来的路上都是有很多红绿灯,有的地方是有那种转盘。像美国还有一种就是叫Four-Way Stop(四向停车),就是你到那边停下来看看左边、右边有没有车,没有车就可以通过。那他实际上都是不同的管理交通方式,管理这个车流量的一种方法,根据不同的地点,你要选择最适合地点的一种方法,有的地方如果车流量不是很大,用这个Four-Way Stop就可以了,有的地方可能有六、七个不同的出口,那用转盘是最合理的。有的地方,在美国比方说有的地方你停了电,本来有红绿灯的地方,你停了电就变成了Four-Way Stop,那时这个地方一定是堵车堵得不得了,因为红绿灯可以帮助流量的增加。

开发的管理方法也是非常类似的,根据不同的项目你要选择对你来说比较合适的方法。如果是一个比较小的项目,你用一个heavy weight(重量级)的方法那就是不合适的。这是为什么微软不会从上面说你一定要用什么样的方法,他考核得是你最后那刻做出来的结果,你的结果是怎么样,能不能在你所承诺的时间里面把东西做出来,你做出来东西用户是不是认可,你做出来的东西后面是不是有很多质量问题,还是说很好用。你在做下面一个版本的时候,就可以反映出你前面做的架构好不好。如果你前面做架构延伸性非常差,你第二个版本相对来说就会多花时间,因为要把前面重新(改造)。

遇到很多兼容性的问题?

对,所以这种才是比较硬性的考核标准,那下面用什么样的方式,你自己应该去选一个对你团队来说最合适的方式。

那我们再具体一点,就是你作为一个开发团队的负责人,肯定在整个的团队管理生涯当中,采用了很多新的技术,很多的新的开发方法,那你是有一种什么样的观点来评估这个技术、这个方法是不是应该用在自己的团队里面?

一般还是看结果。我本人是比较愿意去试验新的方法,我会让一个feature crew (功能小组)去试验这个方法。然后给他一段时间,他来给我反馈,这个不管是方法还是新的工具,他有什么优点,他有什么缺点,因为很多时候你想是想不出来,你还一定要去试,试了之后才知道它到底是好用还是不好用,它什么地方好,什么地方不好,就跟车一样,你得要去试开一下。然后在这之后,根据他的好处跟坏处,你还再可以跟现有的方法再看,再评估一下,你是把它全盘拿过来呢,还是把它改动之后再引用,或者有没有什么办法把它好的地方能够结合到现有的方法之中,不好的地方把它抛开不用。

你每换一个开发工具,或者是每换一个开发流程,尤其是团队大了,相对来说实际上是一个比较难的事情。因为你对整个开发、测试,还有工程师,你都要进行一个训练的过程。所以一般来说,我并不鼓励有什么是最热门的,我们都来试一下,因为这个是不太可能达到效果的。很多时候如果一个新的办法在推行之中,大家对这个方法不熟悉,很多时候员工也会有抵触情绪。因为我本来这个用的很好,我也知道怎么用,它里面好的、坏的我都知道了。那现在你如果是一个新的东西,我对它第一不知道,第二没有感觉,然后第三现在我就是不知道怎么跟大家合作,那一开始可能会有生产效率的这种降低。所以从这种方面来说你都要考虑进去,尤其是团队大的话,有的时候是在现有方法之上,说哪些是一定要改动的,哪些是不能改动的,那很重要一方面就是把这个理念,你为什么要改,你不是教你这个团队方法,你要把你想最关键解决的这个问题,为什么你要做这个改动,你现有方法你觉得最最不好的问题是什么,你要把这个问题跟团队讲清楚。那团队在理解了这个东西而且他也认可的情况下,比方说我们以前的开发方法是假设我们知道用户需要什么的,我们现在开发方法是假设我们并不完全知道用户需要什么的。这是一个非常基本的理念不同,你把这个要跟团队讲清楚,那他真正能够明白体会了这个问题之后,那再接下来他会和你一起改进他的工作方法。

工作方法不是我来改进的,是我的团队来改进的。因为他在日常工作(开发、测试)中发现了问题,发现什么是更好的解决方案,他要有这种主观能动性,他要明白我想解决的问题是什么,他才能够主动帮我来想更好的解决方法。那想出解决方法之后,我们大家再分享,一般都是这样。

很多可能都是从底下往上冒出来的?

绝大多数。因为我每天不在那里做开发,我不可能知道什么是最好的解决方案,确实要每天在做的人才会在他做的过程中发现说,我们这个地方好像浪费了很多时间,我们有没有什么好的方法把它给解决一下。他如果是这个涉及比较广,他会跟我们有一个汇报的过程,因为他可能会问我要资源,或者要其他的东西,那在这个时候我会给一些比较方向性的东西:这个问题我早就知道了,但是我现在决定不解决,因为可能有其他的方方面面的原因,所以我不解决;或者说这个想法非常好,我给你资源,你去给我做一个试验原型出来,然后我们再来看一下,这是非常常见的。

那我想作为一个比较成功的技术研发团队的管理者,给我们其他团队的负责人,如果提三点建议有没有什么好的建议?

我觉得对中国团队来说,有些是不是适合国情我就不知道了,但是我先说一下三点建议:

第一,就是真正的要有这种自信心,要去培养你的接班人。而且是不仅是你要培养你的接班人,每一个重要的职位下面都要有一个接班人,而且这个需要和你重要职位的人一起在培养,因为这是打造一个长久的成功的团队非常重要的一点。因为你没有这种传帮带的话,那你这个团队也许是现在可以把这个产品做出来,如果你们有重要人员离职之后,你还能不能是一个成功的团队,这是一个非常重要一点。

第二点,你怎么样能够调动员工最大的积极性,而且我觉得有的时候中国的员工不够主动,你让他做他会做得非常好,但是你不跟他说的事情,他也许就不做。这个我看得比较多,不管在美国和中国的华人员工里面都是比较常见的一个问题。作为一个管理者,你怎么样能够让他能够非常主动把问题告诉你,而且把解决方案也告诉你,这个是从微软文化上面来说是非常重要的一件事情。

第三个方面,从微软来说是人脑加电脑,从我们做IT来说是人脑加电脑,那实际上最主要的还是人脑,那你是不是真的培养员工,真正是让员工在你团队里的重要性充分的发挥了出来,只有在这个时候员工才认可你的管理的方式,才能认可他是这个团队的一员,才能想到怎么样在这个团队里面发挥最大的重要的作用,那这也是我觉得开发管理者应该多思考的问题,和多做的事情。

还有没有其他想和我们读者做分享的呢?

我觉得我们中国IT员工,从IQ上面来说非常的高。而且尤其从钻研角度来说,也是非常(努力),真的是。我们在微软自己就觉得我们在中国招的大学生素质,比我们在美国招的大学生素质要高,真的是从那个IQ上面来说。

但是,我觉得有一些可能文化上面的东西,可能会限制这些员工的发展。我看到比较多的是,有的时候员工他们碰到一个问题,我觉得可能是考试考太多了,他们看到一个问题,他们不太会去跟旁边的人,一起跟周围的团队里面的人,或者跟美国团队人一起交流,一起想最好的解决方案,能够把大家不同的观点整合起来。很多的时候看到他们自己在非常辛苦地在干。那苦干之后真的是做出来成果就说,你有没有考虑到一二三四五六,那你有没有跟这个人去谈过,好像这方面做得相对来说比较差一点。因为我觉得我们考试的模式就说你不能问别人,你都要自己解决。

我们在工作中都是,你不可能一个人把方方面面都考虑全,这是不可能的。所以你一定要跟你团队里面的人搞好关系,一定要把团队里面帮你一起想这个问题,还有什么其他的观点,而且能够非常坦然的把这个观点结合到你的解决方案中去,那我觉得这方面相对来说就是相对弱一点。而且就是这种主动性比较差,如果你没有跟他说要做什么事情,你交代的我都做好了就完了。那这两方面我觉得中国员工需要想一想怎么样加强的地方。

感谢您接受我们的采访。

谢谢!

 

分享到:
评论

相关推荐

    潘正磊-开源软件开发

    该文档来自阿帕奇2015中国路演。潘正磊发表了题为“开源软件开发”的主题演讲,欢迎下载!

    it行业大牛经验总结

    潘正磊,一位出色的微软女性经理,执掌中美两个研发团队。2010年11月应旨在帮助并支持技术型女性员工不断进步的英特尔女性员工网络(Women at Intel Networks, WIN)邀请,她与英特尔亚太研发公司近100位上海员工...

    2010 SD2.0大会演讲实录.doc

    微软Visual Studio商业软件部总经理潘正磊做大会演讲 潘正磊: 我今天想跟大家聊的是云计算。刚才我们的阿里巴巴的王坚博士谈了很多云计算的概念,我再加一点补充。更多的时间来讲一下微软关于云计算都做了什么,...

Global site tag (gtag.js) - Google Analytics