这个项目在快接近完成的阶段时，不但是外包商基本上每天都要加班加点，而且我这个发包方负责人也不好过，也经常要把周日都"搭上"。因为我非常担心外包商在最后一个星期才告诉我不能如期完成，这样就会影响到我公司整体的软件建设规划。但正如我所担心的一样，这个外包项目最后还是逃脱不了延期的悲惨境况。

总结我在外包项目管理上的失误

当外包开发的软件不能如期交付时，我们往往会在第一时间把罪过推给外包商，这也是我在总结这个外包项目时的第一想法。但事实却告诉我，延期的原因除了是我这个发包方没有选择合适的外包商、或没有提供完整的软件规格需求说明和或没有做出适当开发技术评估之外，更重要的是由于我在这个过程中没有建立自己的项目计划、没有跟进和监督开发的进度、没有在开始时建立好质量指标和测试流程、而且也没有做好最基本的工作，就是定期与外包商沟通与协调所造成的。

（1）失误之一：发包方没有建立自己的项目计划

在总结失败原因时，我发现最大的失误是我作为发包方居然没有建立基于自己企业角度的项目计划。在经过痛苦反思后我得出的心得是，作为一个发包方负责人，千万不要直接采用外包商提供的项目计划来进行监控，以为这样可以省去做项目计划的工作。实际上纵然是外包商已经制定好一个可行性高的项目计划，发包方负责人也需要亲自制定一个从自己企业角度出发的完整的项目计划，这样才能够知道整个开发的工作量，才能评估和衡量外包商是否拥有充分的资源，以及判断外包商所承诺的开发时间是否可行。

因此，发包方在建立自己立场的项目计划时，应该先要求外包商在项目开始前提供一个完整开发计划。一些外包商为了避免繁琐的文书工作，往往会宣称合约签订前所提供的计划便是整个项目计划。事实上，外包商这样做只会说明一点，就是他们并没有一套完整的开发管理体系和项目管理机制。实际上任何一个称职的外包项目负责人都应该了解这一点：合约谈判期间所制定的初步项目交付计划并不全面，是需要根据软件开发的实际合约内容进一步进行修改，例如要补充上实际的工作量、资源的调派和需要的时间才能够成为一个可行的计划。

所以，发包方负责人在拿到外包商交来的项目计划后，要详细地跟本企业的计划进行比对和审核，要了解外包商对整个项目的流程、内容、估计的工作量和资源的安排是否与项目本身的要求相吻合。当有明显的差异时，双方应要认真分析和深入讨论，或进行必要的修改和补充，建立共识并形成双方都接受的最终项目开发计划。

（2）失误之二：发包方没有关注进度评估

在总结项目延期的原因时，我发现大家用得最多的一个词是：进度失控。这时，我才明白到项目进度不但会影响双方的成本，而且还会影响产品质量。因此，外包合约必须明确规定外包商需要定期提供进度报告。在报告中外包商应该要把影响未来进度的各种因素进行分析和预估，及时与发包方交流，以方便双方合理调配资源。

例如，在我看过的很多进度报告中，内容各有不同，但大部分都只是说明已经完成了哪些工作、哪些工作还在进行中、有的报告还会采用红、黄、绿等颜色来表示项目进度的状态。但这些信息基本上只能让阅读者了解项目的概况，并不能让项目负责人全面地把握项目的进度。

在反思和总结延期的经验时，我认为发包方还需要知道余下的还有哪些工作还没有完成、需要多久才能完成、哪些工作还没有开始、是否能如期开始以及计划的资源有没有变动。要是这些答案跟原计划有差异，应该马上进行反思，深入了解还没有完成的工作以及没能按计划开始的主要原因，从而能跟外包商探讨如何才能够把项目拉回正轨。已经完成的工作，对我来说已经是历史，对项目能否如期完成已经没有多大的影响。只有还没有完成或者还没有开始的工作，才是项目的致命伤，才需要特别加以监控。

因此，作为一个发包方的项目负责人，不仅需要对内部项目资源和进度进行统筹调节，也需要了解外包方的进度和安排。千万不要认为外包后就可以减少管理和关注的时间，相反外包后有时更需要双倍的时间去关注和监督。因为由于信息不对称、不透明，所以管理一个外包项目会比内部项目更为复杂。这时不但需要建立更多的里程碑来监控项目的进度，而且需要更多的沟通与协调。所以，千万不要以为项目外包后就可以免去进度管理的需求，否则到最后进度失控时会给你一个大惊喜。

（3）失误之三：质量控制和验收没有如影相随

一般来说，为了达到发包方的质量要求，接包方在质量控制上会通过严格的、完整的测试流程保证编码质量。因此，外包项目最大的风险并不是在编码过程中，而是在开发过程中每时每刻的需求吻合度。例如，很多外包项目往往是在验收过程中，才发现业务逻辑或者输入数据范围等细节上出现问题，导致测试结果与实际所需不符，需要外包商进行大量修改而使项目延误。这时，外包商会抱怨认为错不在他们，而是我们发包方没有说清楚，但实际上这样都是一些非常细节上的东西。

