團隊之美

　　資深團隊領導人物陳述發人深省並引以為鑑的經歷

　　“有好的、壞的、醜陋的，當然還有美麗的團隊。在本書裡你會看到那些團隊不論情況如何惡劣都能夠不屈不撓堅持到底，那些享有盛譽的知名組織是如何建構團隊。如果想知道如何讓你的團隊團結一致上下一心，形成完美出色的團隊，請閱讀這本書。”

—Johanna Rothman，顧問、作家

　　一個優秀的軟體開發團隊面臨著一個不可能的任務，在這樣的團隊裡工作將會是一個什麼樣的情況？如何才能建立一個高效率的團隊？一群不能融洽相處的人也能建構良好的軟體嗎？當專案利害關係重大、期限又很緊迫時，團隊領導者如何讓團員們保持正常的運作，達成目標？

　　本書帶領你到幕後看看那些在軟體工程史上最引人注目的團隊。經由傑出的程式設計師，架構師，專案經理和思想先驅者等一系列引人入勝的故事和訪問，您將從資深團隊領導者的成功和失敗中學到經驗。

　　本書的撰稿人包括：

　　Tim O’Reilly Cory Doctorow Michael Collins
　　Scott Berkun Neil Siegel Karl Rehmer
　　Mark Healey Trevor Field Andrew Stellman
　　Bill DiPierre James Grenning Ned Robinson
　　Andy Lester Steve McConnell Scott Ambler
　　Keoki Andrus Barry Boehm and Johanna Rothman
　　Tom Tarka Maria H. Penedo Mark Denovich and
　　Auke Jilderda Peter Gluck Eric Renkey
　　Grady Booch Karl E. Wiegers Patricia Ensworth
　　Jennifer Greene Alex Martelli Andy Oram
　　Mike Cohn Karl Fogel Tony Visconti

　　Andrew Stellman 和 Jennifer Greene 是資深的軟體工程師和專案經理。他們自從2005年開始為O'Reilly編寫過幾本暢銷書，包括《Applied Software Project Management》，《Head First PMP》，和《Head First C#》。

第十章 讓“我”置身於錯誤之中吧！ Jennifer Greene

我的履歷在最後一行寫著：“Jennifer Greene是一位經驗豐富的專案經理、開發經理，並成功的帶領過團隊和完成專案的記錄。”這是真的，我已經成功的經營過很多團隊能夠依照客戶的需求在指定的時間和預算內，建構高品質的軟體。我敢打賭，很多人的履歷都會有同樣的紀錄。但是，當我回顧過去這15年左右所做的工作時，我知道，那些成功的專案並沒有為我工作的公司取得市場優勢。在某些情況下，有些專案甚至並沒有解決它們所要解決的問題。而我讀過的所有資料都告訴我，不只是我有這樣的問題。有很多專案做得比我更差。一些已經公佈的統計資料估計軟體專案的整體失敗率高達80％。

幾年前，Andrew和我開始四處雲遊參加各地的活動及會議，並舉辦了一個“專案為什麼會失敗”的座談會。人們可能會因為過程繁雜或難以實施而拒絕使用一些務實的方法（如程式碼審查和評估），我們的目的是幫助人們理解這些實務的活動和避免常見陷阱之間的關係。為了讓座談會不至於太嚴肅，我們使用了在編寫那兩本“深入淺出”系列書籍的過程之中學習到的一些東西，我們希望座談輕鬆點、活潑並保持開朗的情緒。我們不但達到了預期的目標而且還超出甚多，有些人似乎非常渴望談談他在專案中所犯的致命錯誤，我們觸動了他們的心弦。很多人想知道：“我的專案為什麼會失敗呢？”很多時候，談話變成了人們發洩感情的一個機會：他們會談論一些難忘的經歷，管理階層是如何做出這個荒唐的決定，一位態度惡劣的程式設計師太自私而不願意去修改程式碼中的錯誤，或者那個產品從一開始就是個糟糕的主意。在聽眾面前，我們就一直嘗試著將談題轉向對他們有幫助的特定實踐上，（“如果有品質的問題，就需要提前做程式碼審
查”，或“你總是錯過你的截止期限嗎？可以使用類似Wideband Delphi這種大家有共識的評估流程”）。這些實務的做法在工作上給Andrew和我帶來非常大的幫助。但這些方法不能解決人際關係問題，也無法保證你所做的專案對你的公司是否合適。這些實務的方法並不能保證成功。在沒有座談會的時候，我們討論了很多這一類的問題。

