在對Patrick Copeland的采訪的第二部分，我們主要討論了管理一個全球開發(fā)團隊的挑戰(zhàn)；食物刺激對程序員的作用；好的測試工程師和超nb測試工程師之間的區(qū)別；以及為何某些公司始終無法提供靠譜的軟件。
問：管理一個跨越一打以上國家的團隊有什么挑戰(zhàn)？在這樣的團隊中管理人員、流程、產(chǎn)品有什么樣的困難？還有，你一般幾點睡覺？
答：“確保對人員的掌控”<談到這個時他臉上掛著邪惡的微笑>不是Google的解決方案。實際上，我們的團隊結構在業(yè)界是非典型的。首先，我們是扁平化架構，即使是Google新雇員，和最高管理層之間的層級也只有幾步而已。還有就是公司內(nèi)的那些半自治人員和團隊。在這個非典型體系中，讓管理者控制一切顯然不太合適。與之相反，我更愿意讓nb的人組成團隊然后讓他們自己管理自己。我的重心會放在幫助團隊提高效率上。大體上來說，我們評價Google管理者的指標就是他們讓聰明人完成任務的能力。而且我們認為，大部分人一旦擁有超過15個下屬，就會陷入混亂，投入到真正的管理上的時間就會減少。
確保我們向同一方向努力的神器是——OKRs，這個東東是董事會成員John Doerr在2000年帶入Google的。John強調(diào)由公司級目標派生部門目標的重要性；與之對應的，每個員工的OKRs應該支持團隊和整個公司范圍的目標。在2000年第一季度，我們發(fā)布了第一個公司級別的OKRs，其中包括“每秒800萬次搜索”以及“為公司尋找CEO”。自那時起，我們已經(jīng)取得了長足的進步。
問：我們注意到Google給雇員提供了大量獨特友好的工作環(huán)境。對于你們的工程師，這些手段是否依然有效呢？或者（如同我們在uTest做的那樣）你們正準備把工程師拷在桌子上，然后他們每寫一行代碼你們?nèi)右粋€小食品以示獎勵？不開玩笑了，真正的問題是，如何保證開放的環(huán)境下工程師依然可以做出出色的軟件？
答：我們有開放的文化，工程師有足夠的自由去探索他們感興趣的領域。我們有一個“20%時間段”，在這些時間中我們鼓勵工程師去探索他們主要業(yè)務之外的領域。
（好的）文化會衍生出好的產(chǎn)品嗎？我們這么認為，但是這二者之間的關系很難判定。有些人會傾向于使用那些“產(chǎn)品化度量”：代碼行數(shù)、簽入次數(shù)等等。我們（非正式的）阻止這種做法，因為類似這種度量會造成一些不可預知的問題：例如人們會使用一些“技巧”，以在系統(tǒng)中獲得“所謂的成功”。（除了帶給最終客戶的創(chuàng)新）我們衡量績效的最重要方式是每季度一次的同事評審。這種系統(tǒng)會強化你對團隊工作的認識，確保你在同事中擁有影響力，并建筑尊重。這種評判是主觀的，可能看上去很難操作，但是對于塑造個體價值功效顯著。
另外，扔食物在我們那里必然沒效果，因為在Google員工可以免費享用各種美食。
問：好測試工程師和卓越的測試工程師之間有什么區(qū)別？
答：好的測試工程師是可以訓練出來的。基礎的要求有：計算機基礎知識，對于應用領域的認識，對于客戶用例的強力理解，客戶角度的視野，對于度量的把握以及對開發(fā)流程的關注。
卓越的測試工程師則意味著傳說中的10%，他們非常罕見和稀有。不是每一個人都可以成為卓越的人。從個人經(jīng)驗角度看，卓越的開發(fā)工程師并不一定能成為卓越的測試工程師，但是卓越的測試工程師（擁有很強的設計能力）則可以成為卓越的開發(fā)者。這與一種心態(tài)和激情有關。從超過100次面試得來的經(jīng)驗看，我認為，卓越來自于：1）一種發(fā)現(xiàn)問題的特殊潛質(zhì)；2）被潛質(zhì)指引去測試和發(fā)現(xiàn)問題的激情。換句話說，他們喜歡測試并且善于測試。他們也常常感覺到測試中的挑戰(zhàn)，大于等于開發(fā)中的挑戰(zhàn)，并為之感到特爽。一個大牛測試工程師，他們有測試的基因，正確的態(tài)度，他們總是很容易的找到一份工作。他們就像金子一樣的寶貴。
問：您認為，導致我們無法在帶著（交付日期，優(yōu)先級，競爭）鐐銬下制作出高質(zhì)量的產(chǎn)品的最大原因是什么？換句話說，為什么不是每一家公司每一次都可以發(fā)布世界級的產(chǎn)品？
答：我經(jīng)歷的每個產(chǎn)品都有不同的故事。每個故事的情節(jié)那就是有一句說一句了。某些產(chǎn)品我們幾乎可以掌控全部（例如技術選擇）。而另外一些產(chǎn)品中我們只能控制一部分。有些因素則完全不受我們的掌控（例如競爭對手想咋整）。
有些公司試圖開發(fā)一些規(guī)范的流程。這些看上去冠冕堂皇的流程都說自己可以：提高效率，消滅不確定性，維護質(zhì)量，如此等等。這些重口味開發(fā)流程在造大灰機的時候灰常有用——這也確實被一些nb飛機制造商證明了。不過在程序猿們看來，這種流程可能過于繁雜，會破壞他們創(chuàng)造軟件的心情。相反的，木有流程的流程則可能導致你的開發(fā)無法被復制。你需要在大流程和沒留成之間做出平衡。
讓我們把灰機制造和軟件開發(fā)過程放在一起比一比。在飛行條件具備和飛行員有經(jīng)驗的情況下，制造灰機的核心就剩下了平衡必要條件：超重或推力不足在一些情況下就會導致災難。同樣的，對于團隊，產(chǎn)品和流程這些虛擬因素也是如此。例如，在項目后期猛招工程師是沒法提供升力的。再比如，采用一套新流程可能會給團隊帶來一時的新推力，但是也可能在中長期破壞團隊的創(chuàng)新能力。
敏捷開發(fā)的流行說明程序猿們需要更好的平衡和創(chuàng)造性。我們的軟件質(zhì)量也確實提升并且過程可控了，我們必須鼓勵創(chuàng)新。我們需要鼓勵那些給客戶帶來價值的或者是解決了困難問題的奇思妙想。話句話說，我們要保持團隊在天上自由的灰啊灰。