團隊之美

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

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

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

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

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

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

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

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

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

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




當我坐電梯來到Gabfest的辦公室，我很驚訝這地方和我離開的公司完全不一樣。進入大樓裡面沒有保全人員、沒有櫃台、沒有接待人員、沒有富麗堂皇的大廳。公司內沒有人穿西裝、打領帶，整個辦公室就是一個擺滿了辦公桌的大會議室。沒有隔間，大家相臨的坐在一起，互相沒有隱私。這些讓我想起了在Gridline重新安排辦公室座位時發生的鬥爭。那個公司裡，辦公家俱代表你的身份，小隔間的座位是新進人員和臨時員工，大隔間的座位是資深員工，小型辦公室裡擺著美耐板書桌是屬於經理和管理人員，大辦公室裡擺著真正的實心木製辦公桌是主管、副總裁或其他更高級職位人員的標準配備。我們的談論話題總是誰應該坐在哪裡，什麼水準的人應該使用什麼樣的辦公家具。在Gridline，這些東西對每個人都意義深遠。座位在隔間裡的人都非常認真的看待這件事，想著有一天能搬進一間辦公室，而高級主管們對於他們的木製家俱都很自豪。我知道我的位置：先在美耐板的辦公室待上五年左右，然後搬入實心木製辦公室。但在Gabfest公司的辦公室，顯然沒人關心那些無聊的事。我們在這裡是為了完成一件工作，我這兩年來，已經厭倦了人們為了辦公室、頭銜和職責而勾心鬥角，現在已經準備接受一份能全心全力投入的工作。

很多人都介紹過關於網路公司的過度奢華，我也讀過有關那個時期其他草創公司的情形，相較之下，我覺得Gridline公司在福利設施方面有些簡陋。沒有桌上足球，員工沒有按摩服務，沒有有機食品的廚師，不提供免費的午餐。公司就是一間大房間，裡面坐滿了認真工作的員工，非常努力的在解決一些不可能的任務。

他們建構了一個我至今都不太了解的產品，一群計算語言學家創造了一個語言處理引擎，根據他們對專業領域的瞭解，將使用者鍵入的詞句建構一個響應模型，他們建構的第一個產品知道有關筆記型電腦的所有資料。如果你輸入“我需要一個速度快、便宜、重量不到5磅的筆記型電腦”，它會將其轉換成一個SQL查詢，並從資料庫中找出與你的描述相匹配的筆記型電腦。並將這個程式做成套裝軟體，如果購物網站想為使用者提供個性化購物體驗，但又不想多雇用一個員工和使用者交談。他們可以購買這個套裝軟體。

這項工作團隊是由公司的一名資深員工帶領。在公司草創之前他就已經帶領著一個語言學家團隊建構出軟體的原型。他將全部的精力都用在那個原型上，隨時隨地都在想把它做得更好。但他並不認為這是個能夠商品化的產品。現在回想起來，這似乎對當時從事這項工作的所有人敲響了警鐘。但我們都沒有察覺，因為大家都非常喜歡自己的工作。我的意思是我們真的很喜歡正在做的那個工作，相形之下產品的方向和整體目標就顯得不是那麼重要了。

我很快的喜歡上這些人。他們都很聰明、風趣，大多數擁有良好的教育背景，而且全心投入他們自己的工作。這個軟體的大部分功能已經可以使用了。如果把談話的主題限定在筆記型電腦上，它是一個非常有用的銷售工具。該小組從一開始就很重視軟體的品質，在產品的開發流程中，他們為產品建立了一個自動化測試工具以便能提早發現產品的缺陷。讓人感覺到他們是如此專心的在解決發生的問題，每天都盡全力的在擴充這個軟體的功能。

現在回想起來，我們建構的軟體有很多的問題──不一定是技術性的問題。例如，我們了解了很多有關在網路上銷售筆記型電腦的情況，但是很顯然的，人們並不會按照Gridline所設想的方式購物。如果你上網購買筆記型電腦，大多數的網路銷售公司都有一套配置工具，可以讓人們從他們提供的清單中選擇所需的硬體。仔細想一想，那個使用者介面可能比我們正在建構的產品更直接。讓我們看看實際的情況：自然語言處理引擎（NLP）會把可以選擇的硬體種類限制在六∼七種之內，所以大部分的人都不想和這個引擎交談。不過它仍然是一個非常有趣的語言學問題，而那個專案在當時也有得到一些資金的支持。

