概要

    近日InfoQ有幸獨家專訪了微軟Visual Studio Business Applications團隊的總經(jīng)理潘正磊，與她探討了微軟研發(fā)團隊管理的相關(guān)問題：技術(shù)人員的職業(yè)發(fā)展、如何培養(yǎng)接班人、如何管理不同規(guī)模的研發(fā)團隊等等，

Visual Studio總經(jīng)理潘正磊談微軟研發(fā)團隊管理之道

。

    個人簡介

    潘正磊女士是位于美國雷德蒙市的Visual Studio Business Applications團隊的總經(jīng)理。這個團隊通過提供多種工具，使全球開發(fā)人員能便捷地在微軟平臺上搭建商業(yè)應(yīng)用程序。她同時領(lǐng)導開發(fā)工具部門的中國研發(fā)團隊，進行Visual Studio、Visual Studio Team System等產(chǎn)品和技術(shù)的全球研發(fā)工作。92年，她以軟件開發(fā)員的身份加盟微軟，參與Access、Visual InterDev等產(chǎn)品的開發(fā)。1998年至2006年間，她先后擔任Visual Basic.NET開發(fā)經(jīng)理、Visual Studio產(chǎn)品線開發(fā)總監(jiān)、Visual Studio Team Architect產(chǎn)品總經(jīng)理和Visual Basic產(chǎn)品總經(jīng)理，為專業(yè)開發(fā)人員提供在.NET平臺上最高效的開發(fā)工具，使數(shù)百萬Visual Basic 6.0用戶遷移到.NET平臺。

    先給我們介紹一下你自己和你自己現(xiàn)在所做的事情吧？

    我是在1992年大學一畢業(yè)就參加了微軟，一開始是做開發(fā)程序員，就是Developer，最開始開發(fā)的項目是Microsoft Access，現(xiàn)在也是微軟賣的很好的一款產(chǎn)品。在Access開發(fā)了幾年之后，我轉(zhuǎn)做另外一個產(chǎn)品叫Visual Interdev，那是我們微軟第一款針對網(wǎng)絡(luò)Web做的開發(fā)工具；那之后我在Visual Basic團隊做Developer Manager，就是開發(fā)經(jīng)理的職位，當時我們整個從VB6到VB.NET 轉(zhuǎn)型，所以跟.NET做平臺開發(fā)，是一個非常艱苦的項目。之后還在Visual Studio里做了一系列的職務(wù)，包括開發(fā)總監(jiān)，包括我們Visual Studio Team Architect的產(chǎn)品總經(jīng)理，包括Visual Basic的產(chǎn)品總經(jīng)理�，F(xiàn)在是Visual Studio Applications的產(chǎn)品總經(jīng)理，像我們剛才所說的，主要我們這個團隊做的是針對企業(yè)的開發(fā)工具。

    你是從一個基層的開發(fā)人員一直走到現(xiàn)在，那我想，在你整個過程中應(yīng)該是有很多的感觸，特別是從一個開發(fā)人員然后到一個管理職位，在整個過程中有沒有什么比較難忘的事情？

    因為已經(jīng)工作十幾年了，所以說，確實有很多故事了，我覺得比較難忘的幾個故事，還是跟我們最高層打交道的時候比較有趣。我們在做Visual Interdev的時候，那是我們第一款針對Web的產(chǎn)品，當時微軟對Web的定義、對Internet的戰(zhàn)略不是非常清晰。記得我們跟Bill Gates在做產(chǎn)品Review時候，他一開始對我們這個產(chǎn)品是有些意見的。他說，你這個產(chǎn)品做出來以后，對Windows有什么好處或者是壞處。這是一個挺尖銳的問題，讓我們所有人回去都要好好想一想。

    還有最近我們在做另外一款產(chǎn)品Review的時候，也是跟我們Steve Ballmer，我們的CEO，跑上來我就要給他做一個演示Demo，我們的CEO就說現(xiàn)在所有演示都不要做，他叫我們最資深的副總裁，“你就到黑板上面去，把你們這個產(chǎn)品要做出來的三個目標先給我寫上去，寫完以后我們再做演示，看你這演示有沒有達到你這三個目標”，這個跟Steve Ballmer做Review常常會碰到這種情況。

    他會直接幫你梳理你的產(chǎn)品目標？

    他會用你很意料不到的方法來問你，因為一般我們?nèi)プ鲞@種總裁Review都是有準備好一套PowerPoint，有一套我們自己的思路，他就會從你的思路之外問一些問題，保證你確實能夠解釋出來你為什么要做這個東西，然后你的思路是什么，你的戰(zhàn)略是什么，這是一些蠻有挑戰(zhàn)性的東西。

    在你的個人從開發(fā)人員到一個團隊管理的過程中，在做團隊管理的時候有沒有遇到一些困難、一些比較難忘的事情？

    做團隊管理的時候，因為團隊管理最主要的是幾大塊：第一，你要造就一個非常強的團隊。這中間有很多（差異），你這團隊是你自己接手的，還是這個團隊是你自己一個一個雇傭進來，這個完全是不同的。還有和你的Partner（合作）團隊，因為微軟很多項目需要好多幾個團隊來一起合做才能做好，那跟你Partner的這個運行過程中也有很多的這種Interaction（互動），有的時候如果大家的戰(zhàn)略目標不一樣，就會造成很多各種各樣的問題，那所以這都是有很多故事的。我現(xiàn)在一下想不出來一個特別好的、最有挑戰(zhàn)的。因為從組建團隊中，這么多年走過來，基本上什么場景都碰到過了，所以我還真一下想不出來一個最好的故事，或者是說最有挑戰(zhàn)性的故事。

    其實我也了解到在你整個的發(fā)展過程中，到最后成為全球微軟有兩千多個總經(jīng)理，你是為數(shù)不多的華人，那么從整個階段來看，你是如何去總結(jié)自己的這段歷史？

    我覺得微軟現(xiàn)在華人的總經(jīng)理比較少，但是我覺得從長遠來說肯定會越來越多，這實際上是我們在九幾年有大量的大學畢業(yè)生開始出國，然后開始在美國，或者這種（國外的）地方開始就業(yè)有關(guān)。我相對來說出國比較早一些，所以我進微軟也很早。那像九幾年之后，95、96，包括90年代末期，有大批的中國員工進入微軟，所以我相信這以后的華人工程師或者華人總經(jīng)理，各方面只會越來越多。那另一方面，在微軟或者是在很多大企業(yè)里，自己的一步一步都是要慢慢走過來，然后都是要腳踏實地，最主要的是要想到說你對這個團隊有什么貢獻，你對你的客戶有什么貢獻，如果能夠比較的專注于某方面工作的話，那我覺得在成長中是很有好處的。

    進入微軟的華人很多，工程師也很多，但我想也淘汰了很多，最終可能會有一個人冒上來，而且這個人就是你，我想問一個比較直接的問題，你覺得為什么會是你走到今天這個位置？

    我覺得每個人的長處是不太一樣的，我覺得我自己的長處，第一是技術(shù)方面還不錯，因為一開始在做工程師，如果你技術(shù)上面做不好，是不可能往上走的。另一方面，我覺得我對資源整合這一方面是比較強的，我的一個強項是我很快就能看出我下面的員工他們最適合什么，他們不太適合什么，那把他們放在最適合于他們的工作崗位上。這樣第一能夠是最大的調(diào)動他們的積極性，第二整個團隊可以成一個非常高效的團隊。

    而且我在管理人員方面，很多跟我做了很多年的員工，愿意跟我做很多年，所以這也是作為一個領(lǐng)導者應(yīng)該比較重要的素質(zhì)。

    我覺得是這些是可以學的，但有些可能有的人就會比較容易一些，比較自然一些，有的人可能就是要學的更多一些。

    但是我想在你的團隊里面應(yīng)該也有一些能力非常強的，比如說他的存在會讓你有所威脅，那么在這種情況之下，你是如何和他們相處的？

    你看，我這個考慮思路跟你完全不一樣，我不會覺得我團隊里面有誰對我是有所威脅的，我的出發(fā)點就是我希望能夠培養(yǎng)一批人才，如果有一天我能夠不用去上班了，而且我的團隊還可以執(zhí)行得非常好，這才是我的目標，所以我是希望有人能夠來代替我。

    因為微軟里面包括很多公司是這樣的，有挑戰(zhàn)性的工作是非常多的，如果我這個工作做完了，如果我下面培養(yǎng)出一批人才，能夠取代于我的話，那還有更加具有挑戰(zhàn)性的工作在等著我去做，所以這個思路不是說有這個人會對我造成危險性，而是我如果有一天能夠找到一個，或者請到一個比我更強的員工，這是一個非常高興的事情，非常令人振奮的事情。

    實際上在我的職業(yè)生涯中也確實有過這樣的經(jīng)歷，我那時候在做Visual Basic開發(fā)經(jīng)理的時候懷孕了，我知道會休蠻長的產(chǎn)假，而且一度還動過可能不回來上班的想法，做全職媽媽的這種心思，所以我那時候就把我下面的一個開發(fā)主管，一個開發(fā)主管一直培養(yǎng)他，而且當時就是培養(yǎng)他到最后，我去休假之前，說那這個團隊就交給你了。等我五個月休完產(chǎn)假回來之后一看，那個團隊雖然是我打造的，交給他之后他還是管理的非常好。我說太好了，那你就來做開發(fā)經(jīng)理。那個時候我就去做了我們Division另外一個工作，整個部門的開發(fā)總監(jiān)。

    就像我說的，這世界需要能人的事情非常的多，所以你是一個能干的人你不要有這種危險感，因為需要你的地方是非常多的。

    所以我想，一個人的自信對于他的整個的成長是非常有幫助的？

    實際上我覺得如果在微軟來說，如果你沒有自信，那你可能很難從一個開發(fā)工程師往上走非常的遠。因為在微軟我們招的都是，真的是世界上英文詞叫“cream of the crop”，都是最最頂尖的大學生，或者是外面有經(jīng)驗的人。在這樣一種環(huán)境中，你怎么樣能夠跟大家交流，怎么樣可以說服大家同意你的觀點，怎么樣聽取別人的反饋，自信心實際上是一個非�；�本的素質(zhì)。如果你沒有這個素質(zhì)，就是作為一般的開發(fā)工程師也不會走的太遠的。

    另外我比較好奇的一點，比如說在你整個的幾個階段里面：有基本的開發(fā)人員，然后到一個比如說項目經(jīng)理、一個產(chǎn)品的帶頭人，然后再成為一個產(chǎn)品的總監(jiān)，最后成為總經(jīng)理，那么這幾個段它有什么特別的不同嗎，除了你管理的人越來越多？

    那是有非常大的不同的。作為一個開發(fā)工程師來說，你最主要的是要把你的代碼寫得越快越多越好。因為你對產(chǎn)品的貢獻是鑒于你代碼的數(shù)量，你寫代碼數(shù)量直接就反映成你對這個產(chǎn)品功能多少的體現(xiàn)，你的代碼行寫得多，那這個功能才增加得多，你寫的代碼行是最難的那部分，那才說明你對這個產(chǎn)品最主要的核心部分有貢獻，這是作為開發(fā)工程師。

    作為一個開發(fā)主管來說，就是我們叫Development Lead，第一方面，作為管理者，你對這個團隊的價值，不僅僅是說你自己寫了多少行代碼，這相對來說是比較少的，最主要是你這個團隊對整個產(chǎn)品的貢獻是什么，那還是基于你這個開發(fā)的功能有多少，然后你這個功能是不是做得好，你架構(gòu)是不是做得好，但是你的核心價值是把你這些資源都組合起來，然后能夠幫助你團隊的員工掃平障礙，讓他們非常順利地開發(fā)。

    像我最開始做管理的時候，我只管理了三個員工，有一個員工如果做得慢一點，那我最多周末去加一加班，他沒有做完幫他補做完就完成了，我覺得相當簡單的一件事情。等我那個團隊長到10個人的時候，你就發(fā)現(xiàn)，第一，不可能我周末再來加班，也不可能把10個人里面有兩三個人可能要做的慢一點，如果按同樣的比例來說，我不可能把這兩三個人要做的東西都做完了。那這個時候你要做，就是我們從這個Skill來說，如果要整個團隊都能夠非常順利高效，你就要想“我怎么樣讓這十個人互相之間能夠（協(xié)調(diào)好）”，就是很多程序是有順序的問題，把順序問題安排好，有些東西可能要需要一些決定，盡早的把決定做好，下面的架構(gòu)可以做好，跟其他團隊的關(guān)系要搞好，因為他們可能有些東西要拿來，他們先做完之后我們才能做，所以有很多東西Dependency Management，這些東西全部都要管理好，就像造房子，管理一個項目一樣。這樣管理好你這十個人才能都是馬不停蹄、非常高效地把這個東西做好。

    等你做開發(fā)經(jīng)理的時候，開發(fā)經(jīng)理因為不是一個第一線的管理者，而是第二線的管理者，這個時候最最有挑戰(zhàn)性可能是，你很多東西要通過你第一線的開發(fā)主管傳達到下面去，如果你開發(fā)主管對你說的話不認可，那你的觀念、決定不一定真正能夠傳達到最下面的開發(fā)人員。而且你下面的開發(fā)主管可能每個人都還要管一攤不同的東西，你怎么樣讓他們之間能夠互相配合、互相合作，從一個大局上面來看你整個這個開發(fā)團隊缺什么，有的時候他們開發(fā)主管在那里面做，他不一定會知道說，我實際上比較缺一個真正能幫我把這個架構(gòu)搞在一起的人，或者一個特別懂客戶的人，那要把這個全部都想清楚，真正打造一個非常強的團隊，這又是另外一套的藝術(shù)，我覺得。

    在微軟如果你不懂這產(chǎn)品（技術(shù)），你是沒有辦法做一個合格管理者的，你不僅要做人員的管理者，你還要做這個產(chǎn)品的定義，而且還要跟你的團隊交流，什么地方是應(yīng)該做的，什么地方是不應(yīng)該做的。

    是多重角色了？

    對，因為從開發(fā)經(jīng)理來說，我在美國喜歡說三個P，你要管理產(chǎn)品（Product），你要管理人員（People），你還要管理流程（Process），這三樣東西都要抓起來，你才能作為一個合格的開發(fā)經(jīng)理，然后讓整個團隊都能高效地運行。

    他和現(xiàn)在的總經(jīng)理有很大的區(qū)別嗎？

    非常大的區(qū)別，因為從開發(fā)經(jīng)理來說，他還只是主要是管開發(fā)團隊的。開發(fā)團隊總的來說只是占了可能是1/3�？偨�(jīng)理跟產(chǎn)品經(jīng)理是兩個不同的概念，產(chǎn)品經(jīng)理是說你管一個產(chǎn)品，那總經(jīng)理你是管多種產(chǎn)品，像我剛才所說的，實際上我現(xiàn)在這個組里面有三種不同的產(chǎn)品。

    那這三種不同產(chǎn)品很多時候會有不同的進度表，發(fā)布時間會不一樣。怎么樣把里面相同的東西能夠整合出來，讓大家最有效地利用，而且還要針對每一個產(chǎn)品有他特別的開發(fā)。怎么樣管理這一套產(chǎn)品線，而且跟我們的市場部，跟我們的營銷部，跟我們的DPE（開發(fā)工具及平臺事業(yè)部），那些合作都是在這個層面上面是完全不同的。而且在這上面你就更要想說，這幾個產(chǎn)品，就像我們叫Portfolio（投資組合），就好像如果你要是投資，你可能有些放風險基金，有些放銀行存款，有些是放外匯，你還要再從比較高的角度上，看你每一個產(chǎn)品到底里面放多少的資源進去，為什么這個產(chǎn)品放這么多資源，而且要看你成功的定義是什么。

    而做一個產(chǎn)品的開發(fā)經(jīng)理，這么多資源實際上已經(jīng)分配給你的，你在這個資源的基礎(chǔ)上面把它做到最大最好，所以這還是不同的概念。

    更加強調(diào)統(tǒng)籌的作用，那我們回到技術(shù)層面來講，在你的身上可以看到一個，我認為他是微軟一個研發(fā)團隊的技術(shù)變遷史，或者一個縮影。那么我想問的問題是，在你的理解當中，從你進入微軟研發(fā)團隊一直到現(xiàn)在，在整個的產(chǎn)品的開發(fā)過程中，主要經(jīng)歷了哪幾個比較重大的階段？

    我覺得這個問題非常好，因為你讓我回想了一下。確實有幾個非常大的不同（階段）。

    在我進微軟的時候還是微軟比較新，很多產(chǎn)品還是剛剛第一代，像我那時候做Microsoft Access，現(xiàn)在已經(jīng)無窮代了。那時候剛剛是第一版，當時發(fā)布時非常振奮人心的，

