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

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

我是在1992年大学一毕业就参加了微软，一开始是做开发程序员，就是Developer，最开始开发的项目是Microsoft Access，现在也是微软卖的很好的一款产品。在Access开发了几年之后，我转做另外一个产品叫Visual Interdev，那是我们微软第一款针对网络Web做的开发工具；那之后我在Visual Basic团队做Developer Manager，就是开发经理的职位，当时我们整个从VB6到VB.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 Ballmer做Review常常会碰到这种情况。

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

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

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

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

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

我觉得微软现在华人的总经理比较少，但是我觉得从长远来说肯定会越来越多，这实际上是我们在九几年有大量的大学毕业生开始出国，然后开始在美国，或者这种（国外的）地方开始就业有关。我相对来说出国比较早一些，所以我进微软也很早。那像九几年之后，95、96，包括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年，我们前面几个例子看到我们开始大量的出我们叫CTP（Community 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上面来说。

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

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

感谢您接受我们的采访。

谢谢！

我了解到，Visual Studio整个研发过程中是非常好地实施了敏捷，取得了不错的效果。能不能请你介绍一下，在你们从传统的研发过程过渡到敏捷过程中，有没有经历什么一些比较好的故事？

我们实际上做敏捷转型也是因为之前有一些不太好的经历。微软在做Visual Studio 2005的时候，实际上可能延误了将近一年，而且因为各种质量问题，做完之后我们还要打一些补丁。所以作为一个开发人员来说，我认为Visual Studio 2005是一款初期做得比较失败的产品，虽然我们之后通过SP（Service Pack，补丁包）来完善它。这个产品做完之后，我们开了几次高层会议（讨论）我们怎么能够让我们下一个产品提高质量、准时发布。

当时，Visual Studio 2005的开发团队已经大约两千多人，让两千多人做同一款产品，并让这么多功能质量达标，相对来说是一个比较难的管理问题。我觉得Visual Studio 2008相对来说就，做得是非常成功的。从第一版Beta(公开测试版)开始，我们的用户反馈就非常好，他们觉得我们Beta 1的产品质量基本上可以达到我们之前的RTM（Release to Manufacturing，发布给生产厂商）的质量。

我们开发Visual Studio 2008的时候，就是我们整个大部门转型，采用敏捷开发的过程。那我来介绍一下当时我们是怎么做的。

第一，我们发现，如果从CLR（Common Language Runtime，公共运行时）、到Framework、到上面的Visual Studio这三层，同时有大改动的时候，这个是最难的。如果说CLR是我们的地基，Framework是我们的钢筋水泥，那Visual Studio就是我们上面盖的这个楼，三个东西一起改的时候，同时要建这个房子就比较困难。我们就采取了Framework有改动，但是它的基本（core）是不能改动的。如果你对我们.NET Framework比较熟悉，就知道2.0版本是最小的，然后3.0是加在它的上面延伸出来的，3.5又延伸。但它的核心的东西并没有太大的改动，我们就采用这么一个模式：我们给用户足够多的新功能和新功效。这样就保证Visual Studio建于它的基础之上，能够有非常稳定的地基。

在Visual Studio 2008中，实质上我们做了很多的工作。最大的功能就是LINQ (Language Integrated Query)功能，对编译器来说是一个非常、非常大的改动。对我们整个编译器结构的要求，和新加的功能，是很有挑战性的。当时最大的编译器当然是Visual Basic跟C#这两个编译器。我们先花了很多时间做了一个非常强大的prototype，并很早就把prototype给我们用户来反馈，帮助我们设计语言的性能，当时VB和C#都有这么一个prototype，而且我们很早让MVP使用。但是这个prototype最后有多少真正做到产品里面？非常少，不到10%。这就是我们从敏捷开发里面（借鉴的）：先要以最快的方法明确用户的需求，一开始我们先是做了这个工作。从做prototype过程之中，我们还学到了什么是容易的，什么是难的。因为很多软件产品，可能一开始用来演示的80%的产品是非常快就可以做好的，但是接下来这20%的难点，可能需要你花80%的时间去做。

最后一公里比较困难？

最后的一公里是非常困难的，尤其是在你的产品会被几百万人使用的时候，会有很多不同的场景，你在开始做演示的时候都不需要考虑到，但你最后把它做成一个产品的时候，是一定要把它做好的，否则你就需要打很多补丁。

