書摘《團隊之美》- Part 1

圖片來源：Anobii

第一篇 人員

團隊中最有影響力的人並不一定是最優秀的程式設計師。事實上，他們也不是經理或領導者。他們是真誠的人：他們在團隊中是為了完成工作，在完成工作時能夠保持自我。他們能夠聆聽周遭人們的意見，知道是什麼在激勵著人們、人們的動力何在。這並不是因為他們從書上或研討會中了解到如何才能成為激勵人的領導者。他們之所以那樣做是因為他們關心周圍的人。他們花費精神讓每個人都保持相同的節奏 — 不需要很好，甚至不需要幫助，只要以一種相互和睦的方式工作就可以了。不論是什麼原因，當團隊不能一起融洽地工作時，他們都能只找出問題的癥結所在，並做一些事情來解決這個問題。 _{p. 15}

第二章 醜陋團隊的致勝之道

我們大多數人受困於一種變形的、做作的、過於簡化的美學認知，總覺得漂亮的就一定好，而醜陋的就必然糟；我們甚至都不願去探究其他的可能。_{p. 18}

唯一適合用於形容團隊之美的詞彙，是日語的”wabi-sabi” (侘寂)，是一種”殘缺之美”。簡而言之wahi-sabi是指從已經用過的事物中感受到一種特殊的美。你特別喜歡的那雙舊鞋，它已殘破不堪，曾經陪著你在沙灘上散布。這雙鞋有種美的感受是其他新鞋無法取代。即使它又髒又破，任何人想買新鞋絕對不會對這雙鞋產生美的聯想，但在你眼中它自有一種”殘缺之美” _{p. 20}

第三章 建構視訊遊戲

我們一直都是這樣工作的 — 真的，我們不會在一開始就弄一大堆設計文件，說：｢這些就是我們準備要做的。｣在開始的時候想法很模糊。｢我們要做一個有2D物理引擎的動作遊戲，再加上一些使用者自創內容。｣行動激發了創意，於是經常會聽到像這樣的話：｢好極了。快來看看這個，我想到一個好點子。｣我們可以互相腦力激盪。這是一個亂中有序的環境，這種方式只有在人少的時候適用。隨著團隊人數的增加，我們處理這種情況的方式是創造幾個｢分子｣，也就是把人們分成幾個小組，在不同的區域工作。這樣人們依舊可以採用那種亂中有序的方式。 _{p. 31}

你做出一些東西來放在螢幕上，大家可以試玩，然後對於進一步的發展方向每個人都會提出自己的想法，如果你不能坐下來，讓大家達成一致意見，人們就可能偏離原來的方向，開始依照自己的想法工作，而使彼此有了一些衝突，突然間這個團隊就不再是一個整體了。

我們努力做到的是取得一個合理的平衡點 — 我和Dave名義上是專案的首席設計師，但實際上大家都參與了遊戲設計。自然而然地，我的工作最後變成了廣納眾議，接納並整理有意義的方案，截短取長讓它們的條理更清晰，但有時候我也不得不說：｢不行，這些不能做，那樣對我們想要實現的目的沒有意義。｣既要保持原有的願景，又要考慮人們提出的、具有進化的設計意見。｣ _{p. 31}

有時候幾位主管互不相讓，彼此恨之入骨，這種態度看起來很糟糕，但我覺得不錯。這表示我們真正關心我們正在做的東西。大家的士氣都很高昂。我們最後總是能得到最佳的解決方案。_{p. 32}

不停地試玩。在製作遊戲過程中，最重要的事情就是要不停地試玩這款遊戲。很多人都忘記了這一點。你可以坐下來，一邊試玩，一邊思考類似這樣的問題：我喜歡這款遊戲嗎？我玩得起勁嗎？它讓人感覺很好還是越來越煩躁？它無聊嗎？太棒了，這正是我想玩的遊戲。在開始的時候，你自己必須成為遊戲的玩家。你必須做一些符合自己標準的東西或是連你自己都願意玩的遊戲。 (中間省略部分) 另外一種重要的方法是找一些對這個遊戲毫無所知的人來進行測試。因為你在製作遊戲時可能會過於專注某些細節，一直牽掛某個特定的地方。但當你把遊戲拿給從未接觸過它的人玩時，你會很痛苦的發覺原來妳根本是杞人憂天，那些事他根本一點也不在乎。突然間你會恍然大悟你會想到一些其他很明顯的、應該注意的地方。我覺得製作遊戲時需要不斷地試玩，同時也需要接納其他人的意見。關鍵是測試、測試、再測試。_{p. 33}

