我们先来谈一下协作的需要。几乎所有大中型企业都为拥有分布式团队而引以为豪；对于很多小公司来说，情况也是如此。由于公司员工分布在全球的不同地方，因此迫切需要跨越地域界限进行有效的协作。

    以前，我曾参与一个简单的项目，它是由设在欧洲和美国的小型团队进行管理的。项目启动后不久，人们必须通过电话、联席会议、电话会议等方式与距离很远的同事进行沟通来做出决定，这种情况非常明显。传统的协作工具（如源代码管理系统）是必不可少的，但仅仅靠它们还无法有效地提高团队的生产率。

    例如，请考虑以下情况：欧洲的团队在项目的某一部分遇到问题，而该部分正在美国进行开发。仅就通过电子邮件并随后通过电话在代码中找出根本原因这一项任务，平均找到每个问题就需要花费一天半的时间，更为重要的是成本上相当于需要四人天的时间。您可以算一下成本。

    这说明了什么问题？问题主要出在代码交流的方式上。毋庸置疑，您可以通过电子邮件进行非常详细的交流，但是电子邮件的速度可能会非常慢，尤其是当您需要快速解决问题时。IM 确实更快一些。可是，试一试在IM 上大段地填充代码，您就会立即发现这是一项多么繁重的工作。

    最理想的方法是：相关人员都坐在同一张桌子旁共同解决问题。在某些紧急的情况下，这是唯一可行的办法，但我们不得不将金钱和时间花费在让工程师在大陆之间飞来飞去，从而降低了底线。我举这个例子是想说明，既然在某些情况下分布式团队必须面对面地进行交流，那么获得有效的协作工具以减少出差次数并增进团队交流就理所当然成为头等大事了。

    请不要误会我的意思。我很清楚，当我们试图解决协作方面的问题时，必须遵循流程规范和定义。此外，即便是最好的协作工具，也无法解决处于不同大陆的团队之间由于有时差而产生的问题。尽管如此，我仍然坚信团队成员在面对各种制约因素时，协作工具可以让团队成员彼此之间更好地进行协作。

协作的优点
 

    在人员日益增多而空间却逐渐缩小的世界中，与将人员召集在一起最为接近的方法是虚拟选项，即联机共享开发环境。当然，您可以使用几个桌面共享工具来实现此功能，但是无法使用其中的任何工具单独地逐步执行同一个源文件。Java Studio Enterprise 通过提供两个用于协作的重要功能，解决了提高团队生产率的问题：

    可识别代码的 IM，它保留了语法着色和代码格式设置功能，因此团队成员（所有称职的源代码编辑人员）可以像平常一样查看代码。

    实时文件共享，可以使用该功能与不同位置的人员共享单个源文件或整个项目树，以便更快地解决问题、改进知识传授的方式并提高质量，所有这些都有助于提升员工士气并增加利润。
    通过协作开发，IT 组织可以对专家管理和分配进行更好的控制。主题事项专家通过使用支持即时、实时文件共享的工具，以虚拟方式检查问题来帮助多个远程团队，从而可以更快地解决问题。协作开发还会对其他用例产生影响，如代码检查、操作实验和培训，这会进一步扩大它的优势。研究表明，在很多情况下，协作开发可以将用于调试问题和完成项目所花的人天数减少一半以上。

    因此，Java Studio Enterprise 中的协作开发功能对开发人员和管理人员同样具有很大的吸引力也就不足为奇了。在工作环境中，有什么比提高团队生产率以及相应地持续增加收入和利润更诱人的呢？

Sun 所发挥的作用
 
    Java Studio Enterprise 现在已迈出了坚实的第一步，将协作开发的优势带给了企业团队。但是，这仅仅是开始。我坚信，由于协作开发与开发人员生产率之间存在固有的联系，因此，社区必将大大扩大其目前的应用范围。