有时好象IT分裂成了两个敌对的阵营。一边是致力于稳定性的基础架构工程师，他们要保护自己的环境。另一边是开发者，他们经常努力去发现独特的、更棒的方法来达到他们的目标。这两个阵营之间的斗争是如此的激烈，以至于连最忙碌的经理都开始注意到这点。
　　一个失败的项目

　　我参加的第一个大项目是帮助一个学校把一个基本财务信息系统从一个平台移到另一个平台上。我作为基础架构小组的解决问题专家以及配置专家。这个应用很陈旧，开发团队还面临着升级它，以符合该学校目前以及将来的需求的挑战。

　　事情的开始很正常。我们架起了自己的服务器，配置路由器，并在搭建IP子网络中找到了乐趣。当基础架构团队忙于进行稳定性测试的时候，开发者们却退到他们满是灰尘的房间和黑暗的角落里去。他们在深夜工作。

　　该项目进行了一个月以后，这两个团队除了在我们每周的例会之外，就已经不说话了。进行了两个月的时候，这些周例会也开始变味了。基础架构团队进行最后的配置并完成了基本的稳定性测试。开发团队每周到我们这来，带来新的变化，补丁和他们想放在服务器上的程序。

　　双方的脾气都开始爆发。从我们的角度看，我们不理解为什么开发者们不能接受我们为他们测试的，所有的伟大的事情。对于他们来说，这些开发者不能理解我们为什么如此顽固。他们只是想要帮助客户。

　　一天下午，事情发展到了顶端。一个开发者走进测试实验室，在桌上放了一个软件，并宣布要我们在当天安装并测试这个软件。我告诉他我们要在别的时间来进行这件事--也许是下个月的某个时候，我有我的方法。他很不高兴。事情从那个时候开始就有些失去控制了。我们面对面地站着，向对方大声嚷嚷。

　　我们的客户协调人刚巧在我们两个扭打在一起的时候走进这个房间。他关上门出去了。两个小时以后，那个开发者和我都被踢出了那个项目。但是，在我们走了以后，那个项目里的两个团队之间的情况没有任何改善。事实上，情况越来越糟，最后导致了整个项目的失败。

　　发生了什么？

　　除了我自己的不够职业的行为，这个项目还受到一个根本问题的困扰。基础架构和开发者这两个团队之间的关系制造了大量的紧张气氛。我的大声嚷嚷和那个开发者的失态只是表象，而不是问题的实质。辨认出并理解这个问题成了我在等待下一个新项目的时候关注的焦点。

　　在回顾了我们从事的工作类型之后，我认识到基础架构和开发对于世界持有相矛盾的看法。这种矛盾不可避免地导致了两个团队之间的战争。

　　基础架构团队关注的是能力和风险管理。他们的目标通常包括诸如“快速配置”，“没有麻烦的安装”以及“快速的问题解决方案”等内容。经理们通过检查当机时间和问题解决方法来衡量基础架构。为了达到这些目标，有天赋的基础架构人员努力创造稳定，低风险，高可管理性的环境。当变化让他们难以达到目标的时候，他们就会有些抗拒风险。

　　程序员们则有着完全不同的文化。他们的目标包括解决商业问题，改造现有的程序来解决新的问题，并思考新技术的可行性。衡量他们的标准是他们能够成功承担风险的能力和愿望。风险越大，他们能解决的问题越大，他们就越有成绩。

　　这种讨厌风险/喜欢风险的不同态度解释了我每天从基础架构和开发团队那里听到的评论。基础架构团队通常把程序员们看成是肆意妄为的牛仔。程序员把基础架构团队当作是庸俗古板的人，并抱怨说他们总是整天忧心忡忡。这两者之间的矛盾是显而易见的，所以这个问题就不是我们怎样才能阻止这两者间的战争，而是我们如何才能利用它，并从中获得最大的收益。

　　利用紧张

　　从实践的角度，我们不能够改变这两个团队之间的紧张气氛。冒险者和反对风险的人总是会起冲突。但是还是有可能利用这些不同的观点并让他们能够在理智的环境中一起工作。

　　最简单的办法是指定两个团队中最外向，喜好交际的人作为同另一个团队的“联络者”。联络者参加对方团队的会议，学习去了解对方想要什么以及对方如何处理问题。这在两个团队之间创建了一点相互的理解。同时保证了他们之间非正式的沟通。

　　一个更复杂的方法是建立基本变化管理。建立起一套可以接受的方法和时间让两个团队坐在一起讨论变化。在这个会议之外，建立一些非正式的头脑风暴会议来让两边关键的人表达自己的意见。在正式会议沉闷的气氛之外，非正式的交流使两个团队能够建立共同的目标。

　　快速前进

　　几年以后，我发现自己再次参加了一个项目，该项目中也包含了大型的开发同基础架构团队。当敌对的阵营开始形成的时候，我利用自己作为高级基础架构管理人员的身份，建立了一个变化管理流程。在第一次会议上，开发者们对基础架构人员进行了嘲笑和抨击。会议结束后，我同软件团队和我身份相似的一个人进行了一个走廊会晤。我们同意作为另一个团队的联系人。虽然这样做花费了我不少时间，我从参加开发会议获得的预先警告和信息让变化管理流程顺畅进行。这个系统也帮助开发者们认识到并不是所有的基础架构团队的成员都仅仅是想妨碍他们的工作。那个扮演联系人角色的开发人员也告诉他们的人基础架构团队所需要处理的风险，以及为什么我们那么反感突然的变化。

　　在我们的会议中，我们建立了一个变化方法（变化的数量，变化的范围以及变化持续的时间），它能够帮助我们清楚地交流对于环境必要的改变。随着时间的推移，我们建立起了一套通用的语言，并对彼此最终能够帮助客户节省时间和金钱的方法表示感激。在第一个项目中，我们没有能够理解这两个团队之间根本的不同。而在第二个项目中，我们使用了正式和非正式的方法来利用这种不同，以产生更具创新、更有效的解决方案。