在最高層面上，整個團隊必須目標一致，在報告進度上遵守最佳實踐。 ### 任務宗旨——不，我是認真的 每當聽到“任務宗旨”這個詞，很多人的第一反應都是大公司顛來倒去說的那些空洞無物、營銷意味濃重的公司宗旨之類的東西。下面這個例子就是一段某家不具名的大型電信公司的公司宗旨。 我們立志成為全球最受尊敬、最有價值的公司。我們的目標是通過令市場矚目的優質服務來豐富客戶的個人生活，幫助企業獲得成功，同時為股東創造價值。 說來奇怪，我不覺得有任何人尊敬這家公司！這里是另一家大型企業的公司宗旨： **提供實時的解決方案以滿足客戶需求。** 這句話到底是什么意思？它可以代表任何事情——如果我們在這家公司工作的話，我們根本就不知道到底是編寫軟件更重要，還是修漏水管或者送披薩更重要。正是這種含糊不清的東西讓公司宗旨在世人眼里顯得那么空洞。 對工程團隊來講，撰寫任務宗旨就是要準確地定義產品的方向和范圍。好的任務宗旨不是輕易寫成的，但是它或許能為你節省數年的時間來澄清哪些是團隊應該做的，哪些是不應該做的 ¹。 幾年前，當Google決定要把Google Web Toolkit（GWT）開源的時候，我們曾經擔任過團隊的指導。我們檢視了開源和閉源開發之間很多不同的地方，特別注意了在一個誰都可以來發表意見、貢獻補丁、對產品最微小的某個方面提出批評的環境里，設計、討論和編寫軟件所要面對的困難 ² 。在解釋了這些困難之后，我們告訴團隊，他們需要寫一份任務宗旨，向公眾描述哪些是產品的目標（還有哪些不是）。 出于上述各種原因，有些工程師對此頗為猶豫，但是也有一些人表示有興趣，團隊負責人似乎也覺得這是個不錯的主意。但是等到真正坐下來開始寫的時候，大家對于這份宗旨的內容、基本要素和風格又產生了巨大的爭論。在一系列討論（和會議）之后，團隊不但交出一份漂亮精練的任務宗旨，甚至還準備了一整篇“讓GWT更出色”的文檔 ³ 來逐條解釋它。他們還專門開辟一節來解釋哪些不是項目的目標。下面就是這份任務宗旨。 GWT的任務是要通過讓程序員利用現有的Java工具，為任何現代瀏覽器構建全功能的AJAX，從而徹底改善用戶的網絡體驗。 這句話包含了很多基本要素，我們認為它是任務宗旨的絕佳范例：它不但包含了方向（通過讓程序員……改善網絡體驗），同時還限制了范圍（Java 工具）。幾年后有一次我們和那位團隊負責人吃飯的時候，傅攀勃告訴他說我們非常感謝他當年堅定地支持我們讓團隊撰寫任務宗旨。他回答說，其實當初我們提出的時候他覺得這完全是浪費時間，但是當他開始和團隊爭論怎么寫的時候，他居然發現了一些之前都不知道的事情：他的首席工程師居然不同意產品的方向！ 撰寫任務宗旨強迫他們在產品的走向上求同存異，否則到時候一定會拖緩（甚至停滯）開發進度。在網上公開任務宗旨后，不但整個團隊自己可以完全專注在那些必須完成的事情上面，而且也不需要再浪費口舌去和潛在的貢獻者爭論產品方向——他們只需要讓新人去讀一讀“讓GWT更出色”這篇文章就可以了，很多問題都能迎刃而解。  任務宗旨可以幫助團隊求同存異 任務宗旨可以保證項目不會隨著進展而偏離目標。但它也不是一成不變的。如若所處大環境或是商業計劃發生巨變（對創業公司來說很常見），團隊成員絕不能頑固不化，他們應該重新評估原來的任務宗旨是否還有價值。像憲法一樣，這種改變肯定是異常困難的，因為它原本就不應該是可以隨意更改的東西。但是當這個時刻來臨之際，至少它是可以改變的，人們也應該予以認真考慮。任務宗旨應該與時俱進，及時反映公司或者產品的變化。 ### 開會要有效率 絕大多數工程師都把會議歸類為必不可少的惡魔。如果利用得當，開會是很有用的，但是人們經常會濫開會，組織不當，而且幾乎一定會把會議拉得很長。我們期望的會議應該像污水處理廠一樣：數量要少，位置要遠，還要在下風口。所以這一節也非常精練，只討論小組會議。 首先是所有會議中最可怕的：常務會議。這種會議一般一周開一次，應該只能用于發布簡單的通告或者介紹——要求所有與會人員一個一個報告進展情況（不管他們是不是真的有什么重要的事情要宣布）完全是浪費時間，只會讓人覺得不耐煩，恨不得立刻打暈自己好不用再受折磨。任何值得深入討論的內容都應該在會議結束后進行，而且應該只涉及相關人員。這種會議應該允許人們在重要議程結束時離開，而且要是沒什么大事，或者可以通過 E-mail 來宣布消息的話，完全可以取消會議。我們曾經見過一些把能夠參加會議和身份地位等同起來的公司文化，結果沒人愿意被落下。說得直白一點，這種做法實在是太愚蠢了。 有些工程師非常推崇像敏捷這樣的開發方法所倡導的每日站會，如果能保持短小精悍，這種形式是可以接受的。這種會議一開始的時候都很短（15分鐘左右），大家真的是圍站在一起，輪流報告自己正在做什么，但是如果不保持警惕，很快這些會議就會被拉長到 30 分鐘，人們會坐下來東拉西扯，好像是參加集體治療課程一樣。所以，如果你的團隊打算開每日站會的話，一定要事先委任會議主持人，而且他要看著時間，防止會議變得太長。 如果你正打算做一些新的設計，那么盡量把會議人數控制在五個人以下——除非只有一個人可以拍板，否則在超過五個人的會議室里是做不出任何新設計或者決策的。如果你不信，可以去找五個朋友一起跑到市中心，然后試試看你們六個人能不能設定一條覆蓋六個旅游景點的觀光路線。我打賭除非你們讓其中一個擔任領頭羊，然后他怎么走你們就怎么走，否則你們會站在路口爭論一整天。  沒用的會議和折磨沒什么兩樣 會議對所謂的“工作時間”⁴ 來說通常是一種干擾，這個詞的靈感來自保羅·格雷厄姆的一篇文章“工匠和老板的時間安排”⁵ 。如果工程師總是要中斷手頭的工作去開會的話，他們是很難完全進入工作狀態的。你應該在日程表上留出三到四個小時的大段時間，把它們標記為“忙碌”或者“工作時間”，然后把事情做完。如果一定要開會，那么盡量把會議安排在休息時間，比如午飯時間，或是下班之前。Google一直都有（可惜也經常被無視）“周四不開會”⁶ 的傳統，就是為了讓大家有時間把工作做完。好的開始就是成功的一半，以后甚至可以空出20～30個小時的大段時間來專注工作。 有關開會的五條小貼士： 1．只邀請一定要參加的人； 2．開會前要決定好議程，而且要事先通知所有人； 3．達成目的后應提早散會； 4．注意別跑題； 5．盡量把會議安排在休息時間前后（比如午飯時間，下班前等）。 開會前一定要事先準備好會議議程并且至少提前一天通知所有與會人員，讓大家知道要開的是什么會。把會議人數降到最低（別忘了同步交流的成本）。我們認識很多人會無視沒有議程的會議邀請，包括工程師、工程經理，甚至主管和副總裁。 為了能達成會議的目的，只邀請那些真的需要與會的人。有些人在發現與會者實際上是在看 E-mail 而沒有認真開會的時候，會規定不準帶筆記本電腦去開會。可惜這只是治標不治本——人們在開會的時候看 E-mail 很有可能是因為他們一開始就不需要參加這個會議。 主持會議的人應該拿出權威來毫不猶豫地（有禮貌地）打斷那些跑題乃至妄圖獨攬話語權的人。要做到這一點并不容易，但卻是值得的。最后，也是最重要的一點就是，如果時間尚早而議程上的議題已經討論完畢，千萬別猶豫，立刻散會吧。 ### 地理上分散的團隊 如果你隸屬一個分布各地的團隊，或者工作的地方離同事們很遠，那么不但需要在溝通渠道另尋出路，更要在溝通上面多下功夫。如果團隊里有異地的同事，那么決策的記錄和分享往往都是書面的形式，比如E-mail。在線聊天、即時通信、走廊上的隨性交談都可以是溝通討論的地點，但是我們還是需要把這些討論的相關內容廣播給所有人知道，保證大家的信息對等性以及參與度（另外一個好處是，存檔后的郵件列表就是文檔）。當需要快速建立對話的時候，視頻對話也是非常有用的工具，而且現在為整個團隊配備攝像頭的成本也是相當低廉的。 我們在做Subversion項目的時候有一句座右銘：“郵件列表上查不到的討論等于沒發生過。”在聊天室里說話可以百無禁忌，什么想法都可以提出來，但是到了真正確定方案的時候，我們千萬不能忘了那些沒參與討論的人。即便團隊分散各地，只要將這些談話內容重新發表到郵件列表上，每個人就都有機會看到決策是如何形成的（如果覺得有必要，他們還可以發表意見）。如果你想要培養基于共識決策的團隊文化，那么這一點是至關重要的。 和一個遠在異地的同事交談應該和直接去他的辦公桌交談一樣做到無摩擦。如果你在異地工作，那你應該利用所有的媒介（比如在線聊天、即時通信、E-mail、視頻對話、打電話等）和團隊溝通，保證大家不但知道你的存在，也清楚你在干什么。最重要的是，千萬不要低估了面對面交流的力量。無論你發了多少E-mail，在網上聊了多久，打了多少個電話，還是要大膽地經常跳上飛機去見見同事們。這也適用于海外的雇員、團隊和分部雇員——安排好時間去總部和同事們見個面吧。 ### 設計文檔 開發新項目的時候，往往很難抑制住那種想要立刻開始寫代碼的沖動，但是這么做的結果往往是很糟糕的（除非你只是打算很快地做一個粗糙的原型出來）。同樣，很多工程師都不做設計就直接開始編碼，后果往往是慘不忍睹的。 設計文檔一般由一個人負責，兩到三個人撰寫，審核的人數則更多一些。它不但勾勒出整個項目的前景，也直白地告訴整個團隊你想做什么以及打算怎么做。而且這時你還沒有花費幾周（甚至數月）編寫代碼，比較容易接受意見和建議，幫助你改進產品和優化實現。另外，當設計文檔定型之后，它能幫助你安排劃分項目的工作量。而且，當編碼工作開始以后，設計文檔絕不是一成不變的：隨著項目的進展而發生的變化應當及時反映在設計文檔里，而不是等到了產品要發布的時候才去更新，不過這一點是說起來容易做起來難。大多數團隊根本沒有文檔，而有些團隊只在很短的一段時間里有很漂亮的文檔，剩下的很長時間里只有過期的文檔。 說到這里，你也不要走到另一個極端“唯設計文檔論”里去。我們曾經遇到過為了一百行的小程序寫了整整四頁設計論文的控制狂。如果寫一份設計文檔的時間足夠把整個項目推翻重寫好幾遍的話，那就不要浪費時間寫設計文檔了。用經驗和判斷來作出適當的權衡吧。 * * * * * > ¹ 這一點我們要一再強調——保持專注的方法就是要拒絕各種誘惑。 > ² 我們經常把編寫開源軟件比喻成在彈跳床上用撲克牌搭建房屋。這需要穩健的雙手、大量的耐心，還有能大聲制止那些看也不看就想往下跳的人的決心。 > ³“讓GWT更出色”可以在這里找到，http://code.google.com/webtoolkit/making-gwtbetter.html。它絕對是任務宗旨的寫作典范。 > ⁴ 譯注：原文是“make time”，即工匠（maker）專注工作的時間。這里的工匠一詞泛指那些從事創造性活動的人，比如程序員、作家等。 > ⁵ http://www.paulgraham.com/makersschedule.html > ⁶ 這個傳統是Google工程部的副總裁韋恩·羅辛在2001年建立的，旨在改善工程師的生活品質。傅攀勃多年來一直都堅持不在周四開會，效果相當不錯，但是這需要非常嚴格的執行力，如果有人不識相的話，有時候還可以寫E-mail去大罵一通。