《專案管理之美》第10章

官僚是一種行政體系，其中需要或傾向於遵照呆板或複雜的程式，對有效率的行動產生阻礙。

你的團隊越大，你的專案管理活動讓人討厭的可能就越大。每當你追蹤其他人的工作，或者做出會影響其他人的決策時，可能就會惹惱他人；這與領域有關。如果你很聰明，就會找到方法把煩惱之事減到最少。他們會比較開心，專案也會運作得很好，而你在門廳中也不會看到很多人臉色十分難看。

最可能惹惱大家的三項活動是電子郵件、會議以及團隊流程（例如構建流程或規格說明書撰寫流程）。本章要討論執行這些任務常犯的錯誤，以及讓你以最小激怒風險因子（minimal annoyance risk factor，MARF）執行這些任務的基本方法。

人們被激怒的原因概述

因為我找不到有關惱怒歷史的出版物，我只能依靠自己的觀察，總結人們為什麼會被惹怒。我在這方面有很多經驗：我被惹惱過很多次，也見證過其他人處於生氣中的狀態，而且也知道偶爾也會惹惱其他人。

為了完全瞭解這些例項，描述時都以第一人稱來表達（閱讀時，想到你曾經和某個特殊的你所尊重的人一起工作的經歷，應該會有所幫助）。

       *     假設我是白痴。如果我受聘來做X，我能把它做好，無論何時，只要有人認為我無法做到X——或者需要20步的過程、規則手冊、模板、每日評估、委員會或其它可以讓我做X的流程——我當然有理由被惹火了。我的部分工作應該是幫助定義我的工作內容，並以某種能滿足管理階層頒佈的任何目標的方法。我應該被當成有能力才對，除非我失敗了並且證明我能力不足。只要合理，我應該能自由決定完成我工作的最好方法。

       *     不信任我。如果每天我都被指望要簽入程式，並且一而再，再而三地檢查，並要求彙報那些在我職責範圍內所做的決策，我就會被激怒。如果什麼事我都得確認，我究竟還有什麼許可權？如果我做得很好，為什麼還要把每件事都寫在檔案上、記錄下來？即使一開始因為某些原因我不值得信任，但管理階層的工作應該是提供一條公平的道路讓我去贏得信任，並讓我在那條路上繼續前進。

       *     浪費我的時間。如果團隊的運作方法逼得我不斷重複（無聊的）任務很多次，或者要做一些和我職務無關的事，去防止可笑而不可能發生、而且又無關緊要的偶然事件和管理階層的妄想，我就會被激怒。這包括重要決策的改變，或者傳達的資訊或行為非常不一致，甚至在被詢問時，也沒有試著去解釋（或者至少說聲抱歉）。

       *     對我不尊重。如果派我去做些白費力氣的事，指派給我的工作沒有實際的基礎，或者註定會失敗，卻因為那些超越我職責範圍的事情而指責我，我就會被激怒。應該要有人看著我，確保我的努力和專案的目標一致，指引我走向成功。因此，我請求協助，應該被認真看待，而不是一直被拖延或者忽視。

       *     讓我聽或讀些蠢事。不管什麼時候，要我去聽其他人講話，或者讀另一個人寫的東西，而這和我們正在做的工作沒什麼關係，我就會被激怒。對於bug的質量，我們有分類標準，為什麼對蠢事卻沒分類？有人說召集開會、寫檔案或發電子郵件，並不說明這些就值得我花時間去做。越是要求（或逼迫）我去做次要或更次要的工作，我就越沒生產力，越不高興。

惹怒的很多原因，可以解釋為什麼很多人都討厭工作流程的想法。他們害怕任何試圖將他們的工作系統化的事，最後只會導致官僚或其它形式的受難。我想，這種恐懼是沒有事實根據的。就和其它事情一樣，流程也是人設計出來的，只要設計者很聰明，心中有正確的目標，流程就能對每個人有益處。流程可以幫助大家，而不是限制和惹惱大家。

好流程的效果

我把流程定義為任何可重複的一組動作，由團隊決定定期執行以確保事情會以某種方式完成。流程有很多其它名稱：規則、指導方針、形式、程式或限制規定。（例如，如何簽入程式碼、測試和構建，就是工程流程的常見例項。其它例項包括規格說明書的撰寫和管理日程表和進度表等等）。好的流程可以提高專案完工的機會，而且效益要大於成本。然而，因為很少花時間研究流程存在的原因，或者流程（應該）解決什麼問題，所以很多團隊只是空有很多流程而已，無法從中獲得益處。

有時，問題出在是誰有權力身上。任何有足夠許可權的白痴，都可以想像出最令人厭惡的白痴體制來做事，並且逼迫團隊服從它。結果，當團隊奮力在那個流程下求生存而且真的做出一些事情時，掌權的人可能甚至會說，那個流程對事情成功起到了貢獻（卻看不見，即使沒有那個愚蠢的流程，團隊也一樣會成功）。如果他們有足夠的權力，他們可以鎮壓任何反抗，甚至繼續增加更多步驟來折磨團隊。

其它時間，問題在於哲學觀：X以前行有效，所以，我們就做X吧。”在這種情況下，團隊領導者過去曾以某種方式完成事情，就會堅持把該方法或流程強加到他所帶領的沒一個新團隊上（第8章提到了這種不良管理習慣）。這種習慣不好，因為只有當前的情況類似於過去的情況，否則之前X能成功，與現在無關。對流程的實際接受度測試，應該重點強調當前的需求，而不是觀察過去。

但是通常問題在於建立流程的複雜度。流程是試著組織大家如何工作和互動的，這兩件事非常重要，但又非常有組織。人們的工作方式不同——他們對正式的控制有不同的偏好和容忍度。如果建立流程的人不注意，這個流程很容易變成瓶頸，讓人們的工作慢下來，束縛他們的自由（感覺）和活力。

