软件外包的困境

高层管理人员肯定清楚在《新劳动法》实施后正式员工的用人成本大大增加，那这么做的苦衷就是：企业自身的管理水平和管理能力不过硬，工作无法“包出去”。而且，工作要能够“包出去”，还要求企业的系统（软件、硬件）的架构具有开放性openess、可适应性flexibility、模块性 modularity。“包不出去”，说明企业在技术架构和管理水平上遇到了双重瓶颈。

一、管理瓶颈

IBM、SAP看到了机会，向企业推销自己的研发项目管理解决方案和工具，或者是人力资源关系全生命周期管理软件等。

另一方面，除了上述的重量级解决方案，一些轻量级的、敏捷的软件开发过程也大行其道。成本压力大的中小企业，推荐两个web 2.0的项目管理服务网站：

http://www.teamworklive.com

http://www.projectstudio.com

二、技术瓶颈

整合是软件行业经久不衰的一个主题。

很多公司的工作之所以“包不出去”，不是因为管理水平跟不上，这其中我知道的有达到CMM3的企业，而是因为：

1.企业的核心关键系统不具有模块化、插件式开发的架构，在技术上就不存在这种可能性，没有清晰的封装完善的API接口。

从企业管理层不求有功、但求无过的心态，也不愿意出现万一出了问题，却界定不清责任的情况，究竟是核心系统的Bug，还是外包开发的插件造成的Bug？

2.即使是相对独立的系统，外包开发完成之后，或者无法方便地实现功能扩展，或者扩展就必须采取某些类似hack code的方法，可能引入潜在的风险。

解决信息孤岛、解决IT系统的异构性，使得IT系统可以互联互通，新系统的开发、旧系统的功能扩充可以有序、低成本地实现，这也是众多解决方案提供商争相自卖自夸的一个领域，首字母大写缩略语层出不穷、乱象纷呈：EAI、ETL、EII、MDA、MDI、SOA、BPEL……

在Web开发领域，受facebook开放应用的刺激，open api、portable data、open social graph、open id、cloud computing、utility/ubiquitous/on demand等概念密如夏日傍晚野外的蚊蚋袭来。

坦白说，我以前做过大量的系统整合类项目，其中典型的一个项目整合了140多个不同的IT系统，项目金额3800万。但如果让我自己给这类项目评估，勉强得 C 而已。

身边的很多朋友开始研究各种插件机制，Eclipse OSGi这样一个精巧的有些过度工程（Over Engineering）之嫌的框架从05年以来在多次偏Java的技术聚会中被提起。Drupal、eGallery2、WordPress的模块扩展机制也有一些偏PHP的朋友在孜孜不倦地探究学习。

未来的技术人员，走管理路线的将沿着“广”的方向发展，在模块/插件、可扩展性、适应性等领域；走技术路线的将沿着“深”的方向发展，在算法、高性能等领域。

结论：相对来说，做好软件外包项目，解决管理瓶颈易，实现开放架构难。

源文档:http://news.csdn.net/n/20080215/113585.html