我们在做prototype的过程中，第一，我们明确了用户的定义；第二，我们也对架构上面哪些地方是比较难的，那些地方需要花很多时间去思考才能把它做好，有一个非常深的理解。第三个好处就是，我们发现VB跟C#，虽然是由两个完全不同的code base组成的，但是在做LINQ的功能，有一些东西是可以分享的，所以从资源组合上面，我们在做完prototype之后，发现有一部分东西是两个小组可以做成一个模型。

可以共享的。

虽然语言的表达方式完全不一样，它下面有一部分生成的东西是一样的，这样两个小组可以共享。在没有做prototype之前，我们这种设计是不可能实现的，做了prototype之后不管是用户定义、架构、分享，都有了更明确的思路。有了这个思路之后，我们再来做这个项目的规划就会比较清晰。比如，第一个里程碑我们需要做出来一个什么东西，而且我们考虑是两方面的：第一方面，是从用户的体验上面来说，哪一些语言的东西可以放进去了；另一方面，是从架构上来说，哪些最最基本的架构工作可以做好了，做完这个架构工作。在第二个里程碑，我们可以实现更多的用户体验；那另一方面，可能再去开展另外一些的架构工作，所以是这么一层一层做下来的。

通过不同的迭代逐渐就完善这个产品？

所以Visual Studio 2008这产品我们做得非常成功，我们大概本来说是九月份要发行，基本上是十月份发行。对一个几千人的大团队，能够做这么大一个LINQ功能，而且我们跟其他的部门，像SQL Server有很多的合作关系，能够把这些都管理好，把产品做成，最后准时发布，这也是我们用了敏捷之后，一个比较大的成功案例。

另外一个比较成功的敏捷开发经验就是，我们试用了我们自己的产品。

微软内部有一个优良（传统），我们自己叫“Dog Food”，就是“吃狗粮”（指自己试用自己开发的软件）。我们在做2008的时候，就Dog Food了Team Foundation Server这个产品，每一个团队把他想做的东西，把用户的场景都放在这个大的服务器里面。作为微软的高层，在任何时候都可以把这些信息汇总，虽然不可能知道每一个项目做到多少，但可以从大面上知道哪些用户体验已经实现了，哪些用户体验还在做，从宏观上面，可以比较快（了解）。如果这个团队看上去这部分可能做得还差得比较远，那这个版本的这个功能我们就不做了，这种决策层上面的问题就比较容易解决。从一个50人的开发团队来说，你可以说有一些用户场景，这个版本是支持的，另一些用户场景，可能这个版本来不及做了，放到下一个版本去做，在这种决策的时候，你可以非常清晰地看到本来计划是什么，已经做到什么，而且场景我们都是要求有一个优先顺序的，按最重要的先做，不重要的相对晚做。

这有包含一些敏捷的思想在里面吗？

对，这实际上都是包含敏捷的思想。因为敏捷里面最重要的一个思想就是backlog（代开发事项），你的产品都有一个backlog，有哪些东西要做的，然后有一个优先级，全部都要按优先级排序，哪一个是最重要的，哪一个是第二个，哪个是第三。

排完序之后，每个团队根据自己现有资源划一条线，觉得哪些场景是应该可以做好的，哪些场景是不能做的。划这条线之后，作为一个决策层，你同意不同意团队的观点？很多时候，我跟我团队交流，他给我一二三四五划了这些场景，我说不对，你划到线下面的这个，比方第十五个实际上是非常重要的，它应该放到第三个。我们这样改动后再看一遍，我现在同意你这个排序了。但是你这条线划得我可能不同意，因为你可能划到第十个，那我觉得说接下来的十一到十五也是非常重要的，如果这个版本没有这些功能在里面，我认为这个版本是卖不出去的。作为管理层我有这个决策权，这时团队可能跑回来跟你说，可是我只有这么多的人，资源不够，怎么办？这个时候两个非常重要的方法，第一个最简单的是加资源；第二是加时间，这也是一种资源；第三个比较难点，你要团队回去，把他每一个做的用户场景，更仔细地分析一下，每个用户场景后面都应该有一个cost information，这个场景做出来需要多少的资源。有的时候看到他这个用户场景（会发现），为什么这个用户场景需要这么多的资源，跟你想象中的是否有出入，作为一名懂技术的管理者应该有个差不多的概念。为什么这项资源花这么多，这是对还是不对，这个时候你要做一个深入分析，阐述这个场景里面具体要做一些什么东西，有些什么考虑，认为比较难的东西是什么，这样才能说明你为什么花了这么多时间和资源。