建立好流程的技巧，就是要了解兩件事：通常能讓專案和團隊成功的事項，以及使當前專案和團隊與其它專案和團隊有所不同的事項（請參閱圖10-1）。瞭解通常如何制定好的團隊決策是不夠的：你必須對共事的當前團隊的文化、個性和習慣負責。有時，不同的文化或專案需要不同的方法（例如，防抱死剎車嵌入系統的決定，和Steve朋克搖滾樂隊網站的決定是不一樣的）。通常，最好是讓團隊自行管理，而不要讓上級單位管理。讓團隊修改和建立自己的標準規範，而不是複用標準模板。就像任何型別的協商那樣（請參閱第11章），涉及到流程時，你必須要清楚知道你關心的利益，而不是特殊的立場。

可在此找到好的流程

通常能讓團隊有效的事情

使得這個團隊/專案和其它的有所不同的事情

圖10-1：好的流程通常需要對專案有感覺，還需要認識當前專案的獨特屬性。

為了幫助你尋找並辨認好的流程，這裡列出了好流程的特徵，和其對專案所造成的影響結果。當你坐下來建立或改進流程時，這份列表可以作為檢查列表來使用。

*     加速事情的進展。看起來似乎違反直覺，但是好的流程會讓人更加有效率。例如，美國高速公路上的白色分隔線限制你能往哪裡開。但是，因為每個人都受到同樣限制，所以，每個駕駛員都能開得很快。好的流程提供了人們可以依賴，並根據其定決策的系統。在某些情況下，程式定義了人們扮演的角色，使得Steve從Molly那裡獲得他所需要的東西會非常容易（例如，找人檢視程式程式碼）。一個規範的例項是自動化構建工具，可以讓人按幾個按鍵就能構建專案工作，只要他們按照構建系統所定義的設計要求進行。   

       *     防止問題。適當制定流程的最常見動機，就是防止某種愚蠢的事情發生（或再次發生）。挑戰在於做此的同時不讓事情的進展變得更困難，或滋生其它蠢事。這需要了解問題的起因，以及哪些因素對事情的進展最重要。只要問：“要確保X、Y、Z不再發生，最沒有干擾、最不會惹惱人和最便宜的方法是什麼？”或者，走另一條路，“這個流程能夠防止什麼問題發生？那個問題有多嚴重或可能怎樣？”如果流程沒有防止問題出現或者加速流程進展，就放棄它。

       *     讓重要行動可見和可測量。通過公開bug或釋出規格說明書的流程，可以輕易追蹤這些事情多久會發生。你也可以追蹤它們的狀態、結果如何以及團隊整體的趨勢。對於bug、規格說明書和測試而言，好的流程會很容易使其找出專案的狀態。這對中盤戰略和終局戰略非常重要（請參閱第14、15章）。

       *     包擴修改或刪除此流程的流程。因為專案隨時在變，這個月有用的流程，到了下個月也許就沒有用了。流程必須有內建的機制，可以決定何時需要更新或者停止。絕不要假設流程可一直用下去，而且因為這個原因，要避免圍繞流程定義工作。某人認為本身的工作是“執行測試通過5的人”，會用生命保衛測試通過5。相反，要讓人們對流程在專案上的影響和結果負責，而不是專案本身。

       *     受到影響的人會贊同。人們喜歡有幫助的流程。好的流程對那些需要的人來說是值得的。如果你提出的一個新流程會影響到程式設計師，但你的流程對專案有價值，這應該很容易讓他們試一試。人們應該直接參與制定他們會使用的新流程。可選擇地，如果會受提議中的流程影響的人，能夠列舉出數十個理由來指出為什麼這個流程很差，他們也許是對的。

好流程的公式

思考流程的一種方式是考慮流程正面效應的價值與實際的制定和執行成本的對比。有個公式可以幫助比較。你不需要為公式找到實際的數字就能使用它。我提出來它，主要是做為練習，來幫助你思考與增加工程流程有關的代價。如果你不喜歡練習或公式，就跳到下一節：這不會錯過重點。

首先，考慮流程的成本：設計流程的時間（DT），加上團隊學習它的時間（LT），加上通過流程做事的實際工作時間乘以使用的頻率（AT×N）。任何流程的總成本就是：

DT＋LT＋（AT×N）

然後，考慮流程的效益：流程避開的失敗成本（FC），乘以單位時間內沒有這個流程時，失敗情況發生的機率（FP），再乘以專案裡有多少單位時間（T）。

總效益＝（FC×FP）×T

結果大概是：

流程價值＝（（FC×FP）×T）-（DT＋LT＋（AT×N））

我完全承認，公式中全部都是過度的簡化，但是它的精神已足以令人感興趣。如果結果是高分，就比低分更有價值。負分表明流程效益比成本低。

開始開起來，這個公式表明，很容易建立能有效消除問題的流程。然而，這麼做的代價，可能超出一輩子跟那個問題共存的風險性（例如，為餅乾罐買價值5000美元的安全系統）。如果你把設計時間和學習時間包含進來，確認只有失敗的可能，那麼修改流程就不符合成本效益。

然而，你必須考慮效益的生命週期：它們通常會橫跨多個專案。更重要的是，後續幾個專案的失敗機率可能增加到100％。公式中的T值很重要：即使失敗機率（FP）很低，但時間間隔越長，失敗發生的機會就越大，採用流程防止發生的價值也越大。（這裡顯示出作為領導者的主要挑戰之一：決定何時付出有形的短期成本，以獲取較不明顯的長期收益。這種挑戰到處都是：僱用、裝置、工具、培訓等。種瓜得瓜，種豆得豆；長期投資是獲取長期提高的唯一方法。）

關於這個公式，最後一點要注意：AT值（使用此流程的實際時間）比看上去的要重要。好的流程應該要讓事情花費較少的時間；與沒有這個流程而完成工作所需的時間相比，如果真能節省時間，AT值應為負值。這改變了等式中構建的成本/效益關係。例如，如果AT等於5小時，但之前此任務花費7小時，淨值就是2小時。這表示現在完成此任務少花2小時，流程的整體價值就更高了。