管理資料

《Visual Studio總經(jīng)理潘正磊談微軟研發(fā)團隊管理之道》(http://m.oriental01.com)。如果打一個比喻，就比較像我們80年代剛剛開放的時候，那時候商品比較少，用計算機的人數(shù)少，相對來說需求也少。所以那個時候從微軟來說，只要發(fā)布產(chǎn)品就會有很多的用戶來使用。因為我們有很多很基本的需求，而市場上卻都沒有。那我們發(fā)布的產(chǎn)品只要大面上不錯的話，就可以非常容易地滿足用戶的需求。從Word第一版開始發(fā)行的時候，前面幾版你可以想有很多很多基本的功能是，現(xiàn)在覺得都是肯定是應(yīng)該有的，但是當時都是很新的東西。

    但是產(chǎn)品在做了時間久了之后，等你發(fā)布第五版、第六版、第七版、第八版的時候，這時有很多基本的用戶需求已經(jīng)滿足了，在那個前提上怎么樣把你的產(chǎn)品更上一層樓，這實際上就變成一個相對來說比較困難的問題。很多時候，像我們的Office團隊最大競爭者不是別人，是前面一個版本的Office。所以在一開始我覺得我們在微軟里邊定義產(chǎn)品的時候，比方說90年代初，跟客戶溝通之后我們就是用一個Waterfall（瀑布式開發(fā)模式）這種Model，因為我們覺得我們知道這個產(chǎn)品應(yīng)該做什么，我們就把它做完了，然后放在外面市場上，相對來說一定是賣得不錯的，賣得很好的，所以這是我們比較成功的一個模式。

    自己可以主導？

    當然我們還是要跟客戶有反饋，一開始要跟客戶研究，但是我覺得相對來說做得少，而且相對來說比較容易滿足客戶的需求。因為那時候大家的基本需求有很多都沒有滿足。等到我覺得差不多就是99年、2000年，就是差不多那個階段，我們那時候很多產(chǎn)品已經(jīng)開發(fā)了好幾代了，等到那個時候我們就有一個危機，因為我記得是差不多是2000年的時候，那時候客戶對我們的滿意度相對來說比較低，而且我們跟合作伙伴的關(guān)系相對來說比較僵一點，在美國還有很多的訴訟案，那個時候我覺得實際上是微軟處于一個比較低潮的階段。但是從那之后，我們確實就開始轉(zhuǎn)型了，我覺得一個最基本的理念，我自己有這個感受，一開始就覺得說我們可以定義這個產(chǎn)品，定義了以后就做，做完以后賣，這是我們最開始的運營模式。

    大概是2000年之后，我們就發(fā)現(xiàn)對用戶反饋的需求變得非常多，而且一個版本一開始跟用戶反饋一次是遠遠不夠的。從開發(fā)模式來說，開始時我知道什么是對的，我知道用戶需要什么，我只要開發(fā)什么，這是我們本來的模式。在那之后，我們的模式時我不太確定用戶確實需要的是什么，我們可能要先做一些prototype，試驗品出來，讓用戶去體驗一下，體驗完了以后再給我們反饋，這是不是他們確實要的，我們在這個反饋基礎(chǔ)上再更改。所以你可以看出來整個流程，一開始的想法跟后來想法是不太一樣的，而且我們在2000年以后，在后面的開發(fā)中，對用戶的反饋的需求比以前是大大增加了，而且我們fundamental mindset（最基本的理念），從一開始我絕對知道什么樣是一個對的產(chǎn)品，到我不太確定，那我需要跟用戶多次反饋，才能知道真正什么是對的產(chǎn)品，那這兩個其實是非常不一樣的開發(fā)模式。我們之后開始用這種開發(fā)模式之后，因為微軟作為一個很大的團隊，確實也碰到很多的挑戰(zhàn)，因為很多時候你要想改一點東西實際上是非常難的。

    涉及到方方面面。

    方方面面，我就喜歡說，像你要是自己想在家里后院造一個小房子，你怎么改都沒有關(guān)系。但是你要想造金茂大廈，造到一半想改一點什么東西，那你可以想到有很多的東西要配合。你如果要改一點東西，那對你的電梯、電路、樓層、重量，都有很多的考慮因素在里面。

    那作為一個大的開發(fā)團隊，你怎么樣能夠同時滿足客戶的需求，又能夠在你的架構(gòu)基礎(chǔ)上能夠做這種改動。因為最后你的產(chǎn)品還是要滿足客戶需求，才能夠有賣點。你怎么樣做這么一個調(diào)整，這也是我們在前七、八年中慢慢轉(zhuǎn)型的過程。那相反過來，你如果看，拿我們Visual Studio作為一個例子，從08年，我們前面幾個例子看到我們開始大量的出我們叫CTP（Community Technology Preview，社區(qū)技術(shù)預(yù)覽版），而且跟我們的客戶、開發(fā)人員的交流變得非常的透明，很多時候我們很早就把我們想做什么，愿意做什么，有的時候把我們寫的Spec，就是產(chǎn)品定義放在網(wǎng)上，給我們的MVP（微軟最有價值專家）先讓他們反饋，我們現(xiàn)在做很多這樣的工作，在這之前都是沒有的。

    對于你們內(nèi)部的開發(fā)團隊來講，產(chǎn)品的設(shè)計方面是有很大的挑戰(zhàn)，也是一種很大的轉(zhuǎn)型。那么你們在自己做開發(fā)的過程中是不是也有一些分為幾個階段來呢？

    對！如果是按以前的開發(fā)模式，那你可以想到我們更多的是這種，我們現(xiàn)在決定要做這些feature（功能），這些功能需要這樣這樣，那就是一條線做下來，最后把它發(fā)布就可以了。

    就像瀑布模型一樣的？

    對。如果你要是想象做的功能可能需要在做的過程中調(diào)整的話，你中間的每一個開發(fā)階段，就要設(shè)計一個跟用戶反饋的過程，然后真正把那反饋拿回來，然后在下面一個過程中做調(diào)整。同時你還不能把你的那個發(fā)布日期改動的太多，所以你就可以看到這個難度實際上是增加了很多。

    在每一個改變的環(huán)節(jié)上，根據(jù)剛才我們的交流，他應(yīng)該是客戶來進行推動的。那還有一個問題是，在什么時候你們認為這是一個改變的時機，認為這個開發(fā)模式應(yīng)該改變了，這個產(chǎn)品設(shè)計的模式應(yīng)該改變了，你們做決定的時候，有沒有某一個觀點來刺激著你們?nèi)プ鲞@種改變呢？

    沒有，因為微軟很多事情不是Top-Down，不是從上面這么Drive（推動）下來的。第一，從管理層來說，我們比較注重抓的是用戶的滿意度，看他的滿意度如何，就能體現(xiàn)我們跟他一開始交流的夠不夠。另一方面，比方說我們這個產(chǎn)品真正是有多少用戶反饋，而且是把這些反饋做到了產(chǎn)品里面去，這也是我們可以衡量的、量化的。而且很多時候微軟有一個團隊開始做一個比較好的模式，那其他團隊會說，這個模式不錯，他也開始借鑒。所以我們這個轉(zhuǎn)型也是慢慢轉(zhuǎn)型，不是說一下子，整個全部團隊開始轉(zhuǎn)型，不是這么一個過程。

    可能是某一個團隊他先采用了某一種方法，然后其他團隊開始慢慢的效仿，應(yīng)該從底下往上推？然后從小到大這么一種方式？

    說的非常對，因為我們不是Top-Down。從上面管理來說，你要抓的是最后的那個結(jié)果，你想看到的結(jié)果是什么，那么你鼓勵下面團隊去實驗不同的方法能夠達到這個結(jié)果，有的試驗可能比較成功，有的試驗可能不是很成功，那么你再把成功的這種方法，然后再在其他團隊里面推廣，一般多半都是使用這種模式比較多。

    微軟的高層他不會認為就是，OK了，所有的開發(fā)團隊應(yīng)該采用這么一種統(tǒng)一的開發(fā)方法來去做，他沒有這么一種強制的要求嗎？

    絕對沒有，因為微軟的產(chǎn)品線非常的長，有各種各樣的產(chǎn)品。開發(fā)方式實際上就是我們說的Process（流程），很多時候根據(jù)你這個產(chǎn)品不一樣，各方面會不一樣的。那我對Process理解是這樣，就說Process是應(yīng)該幫助你的開發(fā)更有效、更快，很多時候我們覺得Process非常煩瑣，時間上會讓你慢下來，實際上這個不是它的（目的），它就是沒有達到要求。用另外一個比喻，其實像我們來的路上都是有很多紅綠燈，有的地方是有那種轉(zhuǎn)盤。像美國還有一種就是叫Four-Way Stop（四向停車），就是你到那邊停下來看看左邊、右邊有沒有車，沒有車就可以通過。那他實際上都是不同的管理交通方式，管理這個車流量的一種方法，根據(jù)不同的地點，你要選擇最適合地點的一種方法，有的地方如果車流量不是很大，用這個Four-Way Stop就可以了，有的地方可能有六、七個不同的出口，那用轉(zhuǎn)盤是最合理的。有的地方，在美國比方說有的地方你停了電，本來有紅綠燈的地方，你停了電就變成了Four-Way Stop，那時這個地方一定是堵車堵得不得了，因為紅綠燈可以幫助流量的增加。

    開發(fā)的管理方法也是非常類似的，根據(jù)不同的項目你要選擇對你來說比較合適的方法。如果是一個比較小的項目，你用一個heavy weight(重量級)的方法那就是不合適的。這是為什么微軟不會從上面說你一定要用什么樣的方法，他考核得是你最后那刻做出來的結(jié)果，你的結(jié)果是怎么樣，能不能在你所承諾的時間里面把東西做出來，你做出來東西用戶是不是認可，你做出來的東西后面是不是有很多質(zhì)量問題，還是說很好用。你在做下面一個版本的時候，就可以反映出你前面做的架構(gòu)好不好。如果你前面做架構(gòu)延伸性非常差，你第二個版本相對來說就會多花時間，因為要把前面重新（改造）。

    遇到很多兼容性的問題？

    對，所以這種才是比較硬性的考核標準，那下面用什么樣的方式，你自己應(yīng)該去選一個對你團隊來說最合適的方式。

    那我們再具體一點，就是你作為一個開發(fā)團隊的負責人，肯定在整個的團隊管理生涯當中，采用了很多新的技術(shù)，很多的新的開發(fā)方法，那你是有一種什么樣的觀點來評估這個技術(shù)、這個方法是不是應(yīng)該用在自己的團隊里面？

    一般還是看結(jié)果。我本人是比較愿意去試驗新的方法，我會讓一個feature crew (功能小組)去試驗這個方法。然后給他一段時間，他來給我反饋，這個不管是方法還是新的工具，他有什么優(yōu)點，他有什么缺點，因為很多時候你想是想不出來，你還一定要去試，試了之后才知道它到底是好用還是不好用，它什么地方好，什么地方不好，就跟車一樣，你得要去試開一下。然后在這之后，根據(jù)他的好處跟壞處，你還再可以跟現(xiàn)有的方法再看，再評估一下，你是把它全盤拿過來呢，還是把它改動之后再引用，或者有沒有什么辦法把它好的地方能夠結(jié)合到現(xiàn)有的方法之中，不好的地方把它拋開不用。

    你每換一個開發(fā)工具，或者是每換一個開發(fā)流程，尤其是團隊大了，相對來說實際上是一個比較難的事情。因為你對整個開發(fā)、測試，還有工程師，你都要進行一個訓練的過程。所以一般來說，我并不鼓勵有什么是最熱門的，我們都來試一下，因為這個是不太可能達到效果的。很多時候如果一個新的辦法在推行之中，大家對這個方法不熟悉，很多時候員工也會有抵觸情緒。因為我本來這個用的很好，我也知道怎么用，它里面好的、壞的我都知道了。那現(xiàn)在你如果是一個新的東西，我對它第一不知道，第二沒有感覺，然后第三現(xiàn)在我就是不知道怎么跟大家合作，那一開始可能會有生產(chǎn)效率的這種降低。所以從這種方面來說你都要考慮進去，尤其是團隊大的話，有的時候是在現(xiàn)有方法之上，說哪些是一定要改動的，哪些是不能改動的，那很重要一方面就是把這個理念，你為什么要改，你不是教你這個團隊方法，你要把你想最關(guān)鍵解決的這個問題，為什么你要做這個改動，你現(xiàn)有方法你覺得最最不好的問題是什么，你要把這個問題跟團隊講清楚。那團隊在理解了這個東西而且他也認可的情況下，比方說我們以前的開發(fā)方法是假設(shè)我們知道用戶需要什么的，我們現(xiàn)在開發(fā)方法是假設(shè)我們并不完全知道用戶需要什么的。這是一個非�；�本的理念不同，你把這個要跟團隊講清楚，那他真正能夠明白體會了這個問題之后，那再接下來他會和你一起改進他的工作方法。

    工作方法不是我來改進的，是我的團隊來改進的。因為他在日常工作（開發(fā)、測試）中發(fā)現(xiàn)了問題，發(fā)現(xiàn)什么是更好的解決方案，他要有這種主觀能動性，他要明白我想解決的問題是什么，他才能夠主動幫我來想更好的解決方法。那想出解決方法之后，我們大家再分享，一般都是這樣。

    很多可能都是從底下往上冒出來的？

    絕大多數(shù)。因為我每天不在那里做開發(fā)，我不可能知道什么是最好的解決方案，確實要每天在做的人才會在他做的過程中發(fā)現(xiàn)說，我們這個地方好像浪費了很多時間，我們有沒有什么好的方法把它給解決一下。他如果是這個涉及比較廣，他會跟我們有一個匯報的過程，因為他可能會問我要資源，或者要其他的東西，那在這個時候我會給一些比較方向性的東西：這個問題我早就知道了，但是我現(xiàn)在決定不解決，因為可能有其他的方方面面的原因，所以我不解決；或者說這個想法非常好，我給你資源，你去給我做一個試驗原型出來，然后我們再來看一下，這是非常常見的。

    那我想作為一個比較成功的技術(shù)研發(fā)團隊的管理者，給我們其他團隊的負責人，如果提三點建議有沒有什么好的建議？

    我覺得對中國團隊來說，有些是不是適合國情我就不知道了，但是我先說一下三點建議：

    第一，就是真正的要有這種自信心，要去培養(yǎng)你的接班人。而且是不僅是你要培養(yǎng)你的接班人，每一個重要的職位下面都要有一個接班人，而且這個需要和你重要職位的人一起在培養(yǎng)，因為這是打造一個長久的成功的團隊非常重要的一點。因為你沒有這種傳幫帶的話，那你這個團隊也許是現(xiàn)在可以把這個產(chǎn)品做出來，如果你們有重要人員離職之后，你還能不能是一個成功的團隊，這是一個非常重要一點。

    第二點，你怎么樣能夠調(diào)動員工最大的積極性，而且我覺得有的時候中國的員工不夠主動，你讓他做他會做得非常好，但是你不跟他說的事情，他也許就不做。這個我看得比較多，不管在美國和中國的華人員工里面都是比較常見的一個問題。作為一個管理者，你怎么樣能夠讓他能夠非常主動把問題告訴你，而且把解決方案也告訴你，這個是從微軟文化上面來說是非常重要的一件事情。

    第三個方面，從微軟來說是人腦加電腦，從我們做IT來說是人腦加電腦，那實際上最主要的還是人腦，那你是不是真的培養(yǎng)員工，真正是讓員工在你團隊里的重要性充分的發(fā)揮了出來，只有在這個時候員工才認可你的管理的方式，才能認可他是這個團隊的一員，才能想到怎么樣在這個團隊里面發(fā)揮最大的重要的作用，那這也是我覺得開發(fā)管理者應(yīng)該多思考的問題，和多做的事情。

    還有沒有其他想和我們讀者做分享的呢？

    我覺得我們中國IT員工，從IQ上面來說非常的高。而且尤其從鉆研角度來說，也是非常（努力），真的是。我們在微軟自己就覺得我們在中國招的大學生素質(zhì)，比我們在美國招的大學生素質(zhì)要高，真的是從那個IQ上面來說。

    但是，我覺得有一些可能文化上面的東西，可能會限制這些員工的發(fā)展。我看到比較多的是，有的時候員工他們碰到一個問題，我覺得可能是考試考太多了，他們看到一個問題，他們不太會去跟旁邊的人，一起跟周圍的團隊里面的人，或者跟美國團隊人一起交流，一起想最好的解決方案，能夠把大家不同的觀點整合起來。很多的時候看到他們自己在非常辛苦地在干。那苦干之后真的是做出來成果就說，你有沒有考慮到一二三四五六，那你有沒有跟這個人這個人去談過，好像這方面做得相對來說比較差一點。因為我覺得我們考試的模式就說你不能問別人，你都要自己解決。

    我們在工作中都是，你不可能一個人把方方面面都考慮全，這是不可能的。所以你一定要跟你團隊里面的人搞好關(guān)系，一定要把團隊里面幫你一起想這個問題，還有什么其他的觀點，而且能夠非常坦然的把這個觀點結(jié)合到你的解決方案中去，那我覺得這方面相對來說就是相對弱一點。而且就是這種主動性比較差，如果你沒有跟他說要做什么事情，你交代的我都做好了就完了。那這兩方面我覺得中國員工需要想一想怎么樣加強的地方。

    感謝您接受我們的采訪。

    謝謝！

    原文鏈接和視頻觀看網(wǎng)址：http://www.infoq.com/cn/interviews/team-management-panzhenglei