在讨论的过程中，很多时候你就会发现，他也许设计的场景太复杂了。我给你举个例子，我们做很多界面上东西，像“drag and drop”，我看到有一个用户场景，用户可以用undo、redo、cut、copy、paste，这个需要花这么多时间吗？后来发现他们设计的是一套非常完善的方案，第一，undo和redo可以是多层的；第二，两个界面之间切换之后还是可以实现的。比方用一个车，场景是我给你一辆自行车就可以了，他可能给我的是一辆非常非常优秀的奔驰，实际上是用不着的，这个资源实际上是比较浪费的，没必要做那么好，因为用户他不认为这个需要做这么好。这时候你要跟你的团队交流，我们不用做一辆奔驰轿车在这里，可能做一个最基本的就够了。反过来说他这场景是不能没有的，一定要有，但是足够好就可以了，那这个足够好的定义就需要管理层跟团队去反复研讨。我们常常说这是一个hard cut，这个东西我也觉得很好，但是从资源上面来说不够了，我们还是放到下一个版本，我把它砍掉之后，我知道我肯定会听到用户反馈的，但是从这个总体的宏观的管理角度来说，我是一定要做这个决策的。

这都很好的融入了敏捷的思想在里面。

这里面都很好地融入了敏捷的思想，因为：第一，我们做完决策之后，就是像我刚才说的我们这个十到十五（条要做的），重新放在优先级列表里面。做完这一套东西之后，尤其是做Visual Studio，我们把很多想做的东西，做成一个可点击的PPT，像产品演示一样。实际上我们花的精力相对来说是比较少的，因为我们并没有真正去设计它下面怎么架构，它真正的用户界面是什么。但是它给了用户一个非常直观的可视性，这个产品大致可以这么操作。我们做出这么一套图形之后，把这套图形给我们的用户演示，包括我们MVP等等。给他们演示之后，他们说这方面很好，这个地方不好，我们就可以马上改进，不会花费很多资源，但是它把你的想法变成一个可视化的东西，否则你跟用户交流也是非常困难的。

你已经形象地告诉他我要做这么一个东西。

对，所以在做这个产品之前，我们先把它变成一套可以看得见的东西。那用户就可以说，我喜欢这个，我不喜欢那个。这是非常容易做到的，而且是非常行之有效的方法。这里面要多次和用户反馈，我们一开始的优先级，最优先要做什么… … 用户反馈之后，我们拿它来作为我们的执行计划，把它分成一个一个里程碑.每个里程碑做完之后，我们再拿已经做好的东西跟用户去进行交流: 产品做到这个地方，你觉得还有什么地方（需要改进）。用户看到一个真正的产品时候，还会有很多想法，比如这个场景能不能实现？我可能说这个场景我现在没有时间做。他会说，你可不可以在这边加一个接口，你要加一个接口的话，那我就可以把我的东西嵌入在里面。这个相对来说可能是比较容易做到，而且又对这个产品的拓展性有好处，那么用户在我给他做成的基础上面能够加入他自己的东西，这些东西很多时候是跟我们的用户交流之后改进的。

但是Visual Studio他的技术团队在自己实施敏捷的时候有没有遇到一些挑战？从传统的开发模型过渡到一个全新的开发模型，有没有遇到什么问题？

对于Visual Studio开发来说最常见的问题，可能与我们中国的客户并不完全一样，因为我们碰到的问题是跟我们团队人数有关系。中国的开发团队规模可能大多是50、100，200差不多就是上限了。我们的Visual Studio开发团队大约两三千人，就像军队管理一样，你管理50个人、100个人、500个人、1，000个人、2，000个人，协调的难度会非常不同。如何在2，000多人的团队，同时每一个小的团队差不多是50到100人，实行敏捷开发？在这个过程中，怎么样能够把所有的数据汇总起来？作为管理层，你可以很清晰地知道你这个团队到底做到什么程度了，什么地方是做得不错的，你可以放心的；什么地方是遇到了很大的困难，这个团队可能是一个非常重要的团队。比方说，如果是CLR 团队碰到了问题，那它的影响面是非常大的，因为我们所有的东西都构建在它之上。你怎么知道哪一个团队做到了什么程度，所碰到的困难是什么，采用些什么方法来补救，这些都是我们做得比较多的地方。从一个小的团队来说，也会碰到这种问题，但只是规模和扩展没有这么难就是了。