我在那裡的工作非常努力，每當作品有一個業務開發交易或展覽會時，我會花大量的時間來確保一切功能正常。我記得當時在晚上和週末加班幾乎是家常便飯。每個人都這樣。每個人都用一種我從沒見過的方式在工作著。我也沒閒著，我開始負責收集產品工作方式的資料，追蹤一些惱人的缺陷並為QA團隊的其他同仁安排工作，為的是要達成那些過於自信的截止期限。由於測試本身是從一開始就實行自動化了，我需要找出最好的方法來評估所有的測試結果，並不斷的追蹤它的測試結果。我開始尋找開發流程中常見的問題，並和團隊一起予以糾正。這項工作很有意思，我開始把管理團隊的一些不同做法所造成的差異整理出一個頭緒，使我對管理開發團隊的能力向前邁開大步。

我把我認為可以對產品有幫助的建議直接反應給CTO、開發主管或開發人員。我能夠提出建議修改，而且能看到這些修正所產生的影響。當然在實施每一件修正之前，我們都會爭辯、討論，但是大家心態很開放，對於大多數值得考慮的想法都願意試一試。我信任和我一起工作的人，他們也信任我，總而言之，這種方式在這裡是可行的。在一些政治氣氛濃厚的地方工作後，現在可以跟決策者溝通，對我而言是一個可喜的變化。

雖然工作本身有回報，但也存在著一些嚴重的問題。除了在做自然語言專案之外，還有另外一組人工智慧的專案也在同時進行，但是沒有得到語言學團隊的認同。另外還有一個資料探勘小組的團隊在加快追蹤軟體和現場使用者談話的使用情況。對於我們是否應當同時考慮所有的目標，大家時常出現激烈的爭辯。




隨著公司的發展，這三組人馬幾乎發展成為敵對派系。每個人都強烈認為自己的方向才是真正的目標，並真誠地相信當Gabfest的產品推向市場時，他們將是決定成功和失敗的關鍵。一部分人是計算語言學家。他們盡力做好NLP引擎，擴充引擎的詞庫和知識領域。實際上這是種無止境的工作。表達一種意思的方式是無法限制的，甚至於連一句這麼簡單的話“我想要有一個快速的筆記本電腦。”也是一樣。他們知道引擎永遠無法像人一樣聰明，但是他們也明白這些引擎如果連“我需要速度快的筆記型電腦”和“我不需要速度慢的筆記型電腦”這兩句話都分不清，那是無法得到人們的信任。這個問題似乎很容易（對於沒做過這種事情的人而言確實如此）但它實際上卻是一個曲折、艱難解決的問題。這正是計算語言學家在做的事。他們認為引擎越豐富，最後的產品就會更好。

另外一組研究人工智慧的人。他們要軟體能夠從和它對談的人身上學習新的詞彙甚至是新的行為方式和思想。他們的工作不如語言學家所做的──他們的功能是要依附在一個已經可以使用的語言處理器上才能實現。但是因為這個功能很酷，所以足以彌補它在願景方面的缺憾，每個人都喜歡這個主意。他們希望軟體會越來越聰明，不是因為人們使用這個軟體，而是因為人們在跟軟體進行交談的關係。

如果公司只有兩個方向，由語言學家和人工智慧兩個團隊帶領，後來的結果可能不同。但是公司還有第三股力量，他們也有自己的目標：資料探勘。他們需要利用軟體檢查與跟它談過話的使用者的全部對話，使用檢索出來的訊息並根據使用者的資料及當時的談話內容，對特定的使用者進行廣告推銷，大家都直覺的感受到這種方式會有很多潛在的利潤存在。但是我們都擔心──即使是資料探勘的支持者也很擔心──這樣可能會有侵犯個人隱私權問題。但是這是產品的最大賣點。我們向Gabfest的客戶推銷這種想法，告訴他們根據客戶和軟體的對談就能夠了解很多客戶的訊息。