以我的經驗，當團隊變大之後，例如超過100人，就會不可避免地產生冗員，人們來上班只是為了一份工資，而不是為了做一些讓他們感到自豪的事。在我們的團隊中沒有這種情況。這裡每個人都十分敬業，為自己的工作而感到自豪。 _{p. 34}

我能說的就是這個歷程很艱辛，但是得到的回饋也很大。在這個過程中我領悟到了很多做人的道理。對於開發這樣的遊戲，我不響低估工作的困難度，但它是完全可以做到的。不過如果你不去嘗試，那麼永遠也不會成功。如果真的想要做，那就開始行動，動手做一做，看看會發生什麼事情。需要行動起來，即使遇到困難也不能放棄。_{p. 37}

後註：可能因為是自己從小就想加入的產業(話說現在不是嗎？笑…)，加上這一章的內容是以訪談的方式，訪談《小小大星球》遊戲公司Media Molecule創辦人Mark Healey，所以讀起來特別有感受。

第四章 打造完美團隊

事實上我們對每天收到的那些鼓舞士氣的電子郵件嗤之以鼻，那些只不過是為了想提高我們的生產率，避免我們的抗爭，所說的一些場面話而已。 _{p. 49}

第五章 激勵開發人員的因素

因此，瞭解你要加入一個什麼樣的團隊，或者現在身處於什麼樣的團隊，這不但要有自知之明，還得觀察你周邊的世界。 (中間省略) 我要說的是，任何人群中都有他們的人情世故。要了解它很困難，因為你得對周邊的人、事、物要有敏銳的感覺。渾然不覺會讓你操受挫折。 _{p. 54}

首先，你身為領導者或經理，一定要明瞭團隊要共同在一起工作。人與人的相處問題是你第一個潛在的障礙，任何一個讓團員無法共事的因素都會讓你的專案一敗塗地。 p. 60

事實上我們主要是想了解應徵者是如何跟他人互動。我會告訴他我這個人選人很嚴格，我們現在有個空缺的職位，我對於想得到這個職位的人特別挑剔，因為我熱愛我的團隊，我喜歡我的工作，我不想隨便找個人加入團隊。當然，還有其他實際的問題要考量。第一，想要開除某個人真的很痛苦。 _{p. 61}

第六章 激勵隊員

第一個願景是我們將圍成公司最優秀的工程團隊：其他人會把我們當作是先鋒，領導流行的人，認為我們都在做一些偉大而創新的事。每當有艱難任務的時候，總是會想到我們。 _{p. 68}

我花了一年的時間才讓他們瞭解，我不會因為他們勇於冒險或為了學習新事物而改變計畫就責怪他們。學習新事物的規則就是要勇敢，要勇於嘗試。我們都是聰明人。我們知道我們學習了新事情，並改變了我們的思維。只有笨蛋才會責罵人們為什麼不知道那些沒學過的東西。但是工程師總是受到處罰，因為每個人都要向他們提出進度要求。我不來這一套。人們開始了解我的作法。 _{p. 71}

於是有一天我和那位優秀的工程師Jason坐下來聊天，｢Jason告訴我，你是怎麼思考工作的，你整天玩遊戲，但你卻是我工作生涯中見過的效率最好的工程師。在玩耍和完成這種高水準的表現有什麼關係嗎？」他說：｢我只是需要釐清一下思緒。在遇到問題時，如果能玩一玩再回來工作，就能解決問題。｣於是我說，｢Jason，我們來做個約定，我不知道別人會怎麼說，但是如果你覺得需要去玩一下，你就去玩，這是你獲得那些神奇表現的方式，你愛玩多久就玩多久。｣而他從來也沒讓我失望。這就是如何得到創造力的部分答案。作為一個領導者，你必須找出能激勵每個人工作熱情的方式，然後把他們帶入那種狀態之中。 _{p. 73}

