【IT168 技术文章】

    一个全球性的公司的IT业务系统开发与维护整体外包给我公司后，现有的大量业务系统的维护被划分为若干个维护项目，而为了适应客户公司的业务发展与变化，开发新的业务系统和对现有系统进行修改完善是必不可少的工作，这一部分的工作被划分为开发项目。这样划分的组织结构职责清晰，任务明确，适合于项目管理，是典型的项目型组织结构。

    现在的问题是，如何管理两个项目之间的联系？开发项目组开发的业务系统完成后要转到维护项目组进行维护，如何管理这个过程？

    业务系统从开发项目组转到维护项目组维护之前，该业务系统应该已经正式运行，而且要求开发项目组维护一段时间，直到维护项目组正式开始维护该业务系统。

    在开发项目组认为开发项目可以结束，业务系统可以交接给维护项目组时，两个项目组的manager开始接触协调，这个交接过程就开始了。这个过程其实很简单，就是双方一起审核交接条件，只要维护项目组认为现在的业务系统满足交接条件，维护项目组manager签字同意，那么该业务系统就正式由维护项目组维护了。

    满足哪些条件维护项目组才能签字同意该业务系统由他们来维护呢？

    首先，客户、最终用户和相关操作者对该业务系统感到满意。

    这是最基本的条件。如果这些人对这个系统还不感到满意，那说明该系统还没达到用户的要求，客户还没有验收，可能还有接下来的开发和修改工作。那么这还是开发项目的延续，在这种情况下开发项目都没法结束，维护项目组就更不可能接收这样的系统来维护了。

    其次，保证系统已经稳定。

    开发项目组需要开始向维护项目组做必要的业务系统知识的培训。维护项目组在培训完后，可以测试系统，看系统是否稳定。如果系统有大的性能上的问题，开发项目组也是需要先解决掉了以后维护项目组才能接收。

    另外一个条件是所有的系统问题都已经解决，包括用户使用后报告的问题。

    业务系统正式运行后如果用户发现问题，都需要在SLA规定的时间内解决。所有的问题都是可跟踪的，在把业务系统正式移交给维护项目组前，这些问题必须都已经被解决。

    最后，当以上条件都满足后，开发项目组需要向维护项目组和业务部门展示在该业务系统的开发与短期维护中的经验教训。这样可以让维护项目组充分了解该业务系统的历史情况。

    在把业务系统从开发项目组移交给维护项目组的过程中，关键的活动包括：

    1. 维护项目组测试系统是否达到客户要求，如果需要，实现对系统的监控。

    2. 开发项目组报告系统过去的系统维护与修改历史记录。

    3. 维护项目组测试过系统后，如果认为系统是稳定的，开发项目组就开始向维护项目组做业务系统的知识培训。

    4. 更新业务系统的风险管理文档。

    5. 更新业务系统的SLA. 6. 和业务部门一起确定定义维护过程，包括问题如何报告、问题如何解决、什么样的问题什么样的team来负责等等。

    7. 确定维护项目的费用与结算方法。

    8. 开发项目组与维护项目组和业务部门一起分享业务系统开发与短期维护过程中的经验与教训。

    9. 客户对业务系统的满意度评估。

    当以上工作都做过后，所有的移交条件也满足，那么开发项目组、维护项目组和业务部门一起就可以签字，业务系统正式由维护项目组来维护。那么这个移交过程也就圆满结束。