總之這是個三方角力。語言學家基本上認為：“如果我們的東西沒做出來，其他的想法都沒搞頭。”人工智慧的團員還沒考慮好他們的目標，但每個人都覺得這是一個值得努力追求的酷主意。資料探勘的人認為自己是公司的利潤中心。但問題是我們的公司規模不大，不足以把這三件事情同時辦好。雖然說我們都夠聰明，但是要實現這些目標將非常、非常的艱難。我們都覺得作為一家公司，我們同時把重點放在太多的問題上面。但是那卻是讓我們的產品取得成功願景的一部分。但我們沒有改變策略，領導階層鼓勵三個不同的團隊按照自己的方向前進。

結果有一堆幾乎是“機密”的專案同時在進行。人工智慧的團員建構了許多原型神經網路，但並未在主產品內增加任何功能。即使產品的銷售不佳，語言學家仍然不斷的在產品上擴增語言的功能。對我來說，這是一個網路公司興盛的真實故事：它沒有桌上足球、靈活的工作時間、古怪的頭銜、開放辦公室計劃、免費食物，甚至也沒有創業投資風險家的起起落落。它有的是人們可以更自由大膽的承擔更大的風險，冒險去做一些他們想不到的有趣工作。那個時候我們真正被鼓勵去創新。對於我們來說，當時做的是一些真正的尖端的語言學和人工智慧研究工作，並嘗試著去建構出一個實際的商業模型。

每個人都在做自己的事情。但隨著事情不斷的進展，我們很難能推出單一的產品。我想我們大多數人知道這一點，但是每個人都能學到東西，它是我們曾經做過最有趣的工作，所以我們仍然繼續做下去。我們都為自己選擇了振奮人心的工作，而且都得到了回報──不只是是薪資，在事業上也有得到某種程度上的回報。我在Gabfest公司認識的每一個人情況都比以前好。但是每個人都強烈地堅持自己的意見，都非常看重自己的工作價值。對於公司的發展方向，每個人試圖盡可能增加自己的影響力，甚而出現許多激烈的、漫長的鬥爭，大家坐在會議室的互相叫罵為的是公司的方向。

在一個星期二的下午，CTO告訴我們，公司的資金用完了，我們公司將在兩個星期後解散。

我記得當天晚上，在這個決定宣佈之後的幾個小時。我們在一起互相討論我們的工作。坐在一起喝啤酒，長時間以來我們還是第一次有那麼樣輕鬆的一個夜晚。我們之間的派系鬥爭已經不算什麼。公司已經沒有了目標，我們只是喝著酒在一起討論問題，回憶一些大家共同經歷的痛苦難忘問題。

接下來發生了奇怪的事情。再過兩個星期公司就要解散了，但是每個人都還照常來上班，彷彿什麼事也沒發生過。我們只是不停地工作，盡力設法保存更多的工作成果。甚至沒有人質疑這個做法。儘管我們知道自己兩個星期後就會失業，但仍然在那裡每天工作12個小時。每個人都專心的做著自己的工作，對於公司的處境反而不在意了。因為我們有了一個新的目標：將所有的資料都歸檔保存好，以便我們日後又能重新拾回這份工作，在某種程度上，我相信我們每一個人都認為這件事真的會發生。



到了後來，我們甚至互相幫助找工作。一直互相保持聯繫。公司關閉的時侯，我的一位朋友懷孕八個月了，她的孩子受洗的時候公司已經解散，但整個公司的人都去參加受洗儀式，大家湊了些錢買了禮物送她。在後來的日子裡，我們都一直保持著聯繫。一年多後，我們又走到一起。最初的想法注定會失敗，我們也注定會成為那個想法的一部分，大家都深情的回憶起那些經歷和友誼。我們因為公司而緊密的結合在一起。我想我會高興地拿起電話，熱情的向別人推荐每一個在那裡跟我一起工作過的人。以前我工作過的其他公司，沒有一家能夠做到這一點。

我以前從來沒有和一個如此專心於工作的團隊合作過，後來也沒有。他們對工作的態度現在仍然激勵著我。但是事實上解決大問題不只是需要智慧、魄力和資金。首先要有一個一致的、可行的目標。我們沒有將自然語言處理程序商業化，建構的軟體也沒有讓上網購物的體驗更人性化。我們並未對人機的互動方式引起革命性的突破。但我們在Gabfest的工作卻對自己產生了一些神奇的東西。