如何建立流程並付諸實踐

當你找出一個問題，覺得可以用流程來解決時，就按照我在第11章所提及的那個粗略步驟來做。（即使你不是面臨危機，執行短期計劃的基本步驟也如此。）明確定義你試圖解決的問題以及最能幫助解決此問題的小組人員。以小組方式運作，產生幾個替代方案，然後，挑選最有希望的一個來執行。

接著，找出專案中可獨立出來的低風險部分，來試驗這個新的流程。如果可能的話，找幾個對改變流程有興趣，並且善於接受的人，讓他們參與建立流程。要對流程改變後應該有的效果達成一致意見，可能的話，要為它們制定測量標準。然後，讓相關的人蔘與制定改變。設定未來的日期，用以評估流程改變後的效用。

當評估日期到了時，再次和小組以及試驗相關的人一起開會。討論發生了什麼事。如果試驗是場災難，就重複流程，做第二次小試驗。否則，就根據你們學到的東西修改流程，再應用到較大的小組中（可能是整個團隊）。每個被要求使用此流程的人，都應該清楚你試著解決什麼問題，以及是什麼原因說服你這個提議的方法會的確幫助你（參與試驗的人給你的證據和證詞應該大有幫助）。

從下層管理流程

”絕不要低估大型團體裡蠢人的能力。”

——Todd Blanchard

有時，比你更有權力的人會強加給你的團隊那些你們不同意的流程。你們可能只是人數佔優勢，或者沒有權力修改流程。我們之中最優秀的人就碰過這種事。我知道有三種方式可以對付這種情況。雖然不總是有效，但值得一試。

       *     替你的團隊擋開流程。有時，你可以為你的團隊吸收流程。如果必須完成某些書面工作，你可以自己做。這可能讓你覺得自己好像是團隊的祕書，但是，如果你只花掉一個下午時間，而你的團隊就不用浪費時間，這樣的代價可能是值得的。在某些情況中，替他們擋掉蠢事，會讓你從團隊那兒贏得很多信任分。工作時間記錄卡、費用報告、強制性（但也很可笑）HR型別會議、裝置申請和其它惱人的瑣事，都是常見的可輕易擋開的流程例項。

       *     打賭不適合流程。召集你的團隊，討論對流程的反意見。找出流程試圖預防或確保的事，並對當權者保證，沒有這個流程，你的團隊也能實現那些目標。設定一段時間做評估。如果在那時間之後你的團隊失敗了，你就同意採用流程。但如果他們成功了，你就不再理會這個提案。至少，這樣可以把對流程的討論集中在正確的問題上（我們試圖解決什麼問題？），所以，即使你失敗了，也會得到一個改善後的流程。（在一些罕見的案例中，利用對其他類似而成功的組織進行的研究成果，或者以某種不太愚蠢的方式來做，可以獲得支援，並避免打賭的需要。）

       *     忽視流程。我傾向於忽視那些我不瞭解的遙遠的、模糊的、官僚的、組織性的事情。我的理論是，通過忽視它，我會迫使兩件事的其中之一發生。或者負責那件事的人會和我聯絡，問我為什麼沒做，給我機會和他對話，瞭解我為什麼到底應該做；或者，如果沒有人問我為什麼沒做，那麼可能就是沒那麼重要。我將繼續做我的事，沒有那件有爭議的事，我會很成功，同時，如果日後有人問我為什麼沒做這件事，我也有很好的正當理由（“哦，嗯，沒有那件事，我們也把X做得很好。也許你可以說服我，Y應該有什麼幫助？”）。在新的組織中，這通常很有效，因為你有對組織有不熟的額外借口。不過，要小心：你的政治前景可能因為忽視官僚，而讓你身陷危險之中。

不令人討厭的電子郵件

雖然郵件的主題似乎有助於閱覽，電子郵件仍然是人們處理專案時，最令人討厭的系統。因為我們收到的電子郵件數量太多，要儘可能快速閱讀和回應新郵件，自然就會感到壓力，通常也會犧牲好的閱讀質量和寫作技巧。多數人都不會認真閱讀或寫好電子郵件。諷刺的是，當我們無法理解別人到底想說什麼時，或者無法讓他們理解我們想說什麼時，電子郵件的便捷也就被浪費了。

對專案經理們最重要的，就是電子郵件是和領導們溝通的基本方式。在建立新郵件和回應其他人傳送的郵件時，領導者會影響專案內的資訊流動。如果領導者有明確的想法，提出實質的問題，就等於鼓勵其他人也這麼做。對與數十人進行的廣泛討論做一次響應，就可以讓清楚的想法傳遞給整個組織。但是，如果領導者思路表達模糊，常發表不清或混亂的觀點，就會破壞團隊的溝通能力。

一個主要的挑戰就是，很少有人承認他們寄出了很差的電子郵件。例如，做以下測試：利用你自己的主觀判斷，你從自己組織成員那兒收到的電子郵件中，具有高質量郵件的百分比是多少？中等質量的是多少？完全沒有用的是多少？現在，問你自己，你寄的電子郵件中，各有多少百分比符合這每一種情況。以此為試驗，我曾問過一個由PM、測試員和程式設計師所組成的小團體這個問題。差不多2比1，每個人都認為其他人寫的垃圾郵件比他們自己寫的還多。因為他們都一起工作，這個有趣的資料表明，每個人都認為問題都是由別人寫的郵件引起的，而不是自己的。我沒有更有力的資料可以支援這種主張，但確實如此。不知何故，當溝失敗時，人們一般傾向於責怪他人（要找更多的證據，只要看西方文明的國際政治史就可以了）。

好的電子郵件