还有作为管理者，比方说一个50到100人的团队，你下面可能有7个、10个不同的功能组，在做不同的东西，你怎么知道每一个功能组实施到什么地方了，他做得好不好？功能组一般来说互相之间是关联的，有很多时候你去找一个功能组，也许他说我正在等前面那个人做完，我才能实施下面一步，那你对这种关联的理解是不是很清晰？这些是最常见的问题，实际上是Dependency Management（依赖关系管理）。我跟你解释一下，因为我们组太大了，很多东西需要CLR 团队先做，做完之后，要交给C# Compiler团队，再做下面一个功能，C# Compiler团队做完之后呢，我才能把它接过来，再做我下面的东西，这是非常常见的一个开发场景。这时候我们在做一开始prototype的时候，先需要定义几个大的里程碑，而且每个大的里程碑在你结束的时候，都要说清楚，哪一组跟哪一个组有哪一些可交付的，要做到这个里程碑里面的。在里程碑结束的时候，你可以非常快地一目了然，是不是每一个deliverable都已经做到了？如果有哪个deliverable没有做到的话，你可以很快的知道他下面的影响是什么。因为有时一个部分没完成，下面可能有一串的东西都没有办法做。我们很多这种数据的汇总都是在我们自己Team Foundation Server里面做的，我们用Team Foundation Server 的Reporting Feature把我们一开始把数据都放进去。这样的话就很明显可以看出来，虽然团队可能把这个deliverable做到了，但也许质量有问题，你怎么知道他这个东西的质量是不是合格？

还是影响其他的？

对，有的时候他说“我做完了”，但是我根本就不能用，每跑一步都是有很多臭虫（bug）蹦出来，这也是很常见的问题。所以我们设计了一套比较严格的Quality Gates，你自己功能组做完之后，要通过所有测试程序，你才能把功能放到我们总的数据库里面。这套东西包括localization（本地化），因为我们的产品都有很多种语言版本，你localization有没有做过、测试过？像德文的字符串会非常的长，可能英文本来这么长的一句，变成德文就会长一倍，这时在你屏幕上显示，会不会有什么东西给砍掉，这种测试有没有做过？我们还有做代码覆盖率，你的代码覆盖率跟单元测试有没有写完，你的单元测试有没有写到50%、60%代码覆盖率，没有达到这个程度，我们是不允许你check-in（签入）的。另外你有没有测过新功能对原来的性能有没有任何影响，原来的性能，比方说应该是0.5秒就跑完的，你加了新功能之后，是否现在变成要0.7秒或者1秒才跑完？另外，你有没有做集成的测试，这些东西都是我们Quality Gates一部分。所以你做一个东西要把这些东西全部都满足了，才能让你允许你到软件包里面去。这样每进来一个东西，都是相对来说比较高质量的东西，这也是我们在Visual Studio 2005版本里学到的一个比较惨痛的教训，因为在做Visual Studio 2005的时候，我们并没有采用这种方法，所以很多程序做到一半，差不多可以演示了，我们就让它Check-in了。因此之后，我们花了很长很长时间使每一个功能真正达到高质量，但是这个性能已经放在产品里面去了，又很难把它再给拿出来，所以当时产品延期（的原因）跟这个有非常大的关系。我们现在改变做法，每一个功能组做的每一个功能，都要达到高性能，你才能把它集成进去，这样你等于是每一步每一步都是稳扎稳打。从一个产品的质量来说，基本上是我每一个产品放进去之后，如果不做其他的产品，再花几个月让它整个集成稳定一下，就应该可以把它发布的，到这样的程度才让你集成。这从敏捷开发来说，你可以很快地体现这个价值，这也是一个敏捷里面非常重要原则之一。

也有人说在Visual Studio这个产品中去集成敏捷开发项目，完全是微软的一个应景之作。因为敏捷现在很热，在这个产品里面去集成敏捷可能更加好卖，因为微软可能没有完全理解敏捷的精髓，它里面有个原则：个体和交互胜过过程和工具。你对这个看法有没有什么自己的解释？