事實上關於創造熱情，我認為有10點要素。其中最重要的一個就是要歌頌錯誤。如果你做一件零風險的事，那麼你的報酬率是零。因為如果沒有風險，那你為什麼會得到報償呢？所以沒有風險的事是不可能獲得成功的。但是什麼是風險呢？風險就是壞事會發生的可能性。好，如果沒有風險事情不能取得成功，而風險意外著會發生不好的事情，那麼如果你把風險降為零，那還有什麼東西也會跟著降為零呢？當然是成功的機率也會跟著降為零。(中間省略)在問題分析出來後，接著就是要找那個犯錯的人。其他人都張大眼睛盯著看，犯了錯要被｢斬首示眾｣。每個人都得到一個經驗：｢不能犯錯。｣這無疑是雪上加霜，給人們增加了無形的壓力，這種壓力就是不能犯錯，這樣的環境是沒有人敢冒險的。_{p. 79}

在你創造的環境中，人們會勇敢的嘗試一些有風險的事情。你必須鼓勵人們這麼做。如果人們冒了風險，而一些瞭解情況的人可以看到這個決定是沒有經過深思熟慮的，那麼當然他們可以立刻制止，別人也不會認為這樣做不合理。但如果們做了一個合理的決定，結果卻很糟糕，這也只是說明了他們冒了一次險，剛好碰到了出錯的機率。你猜會怎麼樣？有時候結果就是這樣。如果你不會大發脾氣，反而欣然接受這個事實，那麼人們就會比較放心地去利用機會。如果他們抓住機會，他們就會創新，偉大的事情就開始發生了。這也就是為什麼有些公司在創立初期都會抓住難得的機會。他們取得了成功，在接下來的日子裡卻又讓那些成果化為烏有，因為他們害怕失去已經擁有的東西。這種患得患失的行為，終究會導致失敗。 _{p. 80}

後註：聽起來好像：對啊！就是這樣，但實際上要真的能激勵隊員是件很不容易的事情！

第七章 將音樂帶向21世紀

這似乎成了MP3.com工程師的一個共同遵守的路線：可以說他們都是富有才華的專業人員，為了完成工作不辭辛苦，隨時準備捲起袖子全力以赴，必提出創新的解決方案。我已經沒辦法告訴你有多少人第一天來到MP3.com就因為周圍環境的快節奏而不知所措。但是接下來發生的事情可就無獨有偶，令人驚奇：他們自己找事情做。在那裡不是：”我要做什麼？”而是”我能做什麼？”就像是你生命中的有機體一班自然的呼吸。_{p. 85}

我們正在改變網站的音樂對客戶提供服務的方式。是由我們自己設計，而且是公司同意的。事情就是這麼酷。 (中間省略) 這就是MP3.com的工作方式：充分的授權你和很酷的人去做不同凡響的事情，分析如何解決問題，然後直接去做它，並學習其中的來龍去脈。 _{p. 90}

接下來大約兩個月的時間，我們慢慢的錄製完成了公司從商店或員工手上買來的CD。看起來是個巨大的工程，而且也是一個團隊建設的流程。看看公司裡的每個人，銷售副總裁旁邊的辦公室，身材矮小的女按摩師Linda，還有Paradise，我們的首席音樂學家之一、嘻哈音樂之父。雖然對於整個行動的合法性還有質疑。但是大家開始活耀起來，我們逐漸找回了在員工擴充過程中失去的凝聚力，六個月前我們有六、七十人成長到現在已經將近二百人。_{p. 93}

大約在此之前的一個星期，Michael拿到了第一個版本進行測試，他大發雷霆：這是誰負責的？一轉眼間，工程副總裁，網頁設計主管，及參與決策過程的每一個人都擁入了Michael的辦公室。你可能已經知道問題出在哪裡：JavaScript[1]！這是MP3.com”採取主動”心態的黑暗面：你可以採取主動，只要你沒做錯事或不讓Michael生氣。這真是恥辱，但這是它的運作方式：你拼命的工作，認真的思考，非常成功，表現出色，是被選中的人，只要出了錯…什麼都沒有，這是你沒有權利再做任何事。_{p. 97}

[1] 書在這前面說明時空背景：當時JavaScript在瀏覽器的相容性還不是很好，所以網頁中使用JavaScript須冒點風險。

第八章 內部開放原始碼