我在微軟學到的一個習慣就是獎勵好的電子郵件。很多重要的討論都會在電子郵件裡進行，這類討論常常使不同階層的人蔘與進來——產品線PM、中層經理，VP也許會來回交換郵件，將彼此幾乎視為平等的。我發現自己也時常身陷這些爭論之中，通常是因為我負責的事突然間成為公司的關鍵。

在這些電子郵件的討論中，我經常對其他人所說的某件事，做出強烈的回應。我謹慎用字，不斷修改到正好為止：簡單、強硬而清晰。然後我再把它發出去。我的論點有時被粉碎，有時被忽視。不過，偶爾我擊出全壘打。幾分鐘後，通常會接到VP或“其他比我重要的人”私下發給我的電子郵件：“郵件不錯”。討論也許還在繼續，但我知道我已在討論中取得成功。更重要的是：有人花時間讓我知道我的觀點很好，而且我表達它們的方式獲得了讚賞。¹

註釋1：我一直保留著那些讚賞的電子郵件，有點不好意思，可能是因為管理層沒有做出足夠的讚賞。IM和電子郵件所能提供的，和開會時點個頭或來個微笑這種次要的反饋不一樣：也許這些額外的電子郵件，以某種方式補償了這一點。

聰明的經理人會重視好的電子郵件。經理們每天都要讀一堆寫得很糟糕的電子郵件，如果他們不花時間讚美那些溝通良好的人，就不可能看見更多人這麼做。稍微處理的電子郵件大約只花15秒就能寄出，就我的故事表明，這種信對組織中的其他人而言，要意味著比你想的還要多的事情。

但是，讚美他人容易，要對自己傳送差郵件的習慣負責就難了。如前所述，我相信多數人都認為，他們寫的電子郵件比別人認為的要好（你越認為自己寫得好，就越難得到有關你電子郵件禮節的誠實反饋）。因為領導者和經理們發的郵件比別人多，找出你有什麼壞習慣並投人精力加以改正，是很重要的。以下是一些關於專案管理的建議，指出好的電子郵件應該是什麼樣子，以及有哪些常見的不好習慣。

       *     要明確、簡單和直接。數學家帕斯卡，Pascal程式語言就是以他命名，曾寫過；“如果有更多的時間，我會寫更短的信。”語言就像程式一樣，可以最優化。你想讓溝通效率最優化，而不是讓邏輯效率最優化。如果收件者無法理解由語法和邏輯都正確的三個字所傳遞的訊息到底是什麼意思，那麼它是無用的，這一點和程式碼不同。²要考慮誰會讀這封電子郵件，如果你和他面對面交談，你要如何解釋？還需要什麼細節？能省略什麼？你能假定他知道哪些概念？你能夠使用哪些比喻？對於重要的電子郵件，在發出之前，先離開幾分鐘，然後再回來讀一遍，在你傳送它之前，腦海中想著那些問題。對於重要的電子郵件，或者要傳送給一大群人的郵件，要讓你團隊中的某個人先流覽一遍，並給你一些反饋。

註釋2：關於Victor Hugo但可能是捏造的故事，描述了聰明地利用簡潔溝通。當《悲慘世界》出版時，Hugo給出版商發了一封電報詢問結果。他的電報儘可能簡潔，只有一個字元“？”，而他收到的回應也只有一個字元“！”。顯然，銷售相當可觀。如果這裡有什麼可學的，那就是兩個彼此非常瞭解的人，能夠比其他互相不瞭解的人溝通起來更加有效，這也是和同事發展人際關係的另一個重要原因。

       *     提出行動和截止期限。最好的電子郵件有明確陳述的特定要求，而且在適當情況下確定了合理的截止期限。應該很容易就讓人讀懂電子郵件，瞭解他們為什麼收到這封電子郵件，採取行動會對如何影他們，以及他們必須做什麼（在截止期限前）。假設你堅持截止期限（“這些要求必須在週五給我”），那就等於你通過電子郵件交流，讓人注意到未來的行動，使你處於有權力的立場。

       *     優先順序。有其必要傳送這封電子郵件嗎？你發的郵件越多，其他人就越要對你要求的事排出優先順序。有多少你提到的事情是重要的？如果你有10個問題要討論，就把它們分成兩組，集中焦點在最重要的一組。考慮是否有哪些事情可以用電話處理，在下次團隊會議中處理，或者挨個辦公室去談來處理。如果你沒有分出優先順序，卻希望收件者為你分出優先順序——那他們只會按照他們的利益去區分，而不是按照你的。

       *     不要假設人們會讀所有東西（尤其是對你特別重要的）。因為你發了郵件，別人就要讀，這是很傲慢的想法。人們每天都收到很多電子郵件，多數都來自和你一樣重要的人。問題對你越重要，你就越得花心思以確保人們真的會積極針對郵件做些事情。你和團隊成員之間建立的信任越多，就越能假設人們會如何回應你發的郵件。

       *     避免太詳細。很少有情況是讓每個人必須瞭解導致事件發生的前因後果。要避免在寫電子郵件時，把焦點放在不同參與者所貢獻的行動上：“當Sally第一次設計我們的構建流程時，她對……感興趣”，或者像敘述式的散文一樣，“會議召開順利，Bob和Steve以極大的熱情和信念談論他們的幻燈片。就是這樣，直到……”相反，應該集中在影響上：發生了什麼事？會如何改變世界？以及我們應該為此做些什麼？如果你被迫加入一些背景細節，就把它們列在要點之後。對於幻燈片、網站、檔案等參考資料，也這麼處理。儘量讓每個人都能儘快看過前兩行之後，就能立刻知道是否足夠重要，值得他們繼續讀下去。

       *     隔離FYI（For Your Information，供你參考）信件。我曾經待過一些團隊，他們堅持轉寄大量有些有趣，但和任何事都沒有直接關係的電子郵件。有些人稱這類郵件為FYI郵件，也就是供你參考的電子郵件。好奇心和了解業界狀態都是良好的習慣，但不要讓這些事主導了用於更實際工作的溝通論壇。設立另一個電子郵件名或討論組，專供“業內趨勢”或“技術展望”使用，讓你的團隊可以把他們發現的很酷的東西放上去。如果你的郵箱委託人支援它，就讓每個人把這類郵件設為低優先順序，或者在主題欄開頭加上“FYI：”。讓大家很容易把它們過濾出來。

       *     電話是你的朋友。如果你不明白你收到的重要電子郵件中的某些事，就不要回復一封包括精緻的五部分問題的郵件。看看你是否能用電話聯發件人。互動式溝通在解決困惑和衝突時，總是比電子郵件更好用。30秒的電話交談，通常相當於一長串費時的電子郵件交換。如果真的能用電話聯絡發件人並解決問題，那麼你就能在電子郵件中寫出你已理清的理解並分享給每個人——如果你感到困惑，其他人可能也是如此。電話（或走到門廳）是群體電子郵件溝通的重要促進工具。³

