1、软件外包项目与需求工程 作者结合自身工作实践，深入探讨了在软件外包项目管理过程中，如何有效地进行“需求工程”的相关工作，从而保证承包商获取完整并符合用户真实意愿的项目需求，以及减少因需求变更失控带来的可能危害。 一、需求的重要性 何为“需求”？广泛的讲，软件项目中的需求源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了软件产品“必须或应当”做什么。 从重要性来看，软件项目中“需求、设计、编码、测试”四者哪个更重要？这个问题不好回答。四者都是软件开发过程中必不可少的环节，光做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏影响。若从
2、风险管理的角度讲，我认为需求开发和管理是最重要的环节。因为需求是产品的根源，需求工作的优劣对产品影响最大，而且会带来最大的返工成本。举例来说，软件项目开发过程就像一条河流，如果河流的源头（需求）被污染了，那么整条河流也就被污染了。 开发软件系统最困难的部分就是准确说明开发什么。最困难的工作是编写出详细的需求，以及包括所有面向用户、面向机器和其他软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后的弥补也极为困难。 二、需求工作的问题分析 电力行业这几年正迎来信息化建设新浪潮，每个电力企业每年都有大量的软件项目需要开发，一些项目是由本企业自主开发，另外很大一部分是外包给其他软件公司
3、进行开发，我们在这里可以将其称为“软件外包项目”。从我个人的了解和切身体会来看，国内许多电力企业的软件项目开发状况并不理想，很多项目进度反复延期、大量的返工、产品质量总是不能满足项目预期和用户的要求。而作为信息化建设的主流模式，软件外包项目更会因为跨地域、沟通不到位、承包商不成熟、组织利益不同等原因而产生更多的问题。 分析导致软件项目失败的众多原因，其中最主要的一条就是项目的开发方和用户方对“需求工作”不重视或缺少一套有效的方法论。一方面开发方的很多人员并不知道如何把需求工作做好，而另一方面用户方往往也忽略需求，不能积极提供完整详细的需求说明，而且很多需求确认或评审工作也是草草了事。 为了改进
4、软件项目以上所述现状，绍兴电力局从2004年起和上海沙迪克软件有限公司一起就软件外包项目开发管理过程进行规范和整改，并取得了非常理想的成效。 我们首先来了解一下软件外包项目中需求工作存在的种种问题。 2.1 用户说不清楚需求 用户说不清楚需求是普遍现象，这是让开发商非常头痛的问题。这种情况下，如果软件承包商以此为借口草率地对待需求工作，会连累整个项目的开发。无论什么原因导致用户说不清楚需求，承包商都必须设法搞清楚用户的真实需求，这是他们的职责。 2.2 态度问题 相当多软件承包商的开发人员习惯于被动地对待需求工作。每当遇到麻烦、挫折时，总是发牢骚，并找出用户的很多问题。这是普遍现象，并不是承包
5、商懒惰所造成的，而是不正确的观念误导了他们。 很多承包商错误地认为： 需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求或者经常变更需求，因此引起的问题是用户造成的，应当由他们自己负责。 软件承包商应该让自己的开发人员了解到：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。 2.3 双方对需求的误解 对用户描述的需求，不同的人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的开发人员错误的开发。不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求，因此需求文档和评审工作
6、必不可少。用户经常变更需求 需求变更通常会对项目的进度、成本、资源产生很大的影响，这是软件承包商非常畏惧的问题。很多情况下用户方也具有不可推卸的责任，如：在项目初始阶段不愿意认真地整理需求、确认需求，总是想着“以后反正可以修改，以后再说 ”，这样做的结果可想而知，大量的需求变更，频繁的返工，导致承包商丧失工作激情，以致项目最终不了了之。 从以上列举的几点来看，要减少因为需求导致项目失败的几率，需要软件外包项目的双方好好反省，认真学习需求工作方法，建立一套有效的软件项目需求开发管理过程体系和方法。 三、 需求工程的概念 为了进行有效的改进，我们首先需要划分并定义清楚需求相关工作的主要内容及其目标
7、。 上述阐述中多次提到的“需求工作”，指的是所有与需求直接相关的活动，业界术语又称为“需求工程”。需求工程中的活动可以分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构如下图所示。需求开发 的目的是通过调查和分析，获取用户需求并定义产品需求。需求开发过程域有3个主要活动： 需求调查 需求调查的目的是通过各种途径获取用户的需求信息，产生用户需求说明书； 需求分析 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。 需求定义 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计
8、工作。 需求管理 的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。需求管理过程域有3个主要活动： 需求确认 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合作效果。 需求跟踪 需求跟踪是指比较需求文档与后续工作产品之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 2 需求变更控制 需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。四、 绍兴电力局进行“需求工程”改进的实践探讨 4.1 甲方需建立合理的项目组
9、织结构 为了有效地进行需求开发和管理活动，我局根据企业自身特点配套建立一套职责清晰、分工明确的项目组织结构。其中对于需求开发和管理工作，我们专门设置了“甲方需求联络员”这样一个岗位，负责用户需求的提出，以及向软件承包商进行用户需求的解释工作，如图。“甲方需求联络员”岗位的设置，保证了甲方有足够的时间和人力资源用于用户需求的获取、整理、解释和确认工作，同时又做到了需求归口统一，最终理解的一致性。对于软件承包商而言，“甲方需求联络员”的设置大大减少了承包商需求分析员组织协调的时间，便于最高效地获取用户的真实需求。 4.2 从合同和项目计划开始进行改进 软件承包商和用户的合作关系对需求而言是至关重要
10、的。因此，我们在软件外包项目的合同和项目计划阶段，就要求明确双方的合作关系，主要体现在：责任到人、职责明确、过程规范。 甲方（发包方或用户）： 明确需求联络员、典型和关键用户； 项目前期尽可能从自身理解出发，整理出一份完整的用户需求原始文档；要求积极配合乙方需求分析员进行采访，在不泄漏机密的前提下，尽可能地回答他们希望了解的问题；要求积极配合乙方需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿；不轻易变更需求。如果需要变更需求的话，按照“需求变更控制规程”执行，而非强迫承包商接受；甲方将派专人（如：甲方SQA）负责对与需求工程有关的双方活动定期进行检查，如果发现问题向双方提出并
11、跟踪其改进结果； 如果条件允许的话，建议承包商为甲方举办有关需求工程的培训，以减少今后的摩擦，以使需求相关人员明白需求的重要性，以及忽视需求的危害性，从而使甲方积极友善地参加需求工程中的各项活动。 乙方（软件承包商）：要求乙方派遣合格的需求分析员和相关人员；要求乙方采用用户熟悉的语言和甲方提供的统一格式来描述需求，如一般情况下会要求乙方提供用户需求说明书和产品需求规格说明书两篇需求文档；如果甲方想变更需求，有权要求乙方对该变更将产生的影响进行真实可信的评估，以便甲方确定是否变更需求；要求乙方完全遵循合同和项目计划中约定的需求开发和管理过程进行工作。 4.3 规范软件承包商的需求开发活动 为了确
12、保承包商获取项目的真实需求，我们对承包商的需求活动进行规范并进行定期的跟踪，要求他们按照规范执行，并定期提交相关工作产品以便于我方进行检查。具体包括：需求开发活动 活动内容和相关工作产品 1. 用户需求调查 1.1 准备调查 确认关键和典型用户、确认调查方式、准备调查问卷、确认调查对象。 1.2 调查与记录 调查用户需求，随时记录调查过程中所获取的需求信息。 1.3 分析需求信息 分析已经获取的需求信息，消除错误，归纳与总结共性的用户需求。 1.4 撰写用户需求说明书 按照指定的文档模板撰写用户需求说明书，主要内容包括：产品介绍、用户群体的特征、产品应当遵循的标准或规范、描述产品的功能性需求、
13、描述产品的非功能性需求，如用户界面、软硬件环境、质量等需求。 2产品需求定义 2.1 细化并分析用户需求 对用户需求说明书进行细化，以便产生详细的产品需求。此外，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。 2.2撰写产品需求规格说明书 按照指定的文档模板撰写产品需求规格说明书，主要内容包括：产品介绍、用户群体的特征、定义产品的范围、产品应当遵循的标准或规范、定义产品中的角色、定义产品的功能性需求、定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求。 另外，为了更好了解每个需求的是否清晰、与其它工作产品的对应关系，并便于跟踪后续的完成情况，我们要求软件承包商为需
14、求进行编号，并能够通过一张索引表（如下表所示）了解以上的相关信息。 需求编号 功能 子功能 需求优先度（高、中、低） 对应的用户需求 备注（依赖关系和清晰状态等） Function A Function A .1 Function A .2 4.4 规范和改进需求评审活动对需求文档进行评审是保证项目质量的关键活动。我们将评审的方式分为两类：一类是正式评审，主要由用户方和承包商共同参与的评审；另一类是非正式评审，主要是软件承包商内部的评审。 对于承包商提交的用户需求说明书和产品需求规格说明书，一般情况下我们都要求至少执行一次正式评审，并安排在我方所在地进行。对于非正式评审，我们都要求由承包商自己
15、内部进行，但我们会跟踪和抽查他们的评审过程和结论，希望他们能事先排除基本的错误，明确主要问题，以提高后续正式评审的效率。对于正式评审活动，往往会伴随很多问题的产生，并严重影响了评审工作的执行。针对这些问题，我们从自身实践中摸索出一些比较好的解决办法，说明如下： 评审工作“虎头蛇尾” 需求评审的确乏味，刚开始评审的时候大家都比较认真，往往越到后面越马虎，特别是需求文档很长时，几乎没有人能够坚持到最后。针对以上问题，我局在自身的需求评审工作中通过以下几点来进行改进：1、评审工作事先有计划，并做好内容分工。每部分内容都有专门的人员进行负责，以减少每个人的阅读工作量。2、作者就评审文档的主要问题点事先
16、和责任人进行沟通，明确需要会上确认的主要问题。这样有助于提高评审效率，尽量减少评审时间。3、会议主持人事先强调需求评审工作的重要性，以提高参与评审人员的注意力和积极性。 评审工作量大 需求评审的人员可能比较多，有时候让这么多人聚在一起花费比较长的时间开会并不容易。其实没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行，这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。 评审时容易“跑题” 评审时如果会针对一个问题进行激烈讨论，而且会越扯越远，结果评审会议变成聊天会议。此时，一方面主持人应当控制话题，避免大家讨论与主题无关的东西；另一方面，对于有些
17、问题“如何做，如何解决”这样的讨论，要做到适可而止，不要过多地谈论细节，可以放在会后进行，这样有助于节约多数人的时间。 评审时过多的“争论” 很多评审会议上，往往会因为某个问题难以达成共识，并分成“几派”各据一方。此时，会议的主持人应该参与进行协调，建议大家站在他人的立场上进行思考，这样一般会很快找到适中的解决办法。 4.5 要求承包商建立需求跟踪报告 在我们对承包商的开发过程进行跟踪和检查的过程中，我们经常需要了解“产品需求是否反映所有用户需求？”、“设计是否反映了产品需求？”、“需求是否有相应的测试用例进行测试？”等等这些问题，并且承包商只有很好地处理了以上问题才能充分保证未来软件产品的质
18、量。为此，我们会在一些重要项目中要求承包商及时建立“需求跟踪报告”（如下表所示），这样有助于后续我们执行相关工作产品的审查工作。 序号 需求编号 需求文档（版本、日期） 设计文档（版本、日期） 代码（版本、日期） 测试用例（版本、日期） 缺陷 标题或标识符，说明 标题或标识符，说明 文件名，标题或标识符，说明 文件名，标题或标识符，说明 缺陷编号 001 FR-A-001 7.A.1用户登录成功 XT-A001-01 XT-A002-02 4.6建立需求变更控制过程 很多项目需求发生若干次变更似乎是不可避免的。很多情况下，是由于用户和承包商对需求的了解越来越深入，原来定义的需求可能存在错误或不
19、足，因此需要变更需求。 提出需求变更的动机是好的，但管理不好往往会带来很严重的负面影响，很多情况下会发生“变更带来的好处远远小于因此导致的坏处”，如：原先好用的功能因为个别人的习惯问题被修改掉，导致大多数人难以使用；个别需求变更，导致开发工作大量返工，严重影响后续的测试工作，导致项目质量低下甚至延期。 为了有效地管理和控制需求变更，我局建立一套规范的需求变更控制过程，并做到： 需求变更提出 用户或承包商提出的变更均采用规定方式进行提交（如：需求变更控制报告或沙迪克ALESH系统需求管理功能），这样便于专人集中统一管理。 需求变更分析 对于提出的重大需求变更，要求承包商采用规定方式做出详细的影响
20、分析，包括：变更内容、变更需要耗费的工作量、对项目交货期的影响等内容。这样便于项目双方人员了解变更带来的相关影响，并以此作为变更与否的重要依据。 需求变更审批 对于需要进行的重大变更，需要承包商和甲方共同认可，并签字确认。 五、 结束语 需求问题是软件外包项目成败的关键因素，以上是绍兴电力局在长期的实践过程中，借鉴和总结出的一些成功需求开发和管理方法。在整个改进的过程中，我们遇到了很多的实际问题，但在单位领导和上海沙迪克软件有限公司咨询顾问的大力支持下我们一直坚持过来，找到了很多很好的解决办法，并在实践中取得了很好的效果。今后，希望能够和广大软件项目管理人员一起进行探讨和研究，为我国电力行业信
21、息化建设摸索出一条能够适合电力企业特点、简单而又具有实效的改进道路和实践方法。 /外包软件项目管理经验总结建立良好合作模式外包开发的软件不能达到企业的质量要求，我们往往会在第一时间把罪过推给外包商。但实际经验告诉我们，很多失败的原因是企业本身没有提供一套完整的软件系统规格说明、没有跟进开发的进度、没有定期与外包商沟通与协调、没有在开始时建立好质量指标和测试流程或者没有做出适当的技术和开发环境的评估。但最重要的一点，是没有在决定软件外包时处理好双方合作模式与关系的建立。千万不要认为软件外包可以减少企业的管理时间。相反，外包项目有时需要双倍的管理时间。在我们决定外包软件开发的时候，我们首要决定是整
22、个应用系统的开发由外包商承包，还是只有部分应用模块的程序交由外包商编写。前者需要管理整个外包项目的生命周期，跟企业内部软件开发的管理没有差异，只是开发的地点、环境和资源比较陌生而已；后者则需要了解企业本身是否能提供优质的规格说明、是否能够提供外包商所需的质量标准和测试数据、外包商是否有类似企业本身的开发平台和环境，以及外包商的技术资源水平是否与企业内部开发时所需的技术指数相符。明确自身所需和服务要求，是决定外包项目的先决条件。选择适合的外包商，并不能单以服务价格来做最终决定。优质的服务需要付出较高的代价。企业应根据自身对软件质量的要求来决定服务的代价。按照国际企业的衡量指标，外包投入比本身开发
23、的净投资（以各技术员工的基本薪资为标准，并不包括企业对员工所提供的福利、假期和奖励计划等开支）多付1520。也就是说，如果企业本身开发需要30万元的话，那么合理的外包服务价格大概是34万元到36万元。既然外包不能立竿见影地带来经济利益，为什么还要外包呢？最主要的原因是企业在项目完成后不需要继续照顾这批开发人员，不需要为这些开发人员提供福利条件。外包费用是一次性的营运开支，不像雇员薪资这样成为企业的长期营运成本。假如企业有些一次性的大型项目需要马上启动，但缺乏足够的资源，或者企业本身没有相应的技术人员来执行的时候，外包不失为一个可行的解决办法。如何进行外包项目的管理一些项目经理往往认为外包开发项
24、目与企业内部开发项目的管理没有多大分别，唯一不同是外包项目需要更多时间去沟通、协调、跟进和监控。总体来说，这种想法是对的，但事实上外包项目的管理比企业内部开发项目的管理更复杂，担负更大的风险，需要更紧密的进度和质量监控。（相关文章：如何控制信息技术外包的风险？）保障沟通内部开发项目所需人力资源大致分为两组：一是技术人员，另一组是配合技术人员的业务人员（他们是所建信息系统的潜在用户）。外包项目除了需要部分技术人员和用户群体参与外，更增加了一组外包商的资源。有些外包商更会指派一名联络人员负责联系与协调，而他们的技术人员只在后方负责项目的开发。这种运作模式要尽量避免，因为外包商指派负责联系的人员往往
25、是业务人员的背景，对技术的细节不能全面把握，把有关信息传达到技术人员的时候便会有所差异。所以我们的首要任务是让外包商明白负责项目联系的人员必须是开发小组的主管。这名开发小组主管是直接参与开发项目的主要人员，如此才能够有效地进行沟通和监控。做好计划项目经理首先需要做出一个详细的、完整的项目计划，并在计划中详细地列清楚每一件工作需要哪方面的哪些人力来共同执行。在计划中的每一个进度都需要进行确认才能继续。例如外包商在完成系统分析后，需要把分析的结果让客户理解，好让企业能够确认外包商对整个系统的理解和分析与企业本身对项目的需求和分析达成一致，这样才能让外包商进行其后的模块设计。不然设计出来的模块组合便
26、有可能与企业的需求不太一样，存在质量和最后上的差异。这些差异也将会引发企业将来在系统维护、更新、增加功能模块、升级、集成等各方面的严重问题。避免延误要避免项目发生延误，计划中要预留足够的时间来进行上述确认工作。由于双方工作地点的缘故，原本只需一天的确认会议便可能耗费两天或三天的时间来完成。议程中所达到的共识也可能需要时间来让外包商做出适当的修改才能让企业正式确认。也只能在正式确认后才能够进一步继续接下来的工作。如果没有预留足够的时间用于协商，当一个项目经过七八个确认会议之后，也许已经延误了一个月的时间。/IT外包项目管理杂谈2005-9-21 22:52:33【作者】畅享网 摘要：“IT国际化
27、，向外走出去”在我国已经被提出好几年了，而“外包”被许多国内IT精英认定的“IT（软件）国际化”的跳板，随之而来的IT外包项目管理也就成了讨论甚至争论的焦点。本文从宏观分析国内“外包”项目现状入手，分析目前国内“外包”项目的痛痒之所在，然后进一步从五个方面阐述了如果针对目前的“外包”项目的特点，对不同的“外包”项目类型如何进行项目管理。 关键字：外包，外包项目，外包项目管理，包工制，外包项目服务一、当前国内IT外包市场状况来自IDC的数据显示，2003年中国IT外包服务市场比上年增长了34.2%，首次超越3亿美元的数字关口达到3.18亿美元，虽然目前外包市场占整个IT服务市场的份额还不到10%
28、，但是未来五年将保持着强劲的增长态势，年均增长可望达到44.2%以上，超出IT服务业平均增长率近一倍以上。由此可见,外包市场潜力巨大,不仅是规模大,而且稳定,利润空间也远较国内IT销售要丰厚的多。就那软件业来说，中国拥有巨大的软件时常，是世界公认的软件开发资源，Gartner研究公司预测，在2007年到2010年期间，中国将成为世界上最大的外包市场。据去年的数据报告，各国发包量中美国发包量亿美元；日本发包量亿美元；印度软件出口亿美元；中国软件出口亿美元。因此目前国内一些大的软件开发公司都在尝试做外包。比如对日软件外包市场的“井喷式”发展，让我国企业欣喜若狂。对日软件外包，已悄然成为产业界的一种
29、时尚。目前，国内软件公司所接的包多数是非核心模块的设计编码或只管编码或进行本地化等，另外还有一类包就是软件测试的包。前几年“软件测试包”是被捆绑在“本地化包”中进行，而现在，“软件测试包”被单独提出来来外包给中国的软件公司，而且由于软件测试是一项业务复杂也工作量极大的工作，在国内迅速发展且将来具有广阔的发展潜力。二、国内企业IT外包项目的痛痒何在？如此广阔的市场，如此庞大的市场商机，国内的IT企业应该欣喜若狂，但是现实的烦恼总比意料中的要多些。即便是目前对日外包最成功的企业，也总是在美好的远景与自身的虚弱感之间徘徊。一种发自生理和心理深处的多重“痒”感，正在撩拨整个产业的神经。现阶段中国的软件
30、外包还处在初始阶段，有很多很弱的方面，比如软件外包运作不成熟，因为外语的约束太大而使沟通不畅，项目管理水平落后，缺乏软件测试的质量管理经验，不熟悉国外软件开发和测试的管理模式，软件开发体系化管理方面做得不好，由于企业规模小无法接大的包等等，是国内企业在接包过程中的痛痒之处。在所有这些痛痒之中，最让人痛的也是痛之源头是人才的短缺。中国软件企业要扩大规模，首先要克服人才瓶颈。可以说，人才的缺乏，是中国企业长不大的根本症结所在。编码人才固然缺乏，但更缺的还是中高端的设计人才以及管理人才。道理很简单，一个管理人才可以带10个人的队伍，而10个管理人才则可以组建100人的“舰队”，因此高端人才的重要性不
31、言而喻。否则，中国的软件企业只能拘泥于“包工制”，原因很简单，因为项目管理水平上不去，无法承接固定价格的外包合同，即使接了不是质量不行就是时间拖延，或是因成本太高而使企业没有赢利甚至亏本。就拿软件测试的外包来说吧，软件测试包不同于软件本地化的包，软件测试更是一类灵活的抽象的不太好衡量的服务，而且其质量控制、安全保密、双方沟通等要求更高，所以，就目前国内软件的项目管理水平，很少有企业能把这种包用固定价格合同的形式接过来做成功。因此，目前很多公司接到的像微软、IBM、HP、NEC、东芝等这些大型国际外企的包，都是以“包工制”的形式进行合作，即以实际工作日来付费。三、如何进行有效的软件测试外包项目的
32、管理？既然清楚了中国企业IT外包项目有这么多的痛痒，那么我们又应该如何面队国外抛送过来的包呢？难道就就是长期以“包工制”形式一直做下去？答案是否定的。有人说企业分三个层次，高层次的企业拥有主动权，靠提供服务机会就能赚钱(如垄断性产品)；中层次企业相对主动，靠提供服务手段和途径赚钱(如集成方案)；低层次企业是被动，靠实现服务赚钱(如劳务)。三类企业境界不同，寿命也就不同。很显然，我们的“包工制”外包项目就是靠实现服务赚钱，如果长此以往，那么我们做的只是低层次的IT企业或软件企业，也许永远都是跟在别人的屁股后面跑，偶尔捡到点“事物”。毫无疑问，这种发展趋势，决不是中国企业、中国政府所希望发展趋势。
33、不难明白，“包工制”利润是极低的，中国的软件企业谁也不愿意只拘泥于“包工制”的小圈内，谁也不想只选择“包工制”。中国的软件企业都希望把外包业务做大，做规范，都更愿意把外包看作走出国门的“初级战略”和向国际软件服务企业转化的契机。用刘积仁先生的话：“外包业务是软件企业锻炼基本功的重要环节。” 因此，“包工制”会逐渐演变。在一定意义上，它应该是暂时为中国软件企业提供收入，为管理锻造空间和提供与国际客户接触的机会，是为中国软件企业国际化铺路，并把中国软件企业带到一个更高的境界。这些当然就是外包在国内蓬勃兴起的根本原因。那么我们应该如何逐步演变“包工制”，如何使借“外包”把中国的软件企业带到一个更高的
34、境界呢？至少目前的形式下，我们该从哪些方面着手呢？我们知道，项目外包的核心理念就是“做你最拿手的，其余的让别人去做”。因此，我们要做好外包项目，也需要从这个理念开始。我们不是没包接，而是没有实力和规模接大包。所以我们要能做好外包项目，做大外包项目，首先我们要有自己最拿手最擅长的招。印度的规模编码设计，爱尔兰的本地化都是在IT市场竞争中获胜了的接包的招。可是我们国内企业，还需要磨练，还需要更强更深的技术能力和项目管理能力等招术。软件外包测试的兴起对国内软件本地化企业意味着什么？笔者认为，意味着更多的机会，争取更多软件外包国际市场份额的机会。项目管理，我们国内的企业不乏丰富的经验，但是目前我们国内
35、的IT企业特别是软件企业，在外包项目这类特殊的“蛋糕”上，有些技能需要改善。主要体现在质量控制、时间进度控制、成本控制等方面。集中起来说主要有三个方面：一是人才方面，包括人才的能力、技能、实践经验以及通讯、交流的能力，还有人力资源方面：培训能力、人才储备的能力，人才储备不仅是软件企业自身，国家的人才储备更为重要；二是项目管理方面，包括项目管理的技能、外包经验，团队的项目管理以及历史经验、质量、时效、成本等；三是企业的基本情况的介绍，如文化、经济状况、信誉、品牌等。欧美国家非常重视信誉，中国企业在质量控制方面最主要解决的是交付期的问题，质量控制方面不规范就会使交付期延长。一个外包的软件出口项目通
36、常要配合国外的设计进行开发，但由于国内外软件企业在文化、管理上的差异较大，因此在管理方面，就不能完全采用一般项目管理的模式。首先，在项目准备阶段，项目调研工作要尽可能地圈定责任，应该在项目正式启动前，尽可能多的了解、熟悉系统设计、系统构架，然后签订一个比合同更加详细的书面的和约，确定双方在项目开发中所承担的责任和义务，要让国外发包方分析、设计人员将设计结果的各个子项目的定义、规则、意义进行详尽的阐述，务必让项目组人员对整个项目的概况及具体实现细节有一个清楚的认识，然后再进入具体的项目实施阶段。否则，往往会由于发包方在项目过程中进行过多的需求变更而导致接包方工作量和费用的增加，从而极易导致纠纷，
37、或者是国内那些接包企业对固定费用合同项目的害怕，并且就认为这种外包项目还是以“包工制”形式比较可靠，利润比较稳定，从而形成目前国内企业多数以“包工制”形式合作并且多数争取建立长期合作关系。因此，对于外包项目的准备工作要比一般的项目做的更详细更全面更到位。其次，应该在项目早期和发包方协商项目的验收方案，当然，项目早期确定项目的验收方案不是那么好确定，但至少应该有个大概的且要双方认可且达成一致的验收约定。项目验收的谈判不能仅仅只是对项目交付期的谈判，外包项目相比起一般项目来，更应该注意具体验收方案的谈判。第三，外包项目对语言培训比一般项目更加重要，在沟通管理中语言培训更应该花大力气。语言能力是影响
38、软件外包项目质量的一大因素。由于语言障碍导致的理解错误从而导致返工、误工的情况在外包项目中比比皆是，因此必须注重对员工语言方面的培训。第四，外包项目比一般项目更应该加强时间管理，对项目进度应该严格控制，项目经理更需要有效地监控项目的进度和风险，才能避免项目的延误，避免额外付出的开发费用。项目经理拿到外包商交来的项目计划后，要详细地进行审核并制定自己项目组的项目计划，并且需要进一步比较和分析二者后不断修改项目计划，使之既不发包方的项目计划冲突，又有利于自己的企业。通过这些活动和过程，项目经理从而进一步了解外包商对整个项目的流程、内容、估计的工作量和资源的安排是否与项目本身的要求吻合。明显的差异都
39、需要及时澄清并建立共识。确认了外包商的项目计划后才能够正式地启动项目，开始对项目进行监控。还有一个好的办法就是项目经理在制定时间计划时，除了要给项目留足缓冲时间外，最好是稍微让项目往前赶，但是不要把项目往前提的太多。第五，服务性质强的外包项目，比如软件测试服务，专家咨询服务，这类外包项目的产品是“软”产品，其项目输出、项目的质量等都是过程性为主的，而且工作量等也很不好量化，因此，对于这类项目的项目管理，而且是这类项目的外包管理，难度在很多方面更难。这种专业性很强但又是服务性很强的项目，首先要求这类公司有丰富的项目管理经验，而且要求这类公司在专业服务上对其提供的“子服务”进行分类，对每类“子服务
40、”要进行尽可能地明确清晰的定义、量化和服务验收方案的标准化，做到条块分明，即市场与服务一致，“子服务”类型定义清晰。除此之外，对于流程建立等类型的“子服务”，因为完全是过程性质的，因此必须有客户代表（最好是由于代表性的领导）参与，与自己的项目组组成一个项目小组，这个客户代表将来对整个项目过程都起非常关键的作用。四、小结“IT国际化，向外走出去”在我国已经被提出好几年了，而“外包”被许多国内IT精英认定的“IT（软件）国际化”的跳板，随之而来的IT外包项目管理也就成了讨论甚至争论的焦点。本文从宏观分析国内“外包”项目现状入手，分析目前国内“外包”项目的痛痒之所在，然后进一步阐述了如果针对目前的“外包”项目的特点，对不同的项目类型如何进行项目管理。IT外包项目的管理会随着我国的IT（软件）业的不断国际化而不断的成熟起来，也必定会有更多的有志之士加入到外包项目管理的队伍中来！
