如今，大家都在跨部门合作上空口说白话。我们的员工调查结果显示，几乎所有人都认为我们应该更好地合作，但几乎没人真的去那么做。哈，问题究竟出在哪里呢？
可能是部门之间有冲突吧？冲突的交付日期，冲突的版本，冲突的功能，冲突的需求，冲突的优先级、目标、客户群、业务模式、行销信息、行政方向、预算约束、资源。喂？！？大家注意了，大部分团队在他们自己部门内部的合作都麻烦重重，更别说跟其他的团队一起工作了。
是的，“不过，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（决定之前总是先商议）。也就是说，在没有跟你的合作伙伴交流之前，不要做任何可能会带来影响的决定。 |
当你以这种方式去协商的时候，通过消除威胁和满足需要以获取信任，你就能在生活的方方面面变得极富有效力。人们在协商的时候经常犯的一个错误是，在没有聆听其他人的顾虑之前就匆匆忙忙地开始设计解决方案。如果你过早地抛出解决方案，没人会去接受它，因为他们害怕被伤害。但如果你耐心地聆听，询问并首先解决问题，人们会出人意料地支持你的想法。
注：在协商完成之后一定要让每个人都觉得是赢家。感觉损失肯定就不对了。要确保每个人都有赢的感觉，最简单的方法是：把所有人都包含在赢的团体中——比如说，“这是我们的杰出设计。” |
这种合作方法不是不可思议的，它也并不局限在跨部门的工作方面。良好的协商技能在家庭生活、邻里关系、自己团队内部、跟我们的合作伙伴之间都会给你带来帮助。因此，抛开“无条件合作”吧——真正地合作起来，并且享受合作之乐！