註釋3：可能有種溝通定律主張，溝通的優勢模式（電子郵件）依然依靠之前的優勢模式（電話）：IM一電子郵件一電話一傳統郵件一煙霧訊號一面對面等。

差的電子郵件例項

嚇人的電子郵件很容易就被識別出來。嚇人的電子郵件通常很長，寫得也很差，有很多附件，而且很難略讀。很明顯就能看出來，這通常會被忽略或被適度提出疑義：“Fred，我發現這封電子郵件很難懂。如果其他人同意，你可以修改一下或召集會議說明嗎？如果不行，我再打給你。謝謝。”因此，嚇人的電子郵件並不是最危險的那種。

真正危險的電子郵件，是那些看起來寫得很好，但實際上卻充滿了讓人分心的東西，想法也不全面，而且令人模糊不清的郵件。下面是相同內容的兩封電子郵件例項：一封很差，一封很好。這是很差的那封：

寄件人：Jack Colono

收件人：前鋒開發團隊

主題：最近檢查討論摘要

過去四周以來，我們之中有很多人想知道，我們重新設計的程式程式碼簽入流程，什麼時候可以最終完成。我知道我們花了很長時間在門廳和會議室裡討論，想找出正確的方法來決策，但卻沒有了解新流程的實質設計。挑選委員會成員對我來說也不容易，很多人都知道，花的時間要比預期多。我為此感到道歉，但這些事還是發生了。

所以，首先，我想讓你們知道新提案的一些重點，避免有人錯過了我們的週會討論，或者這兩週沒有和我談過情況：

1．簽入程式非常重要。它們決定我們到底在構建什麼。

2．每個人都有意見。我們都聽過Randy和Bob各自的詳細描述，解釋他們認為當前系統這麼糟糕的原因。

3．沒有簡單的答案。我們討論過的多數修改都有缺點。所以，當我們最後達成結論時，在轉換時期會有一些粗糙之處，而且可能會持續不斷。

得出這些結論後，現在我想讓你們知道，本週剩下的時間我會給你們發去修改過的提案。請注意我發的下一封電子郵件，應該很快就會發了。

謝謝。

Jack

很好的電子郵件例項

和很差的郵件不同，這封電子郵件沒有提到任何情節，或試著為任何事情辯解：所有都是關於行動。電子郵件內容很短、又十分明確而且抓住重點。它實際提供了提案，而不是在談論那些提案。雖然有最後通碟的味道，但確實達到為提案建立逃逸速度的目的，以幫助把提案推出。

寄件人：Jack Colono

收件人：前鋒開發團隊

主題：新的簽入程式流程

新的簽入程式流程的最終提案已完成，放在網站上：http://intman/proc/checkin/。

因為這是一個有爭議的問題，我已經和團隊中的多數人一對一地討論過這個提案，整合了每個人的反饋意見。如果其中沒包括你的，而你有強烈意見，請儘快發給我。

但要注意：關於這些即將到來的改變，這是第二次公開宣告。目前修改的機會很小，今後會更小。請現在就採取行動，不然就保持沉默。

週五下午五點，是針對上述提案和我聯絡以提出反饋意見的截止時間。在那之前，我會考慮和回應任何問題或意見（和適當的人共同研究）；否則，這件事就這樣，並在下週開始生效。

謝謝。

Jack

不用對範例中的內容深入細讀，就會發現這兩封電子郵件的差異很明顯。這些電子郵件不是應該怎麼做什麼或不應該做什麼的模板。你寄出的每封電子郵件都有不同的目的，和這些範例不同也許有其道理。只要你寫的時候經過深思熟慮，有明確原因，就去做任何必要的事。但總是要尋找方法直指要點，利用電子郵件使事情發生。

如何召開不讓人討厭的會議

以下是我對會議的看法：我不喜歡定期開會。除非有股力量可使會議保持精簡利落，否則最後都會變成緩慢、膨脹、令人沮喪、功能紊亂地浪費時間。然而，如果有那股力量存在，會議就會變得有活力、能把房間內每個人的經驗集中起來。挑戰在於，無論是誰組織和主持會議，都必須知道他在做什麼。

初學者要了解開會有多昂貴。如果會議持續1小時，有10個人在那裡，會議的成本就是10人1小時。整個團隊被關在會議室裡，等候著值得他們花時間的事情發生，而不是去修改bug或結束問題——這是兩種保證事情有進展的形式。事情也許會發生，也許不會發生。所以，我認為程式設計師和其他人抱怨開會是有理由的；相對於待在計算機前時間的價值，開會用掉的時間通常沒有什麼價值。

然而，如果因為要公佈重要想法或決策而需要大家參加開會，會議產生的資訊會改變每個人參會後的行為，或者深入瞭解專案進行中的事項或受到激勵，那麼，這種會議的價值就比較高。開會就不再是雜物事，而是一種難以靠其它方式消化或交換資訊的方式。