不幸的是很多发包方在软件开发过程中，往往把验收列为开发项目的最后一项工作。其实这种观念不但是不正确的，而且是外包项目中最大的风险之一。要避免这类风险最佳的办法是在开发的过程中验收也同时进行，而不是等待开发完成后才进行验收。项目的验收应该是跟随项目的开发过程同时进行、同时开始、同时结束，这样才能够保证最后的验收不会偏离原设想的需求。

（4）失误之四：双方的沟通质量没有得到保障

软件开发项目外包延期的原因也许有很多，但肯定有一条的就是沟通没有得到保证，这也是被称为延期的第一因素。许多软件外包项目失败，究其原因常常是因为开发人员对设计意图的误解而产生的。一般来说，在内部进行软件开发时人力资源大致会分为两组：一是技术人员，另一组是配合技术人员的业务人员，业务人员一般是所建软件系统的潜在用户，两者在内部因为直接当面沟通，会有更大可能的保证沟通的质量。而在开发外包项目中，会增加了一组外包商的资源，外包商团队也会分为技术人员和业务人员。

一般来说，外包商会指派一名专门的联络人员负责联系与协调，而他们的技术人员只在后方负责项目的开发。这时，沟通渠道就变成了：发包方业务人员》发包方技术人员》外包商业务人员》外包方技术人员。实际上，这种运作模式要尽量避免，因为外包商指派负责联系的人员往往是业务背景的人员，对技术的细节不能全面把握，把有关信息传达到技术人员的时候便会有所差异。因此，在外包活动中应该要把沟通放在第一位，双方要做到"心有灵犀一点通"的境界。所以，外包商项目联系的人员最好是开发小组的主管，而且这名开发主管是直接参与开发的主要人员，如此双方才能够有效地进行沟通。

发方包如何确保外包项目如期完成

相对于传统的采购管理，软件开发外包管理的采购对象不是物品而是一些拥有技术能力的人员。管理内部的人员已经是一件困难的事情，更何况是外部的人员。而且很无奈的现实是，外包开发合同一般来说并不是很严格的。在这种前提下，要保证项目的如期完成是多么困难的一件事情。因此，发方包必须要关注以下几点：

（1）要了解外包方的团队组成与变动

基于人员能力和变动对软件质量和如期交付的影响，要确保软件外包的目标实现，发包方必须了解外包方团队人员的结构与角色能力。在合同上应该要有特定的注明，就是当有核心人员变动或流失时，重新调配人力资源的准则和处理办法。否则，延期失控或质量下降就在所难免了。

（2）在项目准备阶段，发包方应尽快熟悉设计

在实践中，一些外包项目的失败除了是双方权责不清导致外，更多的是由于发方包对设计的不熟悉而提出过多的、或频繁的变更。因此，在项目准备阶段要尽可能地圈定双方责任，特别是发包方应尽快熟悉设计。例如，在项目正式启动前，发包方应尽可能多的了解、熟悉系统设计；或发包方需要将设计结果的定义、规则、意义进行详尽的阐述，务必让外包商人员对整个项目的概况及具体实现细节有一个清楚的认识。否则，发包方在项目过程中过多的需求变更会导致接包方工作量和费用的增加，从而使开发方产生厌倦、怠工的情绪或纠纷，经验表明这些消极措施都可能会导致项目延误。因此，对于外包项目的准备工作，发包方要比内部项目做的更详细、更全面、更到位。

（3）开始前先确定质量指标和验收方案

在项目早期双方就要协商项目的验收方案，这是我在和外包商痛苦的推卸责任、扯皮后得到的心得。当然，项目早期就确定项目的验收方案不是那么好确定，但至少应该要有个大概的、且要双方认可的、且达成一致的验收约定。项目验收的谈判不能仅仅只是关于项目交付期的谈判，外包项目相比起一般项目来看，更应该要注重提前就关注具体验收方案的谈判。

（4）加强时间控制，引入里程碑管理

最后，我还有一个收获要与大家分享，就是外包项目要比内部项目更加强时间管理和项目进度控制；发包方负责人更需要避免项目的延误，以避免额外支付开发费用。因此，发包方负责人拿到外包商交来的项目计划后，要详细地进行审核并制定自己的项目计划，有明显的差异时要及时澄清并建立共识。使之既不与接包方的开发计划冲突，也又有利于自己的企业。

在外包项目中最成熟的时间管理技术是里程碑管理，里程碑一般是指项目中完成阶段性工作的标志。比如，在开发项目中可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。不过，要注意的是每到一个里程碑处应及时对前段工作进行小结，并对后续工作进行计划调整。对于一些效果明显的领域可以不必投入较多精力，而对于下一步可能会出现问题的领域，应要给予较多的关注。

总的来说，发包方在管理和监督外包过程中，最重要的不是控制外包活动中问题的发生，而是要以预防问题的发生为主，要时时刻刻的保证项目不偏离正常轨道为主。也就是说，开发工作可以外包出去，但管理和监督的责任是永远不能外包的。