根据The Standish Group International， Inc.的研究报告，40%的软件开发项目在完成前被取消，33%的项目延期或超支。如果像这样搞建筑项目，您能够想象一下纽约城会变成什么样子？

　　协同是关键

　　从开发环境到版本控制，你常常会走过又一个循环：采购工具，使用培训，围绕着工具使用建立内部开发过程，日常应用等等。希望在合同到期时能够顺利完成并且没有超支…

　　让我们来问这样一个问题：下一步是什么？

　　在你让开发小组提高了一点点效率之后，在你配置了开发工具之后，你仍然需要保持竞争力，下一步改善那里能够获得大的生产力？

　　我们要求你看一下目前你周围的信息组织，你一定能看到不同的开发小组，同时你也能够发现其它许多技术上的协作者，如文档、外部资源、客户、设计人员等等。你将发现不同的开发小组的数量在增加，麻烦也在增加。你还能发现合作者分散在不同的部门或不同的地方。

　　当你看到这一切时，相信你会认识到项目组织中存在的噪音和混乱带来了沉重的经济负担。你将意识到这是下一步提高生产力的突破点，不是其它的技术工具，也不是下一个更快的编译器。

　　下一个效益增长点将来自管理，简化技术协作，使不同的小组以一种更快速而简单的方式共享工作中的相关信息，从而降低“项目组织中的噪音”，而且使的小组不会被拖住后腿。换句话说，你的下一个效益增长点将来自实现你的信息组织中所有成员之间的协同工作。

　　“我只需要版本控制，或许是软件配置管理…

　　何必要协同呢？”

　　获得协同的动机依赖于企业内信息组织的个体：应用开发组（如上图中的Tom），应用开发管理（如Ann）和技术协作者（如文档、帮助平台和客户等等），他们参与不同的软件活动，所以会有各自的看法。

　　例如，让我们考虑一下Tom，作为软件开发组长，他可能在应用开发和维护领域有特长，因此自然会倾向于采用专门技术，如版本控制等。那么Tom是否需要技术协作？

　　从哪儿提高生产力，版本控制和软件配置管理通过加强日常开发环境的控制，很快得到了大家的认可。但是它们能进一步提高生产力吗？

　　许多已经使用了版本控制和软件配置管理工具和软件组织，很快发现生产力的提高比预期的要低，下面列出了其中一些原因：

　　不同的项目组使用不同的工具，降低了效率。但搞统一是不合理的，违背自然规律。

　　不同工具之间有“隔阂”，难于重用数据，也减少了项目组之间的交流。

　　已有的版本控制工具不能支持远程用户，或者性能明显退化（如一个基于文件服务器的工具，当在WAN或Internet上使用时，会变得非常迟缓）。

　　考虑到上述因素，很明显Tom肯定会对技术协作发生兴趣：

　　建立在版本控制和软件配置管理之上，提供对信息技术资源的准确访问。

　　通过无缝访问不同的版本控制工具促进代码共享。

　　从任何地方访问（LAN/WAN/Internet/WEB），改善已有的版本控制工具

　　从其它平台（通过统一的JAVA客户端），扩展垮平台的代码共享和重用。

　　提供一个具有高度伸缩性的现代化体系结构，使得将工具扩展到其它领域和功能范畴成为可能。

　　StarTeam满足所有上述需求，它具有：

　　与PVCS和SourceSafe的互操作性，完全的地理位置独立性，客户/服务器体系结构，为Internet和WAN开发环境特别优化，

　　能够运行在任何JAVA平台上的统一的客户端应用。

　　更重要的是，StarTeam支持开发队伍建立一个协同工作的稳固基础的需要。