我给你讲个故事。我在微软Visual Studio做过一个职位──开发总监，开发总监这个职位实际上非常有趣的。怎么样让类似Visual Studio有几千人的开发团队能够互相协调、共同前进，是一个很关键的事情，因为你面对的对象是几千位工程师。比如，我们自己会推动很多不同的流程，你跟他们说，一个工程师没有遵循一个什么流程，把我们每天的Build给破坏了。今天你提出要遵守这个流程，过两天你说你要遵守那个流程，或者这边再加一步，在那边再加一步，在这个时候你会发现你可以给他们很多流程上面的规矩，你要做一二三四五，但是他们是记不住的，他们在做的同时他们有很多考虑。

不是流程化的东西？

不是流程化的东西。我后来就发现，如果没有一个工具去帮助实现这些规矩的确话，你要靠每一个工程师都记住这些规矩，那是非常非常难的，基本上是不可能的。所以，我们就做了另外一套东西。在工程师把代码check-in之前，我们要求他做可能有六、七步不同的东西。而且我们常常又发现一个比较常见的问题，再加一个步骤，这个时候如果有上千，就算有几十个工程师，保证每一个人都记得有这么一回事情并做到，实际上是很难的事情，这是人员管理上面的一个难题，因为工程师有很多要考虑的东西。你要是真觉得什么规则是非常重要的话，就把它做到工具中，所以每个开发工程师，在check-in之前，要做code review，要跟对应的测试工程师做buddy test（伙伴测试），看看有没有问题，之后还要做unit test （单元测试），跑一堆测试工程师的测试，把这些事情都做完，才能够check-in。我把这套东西全部变成了一套工具，然后就变得非常简单。比方说，谁帮你做code review了，你把那个人的名字放进去，测试工程师帮你做buddy test是谁，把他名字放进去，你的unit test，跟你下面的测试，以及后面的集成测试，我们用工具帮你跑了，跑完以后确实没有问题，就帮你自动check-in。全部做成工具化后，这套流程对工程师来说是非常简单的，如果单元测试要加新程序进去，我就把它做在工具里面，工程师也不用记，工具跑下来没有问题就可以帮工程师check-in，如果不行就打回来。所以，工具是起到一个辅助的作用，工具不能保证你什么样是最有效的，这需要团队的管理者跟团队一起去决定。工具不能帮你决定现在去北京还是去上海，还是去三亚，这个问题要团队自己解决。但是工具帮你最快实现目标。

因此我们自己运用了很多Agile方面的东西，试用我们自己开发的Team Foundation Server，所以我觉得我们对敏捷的理解是基于我们工具实施上的，并不是我们的应景之作，应该是用我们的教训，把它变成了一个工具，我们自己在用，也希望我们用户也能够使用。

我也知道在Visual Studio新版2010里面，MSF 5.0，比从前有了很大的改进，能不能给我们简单的介绍一下，它主要的改进是在什么地方，特别在敏捷开发方面？

我们Visual Studio Team Foundation Server在2010版本里确实有非常大的改进。从最简单的来说，我们2005和08的Team Foundation Server，从一开始的Setup，把它这个安装起来，就是一个相对来说比较困难的事情。我们在这上面其实做了很多的投资，（把它变成）非常简单，就是下一步、下一步，帮你全部设置了。

从敏捷开发来说，我们很多的团队，尤其50、100人、200人的团队，他们下面肯定有些有关联的分支，我们在Team Foundation Server分支的管理上面，在2010也有非常大的提高。举个我们Visual Studio的例子，Visual Basic Compiler是一个分支，C# Compiler是一个分支，C++ Compiler又是一个分支，我团队在做的SharePoint Tools又是一个分支，Office Tools是另一个分支，这些都是不同的分支。这之间有很多关联，在Team Foundation Server 2010里面我们有一套可视化的东西，你可以知道每个分支是从哪一个分支上面延伸下来的，就像树一样。很多时候，你会知道哪一个check-in的东西可能会需要搬到另外一个分支上，可以让你非常简单易行地管理它。而且从敏捷开发上面来说，这里面有些非常重要的项目管理，包括burn-down chart，集成以前资源，资源里还有多少工作需要进行，我们在Excel上全部帮你实现了，帮你管理这些报表。同时，因为SQL Server是Team Foundation Server的数据库，你可以很容易用SQL Server的报表功能来生成你领导所需要的报表。

