标签：应该 可维护性 跟踪 成员 驱动 展开 知情 系统测试 软件开发
外包项目一般比较难以管理，由于不是自己来进行具体实施，项目在进行中出现的各种问题对甲方不透明，造成项目的成败往往掌握在承接方手里。这样就常会有进度超期、质量不符合要求、甚至工作结果根本不符合甲方需求等情况的发生。如何去应对？
首先要意识到无论什么样的项目，在实施过程中都会出现各种各样的问题，如果不去主动跟踪，很多问题可能会一直潜伏到验收的时候才浮出水面。从甲方的角度来看，发现问题一定要早，不要等到交付期时才发现，到时恐怕已经无法挽回。越早发现问题，改正的成本越小；越到项目的后期，改正的成本越大，给项目成功带来的风险也越大。所以，甲方一定要建立对外包项目的跟踪控制机制，贯穿实施的全部过程。
其次，软件项目不仅应满足功能性需求，还应该满足可维护性、可靠性和复用性等软件工程上的质量要求。对于承接方的实施人员来说，项目的实施具有一次性，自己不是项目成果的使用者，甚至也不是后期维护的维护者，所以没有进行长远打算的驱动力。而这些质量特性都需要在实施过程中的计划、设计和编码环节进行综合考虑，但承接方为了赶进度、省成本，可能对此并不太重视，认为能够对付合同上规定那些条款也就足够了。这样就造成了软件在交付后，出现问题难以维护。等过了一年维护期后，用户自己对软件维护就更难以进行。对此，甲方要参与到承接方的质量管理中去，要求承接方建立质量保证计划并严格实施。
再次，很多时候甲方并不从事于软件行业，而只是软件项目成果的用户，对软件开发的知识并不了解。所以对于承接方采取的开发流程、技术方法和质量难以衡量。甚至由于甲方接口人员并不懂软件开发领域知识，在同乙方讨论时，被对方抛出的一大堆术语、技术细节所淹没，但为了维护自己的自尊心，出现不懂装懂，胡乱应付的做法，或者干脆就任由乙方去进行各种决策，自己完全撒手不管，让乙方完全掌握主动权。最后在验收后才发现项目结果不能完全符合自己的需要，或者存在这样那样的问题。为防止这种情况的发生，甲方首先要客观面对自身的弱点，选择对软件开发行业熟悉、且有一定经验的人作为接口人（甚至可以外聘项目监理），并建立一套正规的外包项目管理制度和方法，从制度和人两方面来保证项目的正确实施。
与院校等科研学术性单位进行外包合作，尤其要注意，由于这些单位的工作多属研究性质，他们对软件功能上比较重视，也就是要求能走通就行，而对工程上的特性并不愿多投入。所以他们所完成的软件，如果不加控制的话，后期会很难维护和复用。另一点，由于院校的很多项目是导师指导学生来完成，而学生具有流动性，且水平基本上都处于新手水平，开发经验不多，所以开发质量、后期bug的跟踪和修复方面是个风险。而且，院校、科研院所等单位往往工作节奏不快，在进度上也不能太乐观。
具体来说，甲方要从以下几方面来保证外部项目的成功实施：
1、范围管理
甲方的需求提出的越详细清晰、越没有二义性，越有利于乙方展开工作，降低项目风险。如果甲方不能够在项目开始阶段就提出足够细致的需求（很常见），那么可以在实施推进过程中逐步细化，也可要求乙方建立原型来辅助需求的深度挖掘。
撰写详细的软件规格说明文档，作为乙方的范围基准。
要求乙方根据工作范围建立WBS和相应的工作量估计，从而有利于甲方的对项目的跟踪。
2、进度安排
根据WBS和工作量估计，制定进度计划，并以图表的方式表现出来，作为甲方跟踪的依据。
对远期的工作要求有大致的进度计划，对近期的工作要有详尽的进度计划。
为了降低项目的风险，可以要求乙方对软件进行分阶段交付，设置多个里程碑，每个里程碑交付软件的一部分。每次交付验收后，乙方可继续开发其他部分，而甲方可将交付的部分投入更详尽的测试，或者进行现场实测。这样做的好处就是，将项目交付的风险分摊在整个实施过程中，而不是最后交付的那一刻。
分阶段交付的另一个好处是，通过前期的交付，甲方可以对乙方的各方面情况有更充分的了解，例如开发人员稳定性、技术及管理水平、乙方对项目的态度等等。如若发现乙方的资质完全不能满足项目开发的要求，应该立即取消项目，从而避免更大的投入损失。
3、质量管理
软件的质量取决于参与实施的每一个成员，以及涉及到开发的全过程。尤其重要的是，在项目的前期计划中一定要充分认识到质量的重要性，并制定相关计划，采取措施以保证质量指标的实现。
对于甲方来说，由于不直接参与设计与编码，所以对软件的内部质量除要求乙方实行质量保证措施外，较缺乏直接控制的手段。所以甲方要多在系统测试方面下功夫，对于提出的各项需求，做好相应的测试用例，任命专门的验收测试人员。在软件的非功能性指标方面，也要想办法对乙方施加影响。
4、沟通管理
为了能够及时掌握外包项目的状态信息，需要与乙方进行定期和非定期的、各种形式的沟通，出现问题及时能够发现，降低项目失败的风险。对于乙方来说，出于某些原因，并不愿意与甲方完全共享项目实施的情况，除去那些做非正常手脚等情况不谈，乙方害怕甲方过多了解项目实施情况后会有进行微观干预的冲动，指手画脚结果把工作弄得一团糟。所以甲方要认识到沟通的目的不是为了随时插上一脚，而是为了确保自己对项目的进行充分知情，不要有大问题发生后自己却蒙在鼓里。与乙方的交流要建立在互相尊重、信任和实事求是的基础上，对事不对人，尽量不要让乙方产生防备心理。毕竟每天在第一线工作的是乙方的人员，如果他们由于害怕受到批评而想隐瞒的话，甲方是很难控制的。
5、乙方人员安排
虽然说负责实施的是乙方，具体的人员安排由乙方来定，但项目都是由人来实施的，人员的安排对于项目成败至关重要，作为项目成果的使用者，要对此心里有底。我们要看乙方人员安排的是否合理，具体要看乙方人员是否具有足够的软件开发方面的专业能力，对项目业务领域的知识是否掌握，乙方项目组长是否有足够的软件开发和项目管理的经验和能力，人员是否足够，乙方对项目投入的是否足够多等等。国内的现实是，业余的项目组长和程序员占软件开发人员的大部，开发方法基本上是code-and-fix，让他们来主导实施的话，容易让项目走向混乱。作为甲方不可能改变业界的现状，只能尽力做到心中有数，尽可能施加影响，让合适的人来做合适的事。
6、风险管理
7、变更控制
8、验收管理
9、项目跟踪与控制
10、项目管理文档
11、乙方项目管理水平保证
标签：应该 可维护性 跟踪 成员 驱动 展开 知情 系统测试 软件开发
原文地址：http://www.cnblogs.com/GmrBrian/p/6009962.html
