團隊管理之道
Michael Collins訪談錄
【Michael Collins 】是RedJack有限公司的首席科學家，該公司為馬裡蘭地區提供網絡安全方面的咨詢。在這個職位上，他開發了可供超大型網絡使用的流量監控系統和分析技術。在到RedJack公司工作之前，Collins博士在卡耐基·梅隆大學的CERT網絡情景偵測（Network Situational Awareness）團隊中工作，那時他所開發的工具和技術供美國國防部CENTAUR項目和美國國土安全部的EINSTEIN項目使用。
【Andrew Stellman & Jennifer Greene】資深軟體工程師、項目經理。他們從2005年開始為O'Reilly出版社編寫過幾本暢銷書，包括《Applied Software Project Management》、《Head First PMP》、《Head First C#》。
我們對 Michael Collins 的工作領域産生興趣是因為兩個原因。第一個原因， Michael 職業生涯的很大一部分時間都在與具有學術背景的團隊一起從事研究工作。而第二個原因，那些研究工作的目的是為政府内外部的重要客戶解決具體、實際的安全方面的問題，他的工作橫跨了學術和商業兩個領域。我們想聽聽他是怎麼看待團隊管理 這個問題的。
Andrew ：聽說你曾參加過一個檢測網絡入侵的研究項目。
Michael ：我們大多數時候想要實作的是模型常态。而我所做的大部分工作屬于異常檢測的領域，異常檢測又屬于入侵檢測領域的一部分。大多數異常檢測都是嘗試建構一個正常行為的模型，這樣如果你突然發現自己落到了正常行為區域之外，就會感到好奇，想知道為什麼會發生這種情況。
舉個信用卡的例子，你有自己正常的消費習慣。但是如果突然間你跑到加德滿都去消費了，信用卡公司就會打電話問你：“你現在在加德滿都嗎？”這就是異常檢測，是信用卡的異常檢測。在網絡流量上做的也是同樣的事情。
Andrew ：這麼說，你們的目标是檢視路由器資料，通過檢視路由器日志中的海量資料，可以檢測出那些成功或不成功的入侵？
Michael ：這是我們一直追求但又很難實作的目标。但是首選方法為正在進行的事情模組化。但在模組化的時候，對于要處理的問題又不是很清楚。這是研究工作中最重要的一個特征：你不是很清楚自己需要做些什麼。常常地，在整個過程中需要不斷地建構和重新建構工具。比如說客戶現在每隔大約 5 個小時可以執行一次查詢。他們每天執行查詢的方式就是這樣的。他們會釋出圖形，說“今天發現的就是這些”。我們在一台雙處理器的奔騰機上（ 2001 年）把查詢時間從五六個小時縮短為大約 10 分鐘。我們把初始報告拿給他們，客戶不禁問到：“你們是怎麼做到那麼多次查詢呢？”我們解釋了如何收縮資料并将查詢過程規範化。客戶的回答是：“我們需要這套東西。”
Andrew ：突然間你就得到一個軟體項目。
Michael ：是的。
Andrew ：你需要一個團隊來建構這個軟體。
Michael ：是的。我們小組最初是 4 個人。其中兩個人做編碼，但這兩個人都不會被認為是“程式員”。特别是，有一次我說自己是程式員，我的老闆 Suresh 沖着我大聲叫嚷了 5 分鐘：“你可以幹木工的活，但你不是木匠。你是一名研究人員。你寫代碼是為了回答問題，你不是開發人員。”
讓我在這裡表明幾個看法。我們實際上已經準備好對付艱苦的工作環境了，我之是以說是“艱苦”，是因為我想不到有什麼更好的表達方式。比如說我們的檔案類型頭檔案，已經有一個内置的版本系統了。我們一直在準備着向前和向後的相容。
我們在工程環境方面已經有了足夠的經驗，知道在原型和産品之間的差别有時候就是簡單地更改一下上面的标簽，是以知道建構原型是一種奢侈的東西。是以，我們沒有想到會得到那樣的反應，但是我們從一開始就将系統開發看做是一個嚴肅的問題。
Andrew ：在做研究項目并與做研究項目的人交談時，我看到的一件事情和你的老闆 Suresh 說的一樣，研究人員不是程式員。對于某個開始做博士研究或在大學環境中開始做研究項目的人，他們應當如何把你獲得的經驗用到他們自己的項目中？你做的那些工作和幼稚的研究團隊所做的有什麼不一樣的地方？
Michael ：很重要的一件事情（同時也是一件真實存在的情況，特别是對研究所學生而言）是他們有一種傾向，事先不做必要的思考就匆匆忙忙随意地弄出很多東西來。
我們所做的一件重要的事情是将工作分解為一些具體的、小的、定義清晰的“小項目”。這樣做的一個主要原因是確定小項目中的代碼健壯。如果看一下 SiLK 的架構 （ SiLK 是我們構 建的一個系統的名稱），會發現有一個有點類似核心庫的東西，管理着檔案讀取、 I/O 及很多類似的東西。到目前為止我們一共寫了大約 40 個應用程式。
研究項目的失敗率很高。是以，理想的情況是盡可能在這些小項目上的開發上多投入一些時間，然後可以測試一下，看看它們是否有用，看看它們是否解決了問題，如果不能解決，就抛棄掉。我們知道需要花費時間，但是通過這種方式，我們至少不會花費大量時間。真正有用的東西會添加到核心 SiLK 庫中。最關鍵的一點是，因為我們花了很多時間來考慮版本控制并確定核心庫是健壯的，是以我認為我們避免了很多在研發項目中常見的讓人頭疼的事 ，在那些項目中，最後得到的是一個不斷膨脹的軟體。因為在做研究的時候，你會随意添加大量的東西。你産生一個想法後就會試試那個想法，希望那個想法有用。實際上，我們會毫不留情地砍掉無法使用的東西并承認自己的失敗。我們也花了很多時間重新建構，保持核心系統小巧、健壯。
Andrew ：聽起來像是站在架構的角度來看待問題的，基本上是讓它不要超出範圍，承認有些東西是無法使用的。然後在無法使用的時候把它扔掉，把它從解決方案中去掉，這樣，你就不會得到很多越來越難維護的低劣代碼了。
Michael ：是的。研究與功能蔓延的差别真是非常非常細微。
随着時間的推移，我們還要做的一件事情是：比如說工具 X 做的是某件事，但是後來工具 Y 做了 X 做的事情，而且做得更好。那我們就試圖要取代并廢棄工具 X 。但是發現系統還在使用中，客戶那裡的一些人還要繼續使用工具 X 。但是對我們來說，這不再是高優先級的開發任務了。因為人們仍舊在使用那個系統，這種情況附帶的一些重要的東西是，有很多與之相關的文檔：有教育訓練、手冊、會議。而且他們在某種程度上會變成教育訓練課程、教育訓練手冊，定義了如何使用系統。當我們取代那個工具後，我們會把它從教育訓練的主要部分中移除掉，放到後備部分中。
Andrew ：這麼說，有工具、架構，還有一個你們在建構軟體時試圖優化的領域。你們改變了工作方式，為的是讓軟體有更好的可維護性。你們一起工作的方式是什麼？我指的是人員方面。你覺得你們一定要做一些和很多研究項目不同的事情嗎？這是你們常常考慮的問題嗎？一個随着時間的推移而演進的環境？
Michael ：嗯，這是一個有趣的問題，因為我們遇到一些有趣的、技能有隔閡的問題。我們有幾個做研究的人，主要是統計學或進階軟體工程背景，對編碼一無所知。後來我們又招聘了一些主要是擔任程式員的人。但是理想的是找一些處于二者之間的人：如果你既能做統計分析，又能編寫 C 代碼來做數值分析，那就是我們要找的人了。部分原因在我們的工作中，研究人員比編碼人員更容易得到證明。是以，我們最終的目标是讓每個人都成為一種半自治的編碼人員 / 研究人員，還有幾個人基本上承擔架構的守衛責任。長期來看這種做法是不可行的。我想時間長了就不可避免會産生技能上的隔閡，因為人們的特長、興趣和技能是不一樣的。
我們遇到的一個問題是，有一位進階研究員，很明顯就不是程式員。是以，在遇到問題而周圍又沒有人為他寫代碼的時候，他就隻能坐在那裡玩弄手指了，這個長期存在的問題是我們必須解決的。最後，我們找到了一位應用開發人員，他願意和那樣的人一起工作，向他們提供他們所需要的代碼。
Andrew ：這樣你就需要解決一個問題：團隊中的部分成員是純粹的研究人員、科學家、數學家、統計分析學家，他們不是程式設計人員。在軟體公司，常常可以看到的情況是有一個團隊與業務客戶合作。但是在這種情況中，那些非程式設計人員是團隊中不可或缺的部分。
Michael ：是的。在提取需求時我們遇到不同的問題。研究人員充當了發現新想法的引擎。這也是我們為什麼要找一些既能做研究、又能做開發的人的原因。他們是提出問題的人，他們會建構工具來解決問題，在多個場合中，工具都要求是可以使用的。然後我們會找幾個人試着分析一下如何利用已經開發好的東西并放到整個系統中。這樣，你得到那些能做研究、又做開發的人建構的原型，有幾個人事後思考如何把原型放到架構中。一個人會考慮如何把東西放到庫中，而我會考慮總體方向：這裡是我們目前所做出的東西的差距，那裡也許是我們可以彌補差距的地方。我們已經有些這些工具，如果把這些工具的功能擴充到一下，做這些額外的工作怎麼樣，現在我們對問題有了明确的觀點。
這樣做的好處是，随着我們做的事情越來越多，那些純研究人員雖然不會寫 C 程式，但是他們可以寫一些腳本或類似的東西，把工具綁在一起。接着我們得到一個解決方案—一個很慢的解決方案—我們可以用些比現在好的東西。這樣，我們就可以把一些開發精力用到開發工具的優化版本上。
Andrew ：也就是說這種方法的核心是，既是一個建構軟體的項目，又是一個研究項目，一些本來不是編碼人員的團隊成員也可以采取某種方式對代碼作出貢獻，這種貢獻有可能把各個點連起來，幫助項目進行到下一個有趣的研究問題上。
Michael ：是的。我們的想法是達到一個中間地帶。首先，你永遠也不要指望着一個純研究人員對代碼庫作出貢獻。但是如果我們有一些工具，研究人員就可以寫一個 shell 腳本來使用這些工具，這對于他來說沒有負擔，對我們來說不會造成破壞。是一些類似于這樣的東西，他可以做他的工作，對問題提出一個初始的解答，我們可以使用那個資訊，說：“現在可以建構 X 系統了。”
再次說明一下，我們在采取這個想法時，我們并不知道我們這樣做是否有價值。
Andrew ：你有多少次發現自己走到了錯誤的道路上，需要從軟體中删除代碼？因為在删減功能特性或改變代碼時，常常會在解決問題的時候引入同樣多的新問題。
Michael ： SiLK 有兩層，是以可以避免那種情況。有一個架構—檔案系統、檔案存儲和類似的東西，然後就是圍繞着這些東西的工具。從 SiLK 的角度來看，研究有兩個方面，包括了實作，或是将一組工具融合在一起來解決問題。有一個規則是，研究要圍繞着工具展開。如果我們提出了新的想法，我們就把它做成了一個工具，對于中央架構沒有損害，也沒有影響。
Andrew ：從架構的角度看，是高度子產品化的，你可以用 shell 腳本把不同的程式結合在一起，這部分要盡可能子產品化。而從團隊的角度看，你總是要努力確定人們在技術上盡可能靈活。
Michael ：是的。也就是說，我們最後有人變成了架構的守護者，那是個技術工作。
Andrew ：你是否遇到過團隊成員之間發生沖突的時候？
Michael ：研究小組中是由固執己見、高度自治的人組成的，依靠的是他們自己的基金。争論已經成為常态 。
争論基本上有兩類。第一類是研究上的争論：我應當試試這個想法，我應當試試那個想法，還有一個想法我也得試試。作為一個經驗法則，你要試試這個想法，如果證明是可行的，你就接着做下去。如果不可行，就不要做下去。但是，我們也會生産傳遞給客戶的東西。我們用工具做出所有的原型，如果工具證明是有用的，我們就制作一個子產品和一個教育訓練課程，然後教給人們如何使用工具。我要做的一件事情是從使用工具的人那裡擷取需求，因為他們的想法一般會比我們的想法好。我們使用工具做研究，他們利用工具來找人！
那是我們的一種争執。還有一種争執是關于代碼基完整性及類似的東西。我和 Suresh 之間有過一次場面壯觀、盡人皆知的争執，這場争執對他來說更像是一件小事。他剛參加了兩個星期的陪審團，剛剛履行完他的職責，然後就讓我們傳遞一些軟體了，太糟糕了。如果不把軟體測試好，我是不會傳遞軟體的。發生這件事情的原因是因為在那時，我們還沒有達成共識，找一個人來做代碼基礎庫的守衛者。我特别提倡的一件事情是做系統可靠性的權威。我弄過一份所有失效情況的錯誤樹，為系統管理者寫了一份文檔，描述當系統有某種方式失敗時，應當如何利用這份文檔，如何恢複。這樣，我就不會讓任何東西漏過去了。那場争論持續了 4 個小時，我一直堅持自己的立場。這對我來說是件大事，因為在此之前我一直都是 Suresh 的下屬。在這次争論後中我取得項目足夠的控制權，我不能讓自己的名聲受損，因為坦率地說，他剛才參加了陪審團，做事情感覺有點敵對。
實際上，關鍵是，你是搞學術的，聲譽對你來說非常重要。在寫論文的時候，名字要寫在論文上。那時關鍵之一：當我們做出什麼東西的時候，我們有一種文化，就是一般都要全力以赴地投入到這個想法上，那是我們的名聲所在。組内的每個人接受的都是這種觀念。你代表的是我們，你的工作代表的是我們，如果出了什麼錯誤，你必須處理它，修正它，在釋出的時候要小心。
最終我們到了這樣一種情況，為了讓釋出更加順利，我們建立了陪審團體系。我們有一些把事情弄糟的人，我在内部采取的辦法是利用人的自尊。有一次系統中出了一點小故障，導緻兩個字段的位置颠倒了，最後我私下裡找到開發人員說：“看看，你讓我在客戶面前像個傻瓜一樣。我承擔了責任，但是以後不要再做這種事情了。”此後，他表現得極為認真、勤勉，確定類似的事情不再發生。
我的背景是理論方面的，受到工程設計很多想法的影響。我們都接受了一種思想的訓練，認為真理不應當是獨占的。是以，我們期望着發生争論。我們在文化上也強調，争論不是針對個人的。我認為最卓有成效的環境是，人們都互相尊重、但是對人又不偏不倚，我這麼說是因為這樣他們才會提出毫無偏見的觀點，不會把别人當成傻瓜。他們不會總想着如何才能不傷害你的感情，也不會想着怎麼樣去傷害你的感情。作為一個小組，必須鼓勵互相之間的争執，到了最後能夠客觀地達成一緻意見。
關于争論，我們的原則之一是到了最後必須達成某種一緻意見。這樣我們可以全力地互相争論。大多數時候我們的争論在本質上是技術、實驗或類似的東西，是以到了最後必須試驗一下，看看誰是對的。和我們打交道的大多數人都有博士學位。我們這個過程的要點就是：如果不知道一件事情對不對，就必須通過試驗來驗證。
本文 節選自《團隊之美》
一個優秀的軟體開發團隊面臨一個棘手的問題，在這樣的團隊中工作是一種什麼情形呢？如何才能打造一個富有戰鬥力的團隊？一組不能融洽相處的人也能夠開發出好的軟體嗎？當項目關系重大、進度又很緊張的時候，團隊上司如何讓每個人都能符合既定的要求和日程安排？
本書帶你到幕後看一看軟體工程曆史上最引人關注的團隊。通過最傑出的程式員、架構師、項目經理和思想領袖的一系列引人入勝的故事和訪談，你将從資深團隊上司的成功與失敗中學到經驗。