很多时候团队需要共享资源，在微软每天早上一个开发工程师进办公室后需要知道前一天晚上的build出来没有，在什么地方，有没有什么问题。你昨天晚上睡觉的时候，也许中国的测试团队，给你找到了很多的臭虫，又发现了什么问题。晚上集成build后，我们会运行一整套测试，测试里面又出现了什么问题，今天还有哪些本来要做的backlog任务、工程要做，这些东西你现在作为一个工程师，可能要去各个地方通过不同的工具来把它找到。在Visual Studio的Team Foundation Server里面，我们给你做了等于是一个门户，每一个工程师一上班，对所要的东西都一目了然，这是在我们SharePoint Server的基础上面做的。

我以前在做开发经理的时候，盯得最紧的，第一是还有哪些开发任务没有做，另一方面就是每天产生的臭虫。每一个人产生的臭虫，我都非常快地看一遍，这对开发管理人员来说非常重要，不是说我真的想知道这个臭虫应该怎么解决，我会很宏观地看一下，有个大致印象，这个产品里面哪个部分臭虫特别多，然后可能过了一星期发现，为什么我这一部分一个臭虫都没有看见，这可能是因为开发人员特别厉害，也有可能是这个测试人员特别差，或者协调中间忘了，测试人员根本就不知道有这么一个场景。作为管理者，你要有这种宏观概念，而且可以很快地生成一些报表，知道这个到底有没有问题。

如果你的开发团队比较大，几十人开发团队，一个开发人员比较好，做得又快又好，另一个开发人员可能改这个臭虫改得很快，但下个星期他改的臭虫里又生成很多臭虫，这是很常见的问题。虽然他臭虫改得很快，他生成速度也非常快，说明他改的过程中没有考虑周到，那你怎么能够知道这些开发人员到底在做多少事情。在敏捷开发里，你还要知道同样一个任务，给这个人和那个人，两者可能需要的时间是不一样的。怎样定义分配多少时间、监督每个人是否按时完成，你给他规定的时间是否准确。因为你第一个里程碑的时候可能定义不准确，也许这个任务对第一个人来说太简单了，你给他三天，他两天就做完了，那么下一次，有类似的任务，你给他两天就够了。对另外一个工程师，也许他觉得这个任务比较有挑战性，要花的时间相对比较长。这些数据你都要汇总之后，你才能做你下一个里程碑的规划。如果你不去考虑这些问题，你下一个规划做出来一定有很多的错误。敏捷开发另一个很重要的基本原则，你每做一个规划，每做一个迭代，都是一个学习的过程，你什么地方做的对，什么地方做的不对，你把这些经验再放到下一个迭代的规划里面去，这样你每一个里程碑都比上一个做得更好，更贴近你想做的，跟你实际做到的越来越吻合，这才是敏捷开发的精髓之一。这是一个逐步完善的过程，如果没有敏捷开发这个精髓，我跑上来，就把我下面五个里程碑全部给换了，中间要再调整其实是非常困难的。

最后一个问题，对于那些想基于Visual Studio去实施敏捷的团队，比如50到100人的团队，能不能给出三到五条建议来？

第一，希望大家赶紧开始使用我们的Team Foundation Server，因为Team Foundation Server在2010版本中另一个很大的改进，就是对“跨平台”的支持。以前大家都认为它只适合用.NET或者C++的项目，我们在Team Foundation Server2010版本中大大提高了对“跨平台”的支持。Team Foundation Server实际上是开发了一个平台了，上面有很多Web Services，和API，有一个Teamprise公司就是用这些API另外做了一套客户端，可以在Mac上面跑，也可以在Linux、Unix上面跑，也可以集成在Eclipse里面。我们刚刚收购了Teamprise，（通过）这个公司，我们会进一步支持这种跨平台的模式。这样很多项目，用户常常会用Java做服务器端，用.NET做客户端。这时，如果你把两个项目分开管理，实际上不是一个最好的方式，现在我们给你Team Foundation Server，你可以在同一个服务器上把整个项目，不管你是用什么平台来做，都可以把它整合在这个服务器上。而且它和我们的Microsoft Project，也有非常好的集成，那就给管理者很大的便利。真正的大的50、100人团队到底在做什么，有哪些问题，哪些东西是你需要去关心解决的；哪个团队做得好，对项目最后的影响是什么；哪些用户的场景已经做出来了，现在开始跟用户的交流了，这些问题就会变得非常的一目了然，这是第一方面。

