以前的工作经历和心得，没有得到很好的总结，但是总结能够使我快速提高。我要坚持... DBM 历程（一）

    今天是我Charge DBM这个项目的第8个月了，这个项目很快就要到达彼岸了，心中总算有些欣慰，回顾这中间的点点滴滴，实在是太多的感慨，不知道自己在以后的项目当中会不会碰到类似的情况，可这确实让我感到在项目的实施过程中，收获大于失落。

    DBM这个项目是公司有名的烂尾项目，所有.Net Team的说到DBM就摇头，当自己闻听要接手这个项目的时候，心里还是有很多的抵触情绪，毕竟此前这个项目已经更换过好几次PM了，HQ方面的整个团队甚至全部Resign了只剩下了一个BA。首先我要面对的就是对整个Team进行重组，我想稍微有点经验的PM都知道这个对软件项目来说意味着什么。
    Boss告诉我，我只有一个月的时间来对项目组成员进行重组，并完成技术交接，以前在项目中消极怠工的人员都要全部转移出来。面对现状，我唯一能做的就是先了解这个项目的状况，并对风险进行评估。
   

序号	Risk CheckList	Description
1	人力资源的风险	1.随着PM的更换，以前的团队对新的Team和项目已经没有太大的信心了（此项目已经延期半年），随时会有一些项目组中比较有经验的程序员将离职（中国特色），而对于一些消极怠工的程序员，为了不影响新的团队的情绪和态度，公司也会做适当的调整。因此次风险系数为High 2.新的程序员多半是没有经验的新手，要想快速进入角色，有很大的风险，风险系数为High
2	技术风险	1.项目的设计者，架构师的离去，将对整个项目的技术的交接产生巨大的风险，因此需要在他离开之前的工作交接过程中，对新的Team进行系统架构的培训。 2.老的程序员的离去，项目中又没有BA，那么业务逻辑也需要请对系统比较熟悉的QA来进行培训，但是效果能否达到预计目的是一个风险。 3.没有设计文档，而且整个系统采取分布式开发（CTU开发70%的功能，HQ开发30%的功能），Use Case多达1000多页，现在要求程序员去看总是不太现实（项目超级大），而且进度也会有影响。
3	需求变更的风险	客户的需求不断变化，尤其是UI的需求，往往出现重复修改，因为项目延期很长时间，HQ方面已经对客户的需求变换out of control.
4	测试风险	目前所有的测试团队均为黑盒测试，新的测试人员对系统的熟悉程度不高，而目前的bug又非常的多，需要通过系统的培训，甚至加入自动测试工具来完成一些核心功能的测试。
5	成本风险	项目进度很有可能因为需求的不确定和新手的加入，导致不能按时交付，这样对整个项目来说，人力成本在无形的增加，而且我们对DBM的客户已经失去了应有的控制（out of control）.

    当风险列表完成后，我大吸一口冷气，这可真是一个棘手的项目，而我就是这个项目的船长.....