促進的藝術

幾年前，我記得曾對如何構建Windows系統的重要部分有過重大爭論。我提前到了，看著每個人走進會議室並坐下，對他們自己的意見有信心而自鳴得意。我看著他們斜靠在椅背上，在會議開始前，演練他們腦海中的論據。當然，爭論恰恰就是我們要做的事。10分鐘的時間，討論就在大浪裡來來回回。白板上盡是些非常潦草而且互相沖突的圖表，完全無法達成一致意見，到處都是諷刺的陳述和修辭性的質問。最後，我的組經理Hadi Partovi站了起來，他安靜地走到房間前方的白板前。

一句話也沒說，他就列了一份問題列表。房間安靜了下來。每個人都停止了爭論，看著他在做些什麼。當他寫完時，他問白板上寫的是否是正確問題。每個人都點頭。然後，他讓我們一次解決一個問題。其中還是有爭議，但有了架構，就戲劇性地大幅減少了。Hadi沒有提出自己的意見（雖然我知道他有意見）。相反，他花費精力幫助我們探索我們認同的問題。這就是促進的藝術。

促進（facilitate，動詞）：讓事情變得簡單或更簡單的行動。

只有當房間內有人知道如何促進，才會開好會議。有些人出於本能這麼做，而有些人甚至連做的時候也沒有意識到。就像其它人與人之間互動的技巧一樣，人們對進行互動的各種方式以及如何影響它，也有不同層次的認識。

促進者可以是一種半正式的角色，由組織展示的指定人選擔任（通常是PM），或者由召開會議的人擔任。有的團隊有很強的促進文化（表示很多人有這種技巧），因此，在會談過程中，他們可以自然地轉換由誰來扮演這一角色。但是，多數時候，對多數專案來說，開會時都特別需要促進的才能。

促進指標

促進是多數團隊都視為理所當然的一種技巧。有一些書⁴和課程都在談如何促進，但是，如果你想了解所涉及的技巧，最好的辦法是觀察能做得很好的人，然後試著在下次你組織的會議中，應用你觀察到的技巧。然而，有一些指標值得一提。我花了很長時間才瞭解這些指標，它們可長期幫助你發展自己的各種自然促進技巧。

註釋4：兩本起步的好書是Tom Justice所著的The Facilitator’s Fieldbook（American Management Association出版，1999年）和Thomas A. Kayser所著的Mining Group Gold （McGraw-Hill出版，1991年）。

       *     建立主人的地位。如果你是會議的組織者，那麼你就是實際上的促進者。會議開始時，先介紹參會人、澄清日程，然後開始討論。如果你從人們走進門的那一刻起就像個主人，他們就會表現得像客人，很尊重地對待你。謹慎選擇你坐在房間裡的位置：坐在桌子前端或中心區，會給你最多的權威感，而坐在角落給你的權威感最少。

       *     傾聽和反映。促進者的核心作用就是幫助他人溝通。如果有人說了不完整的事（但不是完全沒有價值），就要幫助他發展完整這個想法。試一試重複他人說話內容的反映技巧（reflection trick）：“所以，Mike，我想你是說（加入Mike想表達觀點的較好說法）。對吧？”這樣不但提煉了他的觀點，也為大家示範了該如何合作討論。然而，要小心地把想支援自己想法的願望隔離出來——如果你被自己的議程所負累，就很難做個稱職的促進者。有些組織會聘請專業的促進者，來幫助解決有爭論的會議並提供諮詢。

       *     引導會談。以議程作為嚮導，必要時跳出來，把討論推回必要的正軌。要有靈活性，讓人表達自己，如果議程指出要往西走，而會談卻往南去，那就必須做些事情。禮貌地打斷談話，指著牆上的議程，要求他們暫時擱置眼前的討論，直到日程中的問題都結束為止（或者，如果新問題非常有價值，可以提議調整日程）。注意看誰講得太多，誰又說得太少，根據情況控制發言權（“Bob，暫停一下……Steve，對此你還有什麼想法嗎？”）。

       *     結束會談。對於問題應該何時改到其它地方解決，你的心裡要有個標準。通常確認問題，找出由誰來負責，要求那個人自己進行，明天或後天再把提議的方案拿出來，這樣就足夠了。這是很好的方式，可以結束佔用會議時間的不必要爭論：“噓……，大家暫停。Sam和Bob，你們兩個去了解和處理這個問題，好嗎？到時再回來，讓我們知道你們的決定。”當其他五、六個人已經厭煩了一整小時，絕不要再讓兩個人控制發言權。

       *     製造歷史。花時間記錄討論內容（如果有可能，發生時就記錄）。作為促進者，這可以幫助你追蹤議程的進度，和幫你與小組進行溝通。因此，我完全迷上了白板。白板是最容易的方式，可以抓住人們所說的事，列出待辦事項的列表，或者找出一致（不一致）的觀點。但是，你要怎麼做並不重要。重要的是當會議結束時，接下來的步驟和會議重點已被記錄下來，傳送給那些參會的人。有人說，記錄員是個有權力的職位，因為你可以影響事情記錄的方式和要強調哪些方面。即使情況不是這樣，傳送記錄的確提供了推進作用，使別人理清你誤記的事情。

即使你不同意這些指標，我還是希望它們能夠幫助你瞭解開會時需要有個領導角色。如果沒人積極扮演這個角色，會議就傾向於令人沮喪而且/或者讓人感覺很無聊。一般的看法是“開會很讓人討厭，儘量避免。”但真正的問題是會議應該怎麼開，而不是會議本身的觀點。

三種會議