第二个方面，刚才说的工具，是给管理者提供的。但有了这个工具，并不等于取代了管理者的重要性，管理者还是主导的。你要建立一个高效的团队，团队成员之间，互相要有一种非常合作的（精神），要有同样的目标，大家都知道在做什么，工具只能帮助你进行这种交流，但是管理者的工作程度和难度并没有完全减轻。因为你每设计一个目标，需要团队的认可，让他们能够全心全意地、目标一致地前进，这种精神、这种力量，不是说哪个工具可以帮你做到的，还需要管理者实现这些事情。

最后，我们在用Team Foundation Server进行敏捷开发的时候，要时时刻刻记住敏捷最重要的精髓，不要让过程化的东西来妨碍我们的思维，不要把自己放在一个条条框框里面，敏捷一定要一二三四五。敏捷最最重要的是，根据不同的用户场景、需求，可以很灵活地调整实施方案。这个项目上用法成功了，并不等于说这套方法在另外一个项目上完全可以照搬的。你还要分开来考虑不同的因素，可能客户需求不一样，下面工程师的质量、长处各方面会不一样，因而实施方案会有不同。记住敏捷就是用最好的方法帮你来实现你的项目，它最主要的是跟用户有非常多的交流，帮助你的团队能够团结一致地、很快地朝一个非常明确的目标行进，这些才是敏捷的精髓。

感谢你接受我们的采访。

谢谢。

潘正磊谈微软研发团队管理之道相关推荐

潘正磊谈微软研发团队管理和敏捷实践学习总结
个人成长 1. 你对这个团队有什么贡献,你对你的客户有什么贡献? 2. 目前的流程存在什么问题,要怎样改进? 3. 怎么样能够跟大家交流,怎么样可以说服大家同意你的观点,怎么样听取别人的反馈? 4. ...
潘正磊谈微软研发团队管理和Visual Studio开发过程中的敏捷实践
潘正磊谈微软研发团队管理之道 http://www.infoq.com/cn/interviews/team-management-panzhenglei 先给我们介绍一下你自己和你自己现在所做的事情 ...
独家对话微软顶级代码女神潘正磊：Visual Studio 与 VS Code 的未来走向 | 人物志...
题图.作者 | 唐小引出品 | CSDN(ID:CSDNnews) Visual Studio 到今天,已经有 22 年的光景,因为它强大的功能和支持几乎大部分语言的开发.丰富的扩展插件等,中国开发 ...
独家对话微软顶级代码女神潘正磊：Visual Studio 与 VS Code 的未来走向 | 人物志
题图.作者 | 唐小引出品 | CSDN(ID:CSDNnews) Visual Studio 到今天,已经有 22 年的光景,因为它强大的功能和支持几乎大部分语言的开发.丰富的扩展插件等,中国开发 ...
潘正磊：再过三五年 AI会变成开发人员的基本概念
在微软Build 2018开发者大会上,微软公司全球开发平台事业部的资深副总裁潘正磊(Julia Liuson)接受了界面记者在内的采访. 潘正磊在微软西雅图总部带领一千多人组成的团队,微软的开发工具 ...
潘正磊再过三五年 AI会变成开发人员的基本概念
在微软Build 2018开发者大会上,微软公司全球开发平台事业部的资深副总裁潘正磊(Julia Liuson)接受了界面记者在内的采访. 潘正磊在微软西雅图总部带领一千多人组成的团队,微软的开发工具 ...
从一个故事开始谈项目与团队管理
目录一.团队建设 1.1.注意高效的研发团队建设 1.2.稳定的团队 1.3.PM非常关键二.规范过程 2.1.合理的安排工作计划 2.2.开发前制订开发规范 2.3.项目完成时注重归纳总结 2. ...
研发团队管理：IT研发中项目和产品原来区别那么大，项目级的项目是项目，产品级的项目是产品！！！
若该文为原创文章,转载请注明原文出处本文章博客地址:https://blog.csdn.net/qq21497936/article/details/116087039 长期持续带来更多项目与技术分 ...
【CTO论道】京东商城李大学：京东研发团队管理经验谈
摘要:在今年SDCC的CTO论道特色论坛上,京东商城高级副总裁李大学与二十多位受邀参会的国内一线技术管理者一起做了交流,并发表主题演讲.演讲中,李大学分享了京东研发团队的组织架构以及自己的研发团队管理 ...

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

潘正磊谈微软研发团队管理之道相关推荐

最新文章

热门文章