我们应该如何面队国外抛送过来的包呢？难道就就是长期以“包工制”形式一直做下去？

　　印度一家公司软件工程师为软件企业产品开发人员讲授如何管理软件测试外包项目。

　　我们应该如何面队国外抛送过来的包呢？难道就是长期以“包工制”形式一直做下去？

　　答案是否定的。很显然，我们的“包工制”外包项目就是靠实现服务赚钱，如果长此以往，那么我们做的只是低层次的IT企业或软件企业，这种发展趋势，决不是中国企业、中国政府所希望发展趋势。

　　那么我们应该如何逐步演变“包工制”，如何借“外包”把中国的软件企业带到一个更高的境界？

　　项目外包的核心理念就是“做你最拿手的，其余的让别人去做”。因此，我们要做好外包项目，也需要从这个理念开始。我们不是没包接，而是没有实力和规模接大包。所以我们要能做好外包项目，做大外包项目，首先我们要有自己最拿手最擅长的招。印度的规模编码设计、爱尔兰的本地化都是在IT市场竞争中获胜了的接包的招。可是我们国内企业，还需要磨练，还需要更强更深的技术能力和项目管理能力等招术。

　　软件外包测试的兴起对国内软件本地化企业意味着什么？笔者认为，意味着更多的机会，争取更多软件外包国际市场份额的机会。

　　笔者试图通过多年来从事中高端软件外包工作管理的经历，以一个外包测试项目为例，总结了一些外包测试项目的经验，与读者共飨，以期达到抛砖引玉，共同提高外包行业管理能力的目的。限于篇幅，本文仅对测试外包中的风险管理和沟通管理做一个简单的整理。

　　软件测试外包特性

　　与国内一直以来比较轻视软件测试工作不同，在很多欧美软件企业中，测试（质量控制）是一件非常重要的工程工作。国内企业一般在从事软件项目开发的时候，更多的是由开发人员或者客户人员在开发完成之后才进行一些简单的功能测试工作，很少采用专业的测试团队，开发与测试的比例在4:1以上，甚至高于10:1。因此，多数中国软件的质量水准相对要低。

　　与此相反的，在欧美企业中，质量管理人员（包括事后的质量控制和事前的质量保证）的地位却高的多。测试也作为一个非常独立的职业。在IBM、Microsoft等开发大型系统软件公司，很多重要项目的开发测试人员的比例能够达到 1:2，甚至1:4。测试活动贯穿于整个开发生命周期，甚至会比普通开发人员更早介入项目。测试也是一门更讲究科学方法的工程活动，测试的种类也包括单元测试、集成测试、功能测试、性能测试、β测试、验收测试等等。

　　本文所介绍项目的客户是美国一家知名的金融业软件及服务供应商。由于金融业的特点，对于软件的可靠性、稳定性等质量要求尤其的高。该公司从2005年开始将部门开发和测试工作外包到中国地区，由笔者所在公司在北京和上海分别成立了两个团队，采用一种类似ODC（Offshore Development Center，离岸外包中心）的模式。笔者在过去一年半的时间内负责北京团队的建设和管理，从最初的一个测试人员和两个开发人员发展到现在的十几人的团队（笔者由于公司内部工作安排已经于去年下半年离开该项目）。从最初的从事简单的软件产品的安装和数据移植测试，到现在从事其核心产品的全面功能测试和自动化测试，团队的工作越来越受到客户的认可，在客户的软件开发过程中的重要性也越来越高。按照人员数量来计算，该项目的测试与开发人员的比例略高于1:1。

　　软件测试外包的风险管理

　　软件外包工作由于天然存在的地理、语言文化差别，其失败的风险几率就大的多了。所以从事外包的管理人员在项目启动之前尤其要对项目中可能存在的风险因素有一个比较全面地识别和分析。比较好的一种风险识别方法是结构化的头脑风暴法，通过集思广益找出所有可能影响到项目进度、成本、质量的因素。一个非常重要的风险因素的来源是项目计划的假设和约束，一旦项目成功所作的假设不能达到，这些就会成为未来影响项目正常进展的问题。

　　一旦识别出尽可能多的风险因素之后，需要对这些因素进行评估，并不是所有的风险都需要去规避，所以必须分析哪些风险会对项目产生重大影响，哪些风险发生的可能性非常高。根据这些分析结果排出项目中优先级比较高的风险因素（比如Top 10列表），然后针对这些风险分别找出规避的措施以及风险发生时的应对举措。

　　针对本文中提到的项目，从风险识别的角度来说，自然灾害和战争等也是被识别的一些因素，由于属于不可抗力，所以一般并不列入项目风险管理计划，但不要因此在风险识别阶段就将其排除。而时差、测试人员的英语表达能力、中美的文化差异、网络的稳定性和速度（想想前段时间的海底光缆事故）、数据传输的安全性、节假日安排这些做国内项目的时候几乎不会考虑的因素可能会是对项目的致命威胁。

　　对于每个风险都能找到一定的规避和减少损失的措施，笔者在项目启动初期花费了较多时间准备金融领域的业务知识，通过夜间在家加班与客户建立了良好的信任关系，建立了定期的会议和汇报机制，很短时间之后就确保了团队正点上下班也不会存在时差所带来的障碍。

　　软件测试外包的沟通管理

　　学习过PMP/PMBOK的朋友可能都知道这么一个事实，一个项目经理85%的时间都用在各方面的沟通交流上。很多项目出现问题都不是在技术上碰到难题，而更多的是由于沟通不畅引发的后果。

　　以前做国内项目的时候一说沟通，很多人就想到要和客户一起去吃饭喝酒。相对这种非正式的个人之间的沟通，在外包项目管理中更需要建立流畅的正式沟通渠道。这种正式的沟通渠道包括但不限于定期的电视电话会议，正式邮件往来，通过IM的工作聊天，统一的错误报告机制（Bug跟踪系统及其他）等。一个非常重要但经常被忽视的沟通渠道就是文档，尤其是项目计划，不少项目经理都只是把项目计划当作前期不得不完成的一个文档，到项目执行过程中即使再去阅读也只是关注进度表部分。其实项目计划包含了众多内容，除了进度表外，还包括上面提到的风险管理计划，以及项目的范围界定和各种项目管理流程（包括需求变更管理流程等），它在一定意义上是合同的一部分，所以及时的更新、审核（Review）和批准（Approval）不仅仅对项目的监控非常重要，对于开发方来说也是很好的法律上的保护。

　　正式的沟通还有一点非常需要注意的就是要保证良好的反馈机制。我们都知道信息在传递的过程中会受到噪音的干扰，尤其是在多次传递的情况下更容易失真。所以在建立沟通渠道的时候要建立起方便有效的反馈途径。对于重要的文档，一定要有合适的审核和批准机制。更为有效的一种机制还是利用类似于Mercury的Quality Center这样的工具，由于其内置了工作流，所以任何的问题都必须按照一定的流程进行处理，避免了因为工作忙而忘记了一些重要工作的可能。

　　最后需要提醒的一点的是，要保留一切沟通过程的证据。美国的金融监管部门对金融业内部的所有电子邮件要求保留至少5年以上以备检查。在项目中证据的保留一方面是对自己权益的保护，另一方面也是保持完整的沟通记录有利于后期出现问题的顺利解决。