對會議組織者最大的陷階，就是忘了會議有多麼多面。不是所有的會議都以同樣的方式召開，或者應該有相同的結構。90％的人認為很多會議很無聊的原因，是因為目標和會議的結構、大小互相沖突。超過七、八人時，不管誰在促進，都無法進行高度互動的討論。以非常粗略的規則來分，有三種會議，各有不同的限制和應用。一定要考慮哪種會議最適用於必須要解決的問題。

       *     高度互動的討論。希望會議中的每個人都參與。目標：深度和密切。焦點：探索或解決特殊問題，或者尋找可替代的想法。大小：小到中（2～8人）。例項：設計討論、頭腦風暴、危機管理和分類。

       *     報告或一般的討論。有人要公佈資訊，而他需要人們響應或理解那些內容。目標：獲得高層次的反饋或分享知識。這也可以是高度互動的，但只會在群體中的少數人之間發生。有幾個人會在會議期間取得發言權，驅動者和響應者的角色會改變。大小：中到大（5～15人）。例項：規格說明書檢視、架構檢視、管理檢視以及小型展示。

       *     狀態和專案檢視。目標是總結團隊或整個專案的狀態。給領導者機會，讓他在過程中做出修正，並立刻從管理階層提出新指令給全組成員。當這類會議包括蒐集狀態的活動，或者迫使每個人聽取狀態報告時，這些通常就是全世界最無聊的體驗了。大小：中到大（0～100人）。例項：狀態檢視、專案檢視、大型展示以及全體會議。

當目標和會議的組織方式不一致時，最令人討厭的會議就會發生。如果房間內有10多個人，就很難有高度互動或深入的討論。每個參與的人沒有足夠時間，結果就會出現一小群有主導個性的人會用掉大部分可用的時間（除非有人在促進會議來避開這種狀況；然而有一小群有主導性格的人，也不總是壞事）。多數委員會因為採取這種形式，而做出可預期的沒有價值的結果。

週期性會議的禍害

第二最令人討厭的會議，就是週期性會議（每週、每天、每月），儘管已經不需要，卻還是會持續數週（微軟的一些大樓裡，根本無法訂會議室，因為被已經放棄的週期性會議塞滿了會議室預訂系統）。週期性會議能為工作制定一種節奏，迫使大家在同一時間待在同一房間內，這點很好。當大家實際聚在一起時，所有小問題就能快速且隨意地解決，而且可以每週相互會面一次或多次。“哦，嘿，Sam，我一直想問你……這個API要改變嗎？我看見你的簽入，我想這可能會影響我，但我不能確定。”電子郵件和打電話不保證會有響應，但是，當別人坐在你旁邊時，你通常會得到你所想要的。

問題在於，太容易召開的週期性會議了，以至於這類會議的價值失去以後它還能持續很久。當有些人不再來時，或者其他人利用這段時間用膝上型電腦檢查電子郵件時，這就表示出問題了；這種會議不再值得花時間召開了。經理們（以及其它會議組織者）常有的恐懼就是取消這類會議，他們便會失去控制。但是相反地，拿不需要的會議折磨團隊，正好是經理人失去他們試圖保護的影響力的原因。

這有一條好規則：選擇參加會議（opt-in meetings）。把週期性會議放在進度表上，並要求每個人在會議召開前5分鐘檢查電子郵件，看是否有議程。如果有實質性議程，組織者就把它發給大家，然後就開會討論。如果沒有議程，就寄信說沒有，會議就取消（針對那一週）。這樣如果必要就給團隊預留了時間表，但又沒有迫使眾人參加虛設的會議。如果超過三、四周後還沒有會議召開，這種週期性會議就應該完全取消。

會議指標

最後一節是關於成功管理和參加會議的、時常被忽視的戰術列表。這種事沒什麼迷人或有趣的地方：就是一些你和一小群人共事時，必須處理的特殊事情。任何只要運作過很多會的人，都會有他自己喜歡的技巧和小貼士列表。至少，我希望這份列表能幫助你想一想，過去哪些事情對你是行得通的。

       *     房間裡坐的是該坐的人嗎？有些人只要你邀請，他們就會來。有些人除非你把他們打得不省人事並拖來，否則他們不會來（並且/或者用糖果賄賂他們）。PM大部分工作就是讓該來的人在正確的時間出現在房間裡，所以，如果有人應該出現在你的會議上卻還沒有到，不用害怕跑到門廳或者衝進其他會議室去找他。甚至，更糟糕的是：如果你要開會了，還沒找到該來的人，就停止會議。不要浪費一小時的時間去做一些你在明天或後天達到最低指定人數時，還要再做一遍的事。最後，如果你找到該來的人了，但是看見不需要的人出現在房間內，就告訴他們吧。要講求策略，告訴他們會發會議記錄或摘要給他們，但要讓他們離開，尤其是如果他們會阻礙會議召開時。

       *     坐下或站著。讓會議簡短的一種技巧，就是讓每個人都站著（例如，在門廳或外面開會）。這個理論就是這樣能迫使眾人抓住重點，只提出值得群體討論的問題。會議只需持續5或10分鐘，最多就這樣。SCRUM⁵流程提倡每日站著召開狀態情況會議，會上只問三個問題：上次會議之後，你都做了什麼？什麼阻礙著你？到明天會議前，你將要做些什麼？通過這種赤裸裸的承諾來精簡會議，即使是最暴躁的工程師也應該願意參加會議了。傳統的坐式會議應該留給較小的群體。至少，值得試一試作為實驗；最差也會激發大家去思考，安排一個小時的會議並不需要耗掉整整一小時。