在我曾經工作過的一些公司裡定期生產的軟體包羅萬象，以致於弄不清楚他們製作軟體的原因。有時候人們花費大量的金錢大力開發軟體只是為了證明他們生產了一個產品。我見過一些專案獲得資金卻不太了解需要生產什麼樣的軟體，我還曾經被一些對自己缺乏自信的人管理過，他們強制團隊在一個不必要的緊迫期限內完成專案，而它對於整體的計劃並不重要。我曾經在晚上和週末加班工作而放棄了休假日，建構了一個幾乎沒有被使用過的產品。即使目標不斷變化，也不能保證你正在建構的產品將會被人使用。我知道在這種團隊中工作會是什麼樣的感覺。按時完成一個毫無用處的專案，算是成功嗎？在這種情況下，讓團隊團結一致，算是成功嗎？坦白地說，如果客觀的評論，這很難算是成功。你能做的事也只有向管理階層質問這個期限的必要性，替人們盡力爭取一個合理的目標，雖然這個願望有時候無法達成。

一些我合作過的最好團隊其實處境很艱難。在我完成過的最好的工作成果中，客觀地說有些並不算成功。促使你產生一些真正的創新思維的因素，有時候是工作關係密切的人，有時候則是被艱困的處境所刺激。我剛開始工作沒多久，來到紐約，我加入一個團隊，那可能是我參加過最有才華也是工作最勤奮的團隊。這段經歷一直深印於我的腦海裡。

“在Gabfest軟體公司，我們認為把一些聰明人組合起來，讓他們在一個房間裡專心的解決一個燙手的問題，這樣可能導致的神奇效果。”

我還記得公司的CTO他在說那些話時，臉上的激動表情。他對他們正在進行中的工作非常興奮，這讓我打消了疑慮。當時我去應徵QA經理，正在面試的過程當中，那是一家剛創立的小型公司，生產一種令人稱奇的產品，他們要改變人們與電腦的互動方式：他們要讓電腦聽懂人類說的話。我花了一整天的時間和公司一半的職員面談完成了傳統的面試問題。之後和CTO進行非正式的談話。他帶我到辦公室隔壁的咖啡店，開始向我推銷他的願景和公司的未來。當他說到有關於聰明人和解決艱難問題的那番話似乎不甚合理，但實際上卻令人振奮。聰明的人可以完成任何事情，對吧？

當時我覺得自己很聰明。在一家非常保守的金融公司做了兩年的內部軟體測試，之後我準備嘗試解決一些更重要的問題。所以我離開了那家公司，準備開始大展身手。

我的工作背景及知識和自然語言處理毫無關係。我剛離開的那家小公司Gridline，他們開發的是追蹤股票訊息的金融軟體。我搬到紐約市時在這間公司上班，（在此之前我在一個線上服務公司做過幾年的客戶端C++軟體測試）。在Gridline的工作非常好，但有點古板。這個地方，即使散漫的週五上班也要穿著商務休閒服。正常上班時間每個人都穿著西裝，打領帶，文化是以業績為導向，而大多數的團員在金融業已經服務很長的時間。

Gridline是個小公司。管理團隊的成員都是在公司剛成立的時候就加入了。他們對於公司的成功感到自豪，他們對公司創辦人的忠誠是我在其他地方工作時從沒見過的。公司的員工在相同的工作崗位上已有數年的歲月。我加入公司作為QA經理，測試其內部資料清理的應用程式。我在那裡做了兩年，我真的很喜歡那份工作。我在那間公司從無到有，幫他們招聘並培訓了測試團隊，並編寫建構了他們第一個版本的開發流程。這對他們的工作品質產生了良好的影響。當測試團隊建立之後，我開始承擔越來越多的責任。但是我的收入並未隨著工作難度的增加而增長。最後我突然覺得最好還是去找一份新的工作。那時正值網路公司興盛時期，任何人只要懂一點電腦絕對找得到一份好工作。