儘管業界對於曾經有失敗專案的記錄會感到不安，但是每個人的履歷上的寫的摘要都類似我在本文剛開始所引用的那些詞句。就我而言，這個失敗的經驗比起其他很多的成功經歷更值得。我能說它是成功嗎？從我個人的角度來看，我認為是成功的，我獲得了十足的成長。但是客觀地說，公司和產品並沒有成功。據我所知，我們的軟體從來沒有被使用過，我知道我們都夠聰明，有足夠的技能來建構我們需要的任何軟體──Gabfest公司的團隊是我合作過的最聰明的團隊。但是我看過一些技能比我們差很多的人卻在軟體行業賺了很多錢，因為他們選擇了一個能夠銷售、而且客戶願意購買的產品。

一般的情況下，好像沒有人會認為我們經歷的失敗是自己的錯。我並不認為這一定是件壞事。我想我也不會認為我所經歷的失敗是我的問題。

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

章節說明:為什麼要編寫《團隊之美》
序言
　　第一章　這對你有幫助嗎？- Tim O’Reilly 訪問記
第一篇　人員
　　第二章　醜陋團隊的致勝之道 - Scott Berkun
　　第三章　建構視訊遊戲 - Mark Healey訪問記
　　第四章　打造完美團隊 - Bill DiPierre
　　第五章　激勵開發人員的因素 - Andy Lester訪問記
　　第六章　激勵隊員 - Keoki Andrus訪問記
　　第七章　將音樂帶向21世紀 - Tom Tarka
　　第八章　內部開放原始碼 - Auke Jilderda訪問記
第二篇　目標
　　第九章　創造團隊文化 - Grady Booch訪問記
　　第十章　讓“我”置身於錯誤之中吧！- Jennifer Greene
　　第十一章　制定計劃 - Mik`e Cohn訪問記
　　第十二章　公眾利益鬥士攻佔邪惡之城 - Cory Doctorow
　　第十三章　保衛自由世界 - Neil Siegel訪問記
　　第十四章　拯救生命 - Trevor Field訪問記
第三篇　實踐
　　第十五章　建構協同作業型和學習型的團隊 - James Grenning
　　第十六章　更好的實踐 - Steve McConnell訪問記
　　第十七章　TRW軟體生產率專案回憶錄 - Barry Boehm & Maria H. Penedo
　　第十八章　建造太空船 - Peter Glück訪問記
　　第十九章　成功的需求 - Karl E. Wiegers
　　第二十章　在Google的開發工作 - Alex Martelli訪問記
　　第二十一章　團隊與工具 - Karl Fogel
　　第二十二章　研究團隊 - Michael Collins訪問記
　　第二十三章　HADS團隊 - Karl Rehmer
第四篇　障礙
　　第二十四章　糟糕的上司 - Andrew Stellman
　　第二十五章　歡迎使用軟體開發流程 - Ned Robinson
　　第二十六章　跨越障礙 - Scott Ambler訪問記
　　第二十七章　速度與品質 - Johanna Rothman
　　第二十八章　層層障礙，不是嗎？- Mark Denovich & Eric Renkey
　　第二十九章　辦公室內外 - Patricia Ensworth
　　第三十章　匯集團隊的心聲 - Andy Oram
第五篇　音樂
　　第三十一章　製作音樂 - Tony Visconti訪問記
作者群
索引

章節說明:為什麼要編寫《團隊之美》
序言
　　第一章　這對你有幫助嗎？- Tim O’Reilly 訪問記
第一篇　人員
　　第二章　醜陋團隊的致勝之道 - Scott Berkun
　　第三章　建構視訊遊戲 - Mark Healey訪問記
　　第四章　打造完美團隊 - Bill DiPierre
　　第五章　激勵開發人員的因素 - Andy Lester訪問記
　　第六章　激勵隊員 - Keoki Andrus訪問記
　　第七章　將音樂帶向21世紀 - Tom Tarka
　　第八章　內部開放原始碼 - Auke Jilderda訪問記
第二篇　目標
　　第九章　創造團隊文化 - Grady Booch訪問記
　　第十章　...