註釋5：瞭解SCRUM的更多資訊，可登陸http://c2.com/cgi/wiki?ScrumMeetings或者http://www.controlchaos.com/。

       *     準備。會議經常是因為缺乏準備而失敗。一定要考慮你需要多少準備時間來召開，才能達到它的目的。有時，這會很少：一份問題或開放問題列表，或者在前一天發出包含議程的電子郵件。其它時候，會複雜些：幻燈片、樣本展示、裝訂好的印刷品。無論何時，只要有會議不像你想像的那樣開展，就問問你自己，還有什麼可以做得不一樣。多數時候，答案會涉及到某種粗心的準備工作。一種技巧就是當你發出會議邀請函時，要考慮這一點：在你的日曆上空出時間，讓會議在召開前，有足夠的準備時間。

       *     膝上型電腦和小工具。我有很強烈的偏見，反對在會議期間使用小器具和膝上型電腦。如果房間裡的人認為進行中的事不夠重要，不值得他們全神貫注，那他們就不應該出現在這房間內（除非這是狀態或專案檢視型別的會議，此時訊號與噪聲比很低）。面對面的時間很珍貴，應該用於大家自然就覺得很重要而且值得他們花時間的事情上，而電子郵件和語音信箱是設計為等待的。如果你對這點有意見，可以和團隊的其他人談一談，針對會議期間妥當使用膝上型電腦，看看你們是否能達成一致的政策。

       *     準時。這是由資深人士推動的行為。如果VP傾向於晚到，那麼每個人都會如此。如果他通常都準時，那麼每個人也會如此。你可以試著準時談重點，但如果重要人士不在那兒，等他們出現時，你只能再重講一遍——這就是失敗的原因。然而，如果你在等的是你的同級或下屬，可以試試喜劇性的激怒戰術。我最喜歡的技巧是打電話到每個遲到者的辦公室。如果他還在那，適度地當著眾人的面，在電話裡嘲笑他：“晦，Sam，如果你出現在第5會議室，我們會感到很榮幸的。”如果他不在那，就給他的語音信箱留話。對著麥克風，讓房間裡的每個人都說：“我們愛你，Sam！”或者唱生日快樂歌。每次開會時，都用這招對付那些遲到或最晚到的人。這樣，會議就會變得有樂趣地開始——而且也多了一個準時到會的動機。

       *     會議結束時要有明確的步驟和負責人。會議結束後，最重要的就是接下來要發生什麼事。你可以開個人類史上最可憎、最令人討厭、最殘酷的會議，但是如果你離開會議室時，有5件必須完成事情的正確列表，以及5個同意把這些事情做好的人的名字，那麼你就成功了。絕不要讓人們離開時，還不清楚接下來的步驟是什麼。你的事前部分準備工作，就是應該考慮你該如何實現這個結果，以及由誰來負責每項任務。

摘要

       *     專案經理總是容易惹惱別人。有些是可以避免的。

       *     人們生氣的原因有很多。通常，當他們感覺時間被浪費了，他們被別人像白痴一樣對待，或者當他們被認為可以忍受長期沉悶和虐待時，就會被惹惱。

       *     好的流程有很多正面的影響，包括加速流程和防治出現問題。但是，人們很難設計好流程。

       *     不令人討厭的郵件是簡潔而具有行動力的，它能迅速讓讀者明確其是否有足夠影響需要他們進一步讀下去，或者只看一句就結束。

       *     當有人推動會議時，它就能順暢運轉。

       *     當目標和會議型別不符時，令人沮喪的會議就會出現。

練習

       A.    你認識的最令人討厭的人是誰？他什麼地方讓你討厭？你覺得有人針對他令人討厭的地方給他反饋嗎？如果你不想令團隊的人討厭你，如何才能獲得他們的反饋？

       B.    你所經歷的最好的工作流程是什麼？是什麼使得這個流程那麼好？這個流程應用一年後，仍然對專案十分有用嗎？

       C.    你所經歷的最差的工作流程是什麼？是什麼使得這個流程那麼差？領導們本來應該能做哪些不同的事情？你曾建議那些被忽視的改變嗎？或者你只是保持沉默？團隊領導如何才能從團隊成員那裡或者關於令人討厭的流程的資訊？

       D.    上一次你稱讚某人電子郵件既簡單由清晰是什麼時候？在接下來的一週，每天都感謝那個傳送給你最清晰、最有效的電子郵件的人。

       E.    控制你的電子郵件。沒有法律規定郵件一來你就要讀它，或者在一個小時之內回覆它。有些研究表明如果你成批處理郵件，一天兩到三次，你花費在郵件上的時間就會下降，總體的工作效率就會提升。做一個實驗，把你每次檢查郵件的時間記錄下來。明天，把少檢查一次作為目標，這樣一天天減少，知道你能控制它。

       F.    這是一個團隊實驗：把一週的某一天下午作為無郵件時間；例如，從2點到5點要求每個人不能回覆郵件。這樣可以讓所有人在這幾個小時內可以自由地、更好地控制自己的工作。實驗之後，詢問團隊成員感覺生產力提高了，還是減少，或者沒有區別。

       G.    下次參加會議時，帶一個記事本。每次會議，都找出誰能推動會議，記下他是怎麼表現的。一週結束時，列出你看到的最好的技巧和習慣，並且把模仿它們作為你自己開會時的目標。

       H.    如果你發現自己並不符合某次會議（會議的大小不合目標要求），你應該做些什麼？a）等著看看是否有其他人抱怨；b）建議會議組織者改變會議的規模，這樣會增加開好會議的機會；c）或者開始一個聽音樂搶椅子的遊戲，把沒搶到椅子的人趕出去，直到會議人數合適為止。你選擇其中哪一個？

       I.     歷史上，每一種官僚都滋生於簡單而傾斜的流程。研究官僚系統歷史會讓你極大地感到灰心（例如，政府稅收系統，HR僱用程式，工作花費報告，等等）。找出那個系統的第一個版本像什麼？它是如何進入現在你所知道的這個系統裡的？官僚原本可以被阻止嗎？既然你知道了歷史，你本該做哪些不同的事情呢？

       J.     看看所有你反覆的會議，把它們按重要性排列起來。取消最不重要的反覆召開的會議，試著用其它會議或者郵件來代替它本身傳達的目的。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16502878/viewspace-594279/，如需轉載，請註明出處，否則將追究法律責任。