根據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支持開發隊伍建立一個協同工作的穩固基礎的需要。