你在一個成功的開放原始碼專案中經常會看到人們很容易地提出缺陷報告。他們的團隊讓這個過程變得簡單，他們幫助有困難的人，他們花時間幫助人們找出問題所在。一方面是因為他們把它當成自己的事，認為這樣做是對自己最有利，另一方面是因為他們本身原先是個使用者，進而成為專家級使用者，最後成為一個專業的開發人員。因此開放原始碼的團隊總是能以自己的方式工作取得成功。_{p. 111}

第二篇 目標

敏捷團隊中的程式設計師能夠把工作做好的原因之一是他們持續不斷的回顧目標。他們為了讓每個人朝著目標前進，團隊把目標記在白板上提醒大家，並且經由開會讓團員知道事情的任何變化。而且他們讓客戶餐與專案的日常工作，因為這是確保每個人的方向都和目標保持一致的最有效的方法。_{p. 120}

良好的軟體，或者如果它不是客戶需要的軟體，這些都是其次。整個團隊一起工作最大的挑戰是讓大家的目標保持一致，使他們能建構適當的軟體。即使是最好的團隊也可能在這些目標上有衝突，衝突可以破壞一個團隊的團結。但是如果你從一開始就能讓每個人的方向和目標保持一致，當目標有所變化時能讓每個人都知道 — 目標總是不停的變化，那麼專案更容易取得成功。_{p. 121}

第九章 創造團隊文化

普通的流程帶來的會是一般的產品。這不依定是壞事，因為有許多一般的傳統產品要生產，但如果你在一個地方，做一件富有創新意義的產品，而你缺少信任的文化，那麼這個創新絕對會受到傷害。 _{p. 125}

每一個組織都會有這種問題。有些團隊可以結合成一個整體，有些則不能。關鍵是要能提供一個機制，讓團隊找到自己的路。如果你的流程太過繁複沉重，那麼人們連一點自我組織的空間都沒有了，但是如果你的流程太過於鬆散，那就沒有組織結構，事情變得不可預測了。_{p. 127}

隨著人們繼續前進，你會遇到有關這個架構裡的一些有趣問題，這些細節問題很少會記錄在文件中，經常是沒有文件可供查詢，雖然程式碼最重要，但程式碼並不能代表一切，因為它不能把原理和衡量結果的內容保存下來，用程式碼難以辨別的東西也不法保存。他們是超越程式碼本身的一種模式。那樣的東西保存在部落記憶之中。 (中間省略) 你還必須處理知識產權洩漏的問題，因為把它保存在部落記憶裡的代價太昂貴 — 其實，它並不貴，但是將這些知識產權抽取出來卻非常不便宜，而且如果這些內容離你而去，成本可就特別的高。_{p. 127}

在開發流程中有很多的創新，但會丟棄大量的程式碼，也會開始累積程式碼，成為一項資本投資，並成為文化本身的一部分，這時再也不能隨便丟棄。你必須將這個決策流程的部分內容形成一種制度。_{p. 128}

擔任那個職位(這指經理)需要培養的另一項能力是向權力部門說真話，雖然這麼做是在拿自己的前途開玩笑，但是站在這個位置確實必須如此。你必須不作假，否則，你的整個過程變成了一連串的謊言。要對權力部門說真話，這點很重要的。這是能把你的團隊從令人不習慣的政治中隔離的另外一面。 _{p. 130}

一個健康的組織是有跡象可辨識的，他們面對失敗是謹慎沉默的。一個極度不知變通、拒絕失敗的組織，通常也都是那些缺少創新的組織，那些人非常害怕失敗，總是會採用一些最保守的行動，所以他們幾乎沒有任何樂趣可言。另一方面，在不會破壞公司業務為前提之下能夠比較自由的面對失敗的組織，反而會是生產力較高的團隊，他們面對失敗給予一定的自由度，這樣人們就不會編寫每一行程式碼都要擔心受怕。_{p. 131}

我看到的那些跨越不同區域、生產率超高的組織都遵循這樣的作法。分為三個部分。第一，把重點放在可執行程式碼上。 (中略) 第二，以增量、迭代的方式完成這些事情，這樣做意味著你們做事會有一定的規律，因此你們可以從中引入重構， (中略)第三項因素，敏捷的成分少一點，RUP成分多一點，要把重點放在架構上，把架構當成一種控管的手段。 _{p. 132}

這本書其實沒看完，當初 2015 寫完書摘 (8/1)，就慢慢被我遺忘在書架上了，看來是可以找時間把它看完，但... 什麼時候？我也不知道 XD