功能升级项目的CMMI流程之路

    此项目是一个功能增强的项目，该项目不算管理活动的规模是260人天，时间跨度3个月，而且是直接对接第三方系统，由于客户有时间上的要求，所以总体来说：其项目的特点可以简单概括为：关系复杂、任务紧、风险较大。
     我作为此项目的项目经理，全面负责该项目。目前该项目已经进入开发阶段，具体的CMMI流程中的程序实现阶段。从我个人在此项目中的经历来看，制定工作分解结构非常重要。记得培训的老师说项目经理的工作简单的来说就是做减法，我理解也就是说将项目所有的活动最终都分解成1-2周的具体任务，并且落实到具体的人。用项目计划工具MS project作为辅助工具，我将任务一个一个的分解，从需求、设计、编码、测试、上线等各个环节的项目成员该做的工作一目了然。完成了工作结构分解之后，某升级的项目计划也就很详细的明确了，然后可以根据实际情况的设定里程碑，比如说提交ST(系统测试)，上线等都可以作为项目的里程碑。
      当我指定好工作结构分解之后，每1-2周的周一就按照工作结构分解上的明细任务，来给所有的项目成员分解具体的工作任务，这样项目成员就可以在下班前填写好详细的任务工时，作为项目很详细的一个工时的统计。每周五或者周一，我在填写项目周报的时候，其直接的属于来源就是工时系统，从中我可以得到PV,EV,AC，汇总数据之后就可以汇报给领导了。从其中的数据分析，我发现我们的项目规模估算还是和实际的情况有很大差异。我们的宽带delphi估算法确实带来的估算结果和实际的工作工时有比较大的差异，至少目前某升级的估算就是差异比较大。这样带来的后果就是项目计划的制定会导致偏差。经过培训之后，我认为：功能点估算法更加科学和准备，可能这种方式就是我们以后项目的估算方法，但是需要数据的积累。
     此项目目前只进行到一半，前期立项阶段有一项也很重要的活动：识别项目风险和关键依赖，我觉得风险较大的就是我们这次系统的开发成功与否很大程度上依赖于第三方系统，我们的系统是通过对接第三方系统然后间接实现客户的升级功能的。如果我们双方前期没有约定好彼此认可的接口和交互的数据属性，那么在系统上线之后，就可能会出很多问题，最终导致严重的后果：对接失败，也就意味着项目可能失败。项目管理知识中对风险的处理方式有四种：回避、转移、减轻和接受。这个项目我们采用了接受的处理策略。在接受之后，我仔细分析了实际情况，和项目组的成员一起确定了一个方案：在后续的三个关键点，安排资源和第三方系统进行对接测试，这几个关键点分别是：1.程序实现阶段，提交ST（系统测试）之前2.系统测试测试阶段；3.UAT测试阶段。然后和深圳的同事们（做需求的同事）沟通，请求他们直接和第三方的联络人联系，提出我们的这种方案。从第三方的负责人的回复邮件看来，他们的态度是很积极的，也是比较认可的。这样我们可以解决上述的问题，尽量将问题扼杀在摇篮之中，避免成为项目的”失败关键”。
    作为项目负责人每天的工作大部分时间都是在沟通协调上。其实从整个项目的实际情况来说，沟通协调是很重要的，对于项目经理这一职责：和项目成员、上级项目经理负责人、其他兄弟项目成员、测试部门同事、需求部门同事、加上项目第三方公司，我的沟通对象各种各样，总结一句话就是：项目经理80%的时间都在沟通，沟通的方式各种各样，邮件、电话、UC、直接面对面等等，有了良好顺畅的沟通，项目中信息流的畅通无阻，从而使项目经理对于项目的各种情况，各种事件会掌握的非常全面，有利于项目的顺利正常进行。我认为，这个也是项目最终能否成功的关键点之一。
     此项目还只进行到一半不到，但是通过走CMMI流程，它带给我们的不仅仅是标准化，不仅仅是流程的规范，而是从各个方面都会改善我们的项目管理工作，可以预见，在不久的将来，会带给我们非常大的优势。