如今，大家都在跨部門合作上空口說白話。我們的員工調查結果顯示，幾乎所有人都認爲我們應該更好地合作，但幾乎沒人真的去那麼做。哈，問題究竟出在哪裏呢？
可能是部門之間有衝突吧？衝突的交付日期，衝突的版本，衝突的功能，衝突的需求，衝突的優先級、目標、客戶羣、業務模式、行銷信息、行政方向、預算約束、資源。喂？！？大家注意了，大部分團隊在他們自己部門內部的合作都麻煩重重，更別說跟其他的團隊一起工作了。
是的，“不過，I. M.Wright先生，”你說，“合作是好事。”Bug只需在一個地方被修復一次。不再有重複的工作。用戶都使用一種常用的方式去做事，提供的用戶界面也只有一個。開發者只需理解一個應用程序編程接口。幾乎沒有缺口留給黑客去攻擊，也沒有很多漏洞需要打補丁。各個部門可以共享資源和源代碼。大家可以把更多的精力放在設計上，而放在實現和測試上的精力可以減少。還有……
我們又回到了剛剛開始的地方。合作是好事，同時也是棘手的，跟其他人一起工作大體上也是這樣。關鍵是要有良好的協商技能，而我們當中幾乎沒人意識到這一點，更別談實踐了。那我們該怎麼辦呢？我瞭解到，微軟使用了兩種基本的合作和協商方法……
一個你無法拒絕的方式
第一種方式是“無條件合作！”這也是我們這裏迄今爲止最通用的一種方法。某個掌權的大人物強勢地監管着所有人，直到他們能夠在一起很好地工作爲止。（通常是一個管理人員安排部門之間的合作或其他事宜。）如果那還不奏效，管理人員就把兩個部門合併在一起，那也就沒得選擇了。
這種協商策略就是通過大聲叫喊，試圖脅迫大家以你的方式去做事。哈，真幼稚！除了那個以強凌弱的人，沒人喜歡這種威逼的方法。最糟糕的“重組”就是以這種方式來進行的，因而重組常常令人厭惡。優秀的人才會離開部門，有時甚至會離開公司。大家的感情受到了傷害，生產力和士氣像互聯網泡沫破滅時的股票一樣一路狂跌，幾個月都恢復不過來。
注：儘管強迫合作仍然在被使用，但它在微軟已經不再佔據統治地位了。如今，各個團隊相互之間簽訂了協議（正如我下面將要講到的那樣），或者他們乾脆共享源代碼。簽訂協議的方式要好得多，但人們常常不瞭解其背後的原因，以致於忽略了一些重要的方面。這必然導致問題。這也是爲什麼說了解如何去協商是極其基本的問題的原因了。 |
逐漸長大
第二種方法在促進合作方面更加成熟。不過它也有點微妙——你跟你的合夥部門簽訂某種協議。（是的，我知道，一些性急的項目經理把這跟編寫詳細、蓄意的合同混爲一談，而那些合同常使他們的依賴方士氣受挫、最終離他們而去，不過你不必做得像那樣過火。）你們只是預先就下面一些事宜達成一致意見：你的部門和你的合作部門各自做什麼；你們各自需要從對方獲得什麼；以及如果事情不像預想的那麼發展的話，你的部門會採取什麼措施（你的合作部門也一樣有這樣的考慮）。
這種方法可以稱得上是“在滿足需要的同時發現並排除威脅，從而在各方之間建立起信任以及妥協與合作的基礎”的一種有效的協商策略。這句話很長，包含了許多不錯的概念，因此讓我們把它分解開來。
我腦子裏閃過的陰影和凶兆
當兩個部門都贊成“通過一起工作來實現互惠互利”的主意時，關鍵問題變成了如何消除合作過程中的障礙，而不是合作過程本身。但如果各個部門都像對待我們的競爭對手一樣想去戰勝對方，那上面所說的邏輯就不復存在了。
然而，對於微軟內部的各個部門，或者在我們跟我們的合作方一起工作時，真正對合作構成挑戰的，確實是如何清除一路上所有的障礙。
不要彼此傷害
合作障礙總是以威脅、需要和信任的形式出現。消除威脅，滿足需要，然後你就可以建立起信任。所有的事情都在它之下。
l 威脅。假設你想要在你的應用程序中使用Windows Messenger，但你擔心Messenger團隊的時間表跟你的不匹配，害怕他們在最後時刻的更改導致你的程序中斷或者你的項目不能按期交付。這是一個實實在在的威脅。
l 需要。你需要Messenger團隊在你的產品發佈日期前後，爲你保證一個穩定的源代碼分支。你需要他們驗證他們構建的交付物，以檢驗你對他們的應用程序編程接口的使用是正確的。
另外一方面，Messenger團隊也有一些需要被滿足——他們不想讓你給他們製造麻煩——沒有特別大的功能改動或要求、沒有額外的本地化開銷。他們還想讓你使用他們的安裝模塊，從而你不會破壞其他使用Messenger的應用程序。他們需要你預先同意按照組件的既有方式去支持任何額外的本地化開銷，並且把他們的安裝模塊合併到你的應用程序中。
注：對於合作伙伴，你要真切地理解他們的需要和顧慮，並且讚賞他們，這是成功協商的關鍵。直接瞭解彼此的處境和需求，以此來保證你們的信息同步。無需妥協，僅僅只是承認，這就能對信任的建立大有幫助。 |
l 信任。你們簽訂的合同（它可以像e-mail那樣不正式），記錄了你的團隊同意使用Messenger的安裝模塊，以及他們支持任何額外的本地化開銷的方式，還有Messenger團隊同意在你的產品發佈日期前後給你一個凍結的源代碼分支（這在SourceDepot中很容易就能做到），並且使用你的“建造驗證測試”去檢驗他們的交付成果。你們同時也說明了當你們中的任何一方對彼此間的關係感到不滿意時可以採取的措施。在兩個團隊的產品單元經理（PUM，Product UnitManager）同意了上述條款之後，你們就要像合作伙伴一樣在一起工作了。
注：“建造驗證測試”（BVT，Build Verification Test）用於檢驗一個軟件建造是否滿足某個集合的需求。在接受其他團隊的交付成果之前執行建造驗證測試是個不錯的做法。不過更好的做法是，把你的建造驗證測試交給別的團隊，以便於他們自行檢驗。那樣的話，他們知道什麼時候算是滿足了你的需求，你也不用再去處理任何不可接受的建造了。 |
在那之後，你就可以定出交付成果放置的地方和時間表，並且懇求他們幫助實現指定的應用程序編程接口。當你們都確信彼此的顧慮都將得到解決時，事情就變得容易多了。
皆大歡喜
要維持這個層次的信任，其關鍵是：保持溝通線路開放和暢通。確保兩邊的項目經理對彼此的時間表或功能改動、問題以及意外情況進行持續的交流。這並不難，但如果任何一個團隊疏忽了，那就會給項目招來厄運。
注：“哈佛談判項目”（Harvard Negotiation Project）推薦的一個記憶術是ACBD，即Always Consult Before Deciding（決定之前總是先商議）。也就是說，在沒有跟你的合作伙伴交流之前，不要做任何可能會帶來影響的決定。 |
當你以這種方式去協商的時候，通過消除威脅和滿足需要以獲取信任，你就能在生活的方方面面變得極富有效力。人們在協商的時候經常犯的一個錯誤是，在沒有聆聽其他人的顧慮之前就匆匆忙忙地開始設計解決方案。如果你過早地拋出解決方案，沒人會去接受它，因爲他們害怕被傷害。但如果你耐心地聆聽，詢問並首先解決問題，人們會出人意料地支持你的想法。
注：在協商完成之後一定要讓每個人都覺得是贏家。感覺損失肯定就不對了。要確保每個人都有贏的感覺，最簡單的方法是：把所有人都包含在贏的團體中——比如說，“這是我們的傑出設計。” |
這種合作方法不是不可思議的，它也並不侷限在跨部門的工作方面。良好的協商技能在家庭生活、鄰里關係、自己團隊內部、跟我們的合作伙伴之間都會給你帶來幫助。因此，拋開“無條件合作”吧——真正地合作起來，並且享受合作之樂！