CMMI（Capability Maturity Model Integration For Software,软件能力成熟度模型集成），是由美国卡耐基梅隆大学软件工程研究所组织全世界的软件过程改进和软件开发管理方面的专家历时四年开发出来的，它是在CMM基础上发展来的，目前在世界范围已成为一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估。
他山之石，可以功玉。CMMI是一面镜子，参照它，我们可以比较直观地了解自己的软件开发能力，找到值得借鉴修改的地方，有效地改进我们的项目管理方式，提高软件产品开发质量。
本人作为交通银行IT部门人员，有幸参加了交通银行（以下简称交行）数据大集中工程核心一期的项目工作，历经了从管理到开发到维护等项目进程的各个阶段，在项目管理方面感觉收获颇多。在学习CMMI之后，我静下心来反思，认为交行大集中项目管理还有许多可改进的地方，本着交流学习的态度，冒昧地将一孔之见在此托出，希望得到大家指正。
问题一、计划制定合理性
Ø问题说明：
1、计划期限的制定不尽合理。行领导在听取项目组的项目汇报后，根据行业发展规划及市场开拓要求，明确了大集中核心一期项目的完成期限。在项目总体时间确定的情况下，项目组制定了项目总体计划，项目的各项开发管理皆在总体计划的指导下进行。
2、项目计划可供调配时间紧张，需求变革未在项目计划中加以反映。
3、因为项目计划时间少于项目实际耗费所需时间，为控制项目按期完工，项目组不断从分行抽调兵力，并采用大量加班方式来赶进度。而新人的培养需要投入熟练人员来培训，短期内进一步导致人员缺乏；过度加班又导致了开发人员精力和创造力持续下降……项目陷入“人月神话”式的误区，对进度、质量、成本都产生不利影响。
Ø问题点评：
以上问题的根源在于项目计划的制定方式不尽合理。
项目计划是执行和控制项目活动的基础，计划的好坏、合理与否关系到项目的质量、项目的进展、项目的成本等等重要环节，它的重要性是不言而喻的。
项目实施期限的设定是“在项目资源基本明确的基础上，在对需求范围公正分析的前提下，通过任务分解、工作进度判断以及工作量评估等方式得来的。”
仅有好的愿望而不切合现实情况，计划的设定是不会合理的，交行项目组在项目期限已定的情况下，只能根据项目截至时间倒排计划，对各个环节的工作时间进行压缩，从而为项目带来一定的风险。
因为项目总体计划未留出需求变更余量，随着项目需求的不断明确，许多不确定的需求日趋明朗，需求变更问题不断涌现，随之而来的工作加大了开发工作量，延长了开发时间，从而影响了整体项目进展。
Ø解决方案：
项目总体计划是项目进行的指南针及控制基础，它的制定是一项非常严谨的工作。项目计划的制定需要多个步骤来完成：
1、确定项目的应交付成果。其中又分为中间交付成果（如：文档）和最终交付成果（如：开发的产品）；
2、工作量分解。在明确项目范围的基础上，通过工作分解结构WBS等方式将项目工作层层分解，将大任务化为阶段性任务，确定阶段性工作目标。
3、确定各个任务之间的相互关系。各个任务彼此相互制约、相互依赖，通过分析确定各个任务执行的先后顺序，整理出各工作任务之间动态的工作流程。
4、确定每个任务所需的时间。根据模型和历史数据估计工作量，从而估算出各任务需要耗费的时间；并明确各任务所需的资源要求。
5、确定项目团队成员可以支配的时间。根据项目团队中的职责分配及工作任务划分，分配项目成员具体工作及工作时间。
6、确定管理工作。管理工作是贯穿项目生命周期的，如项目管理、项目会议等、编写阶段报告等。
7、根据以上结果编制项目总体进度计划，总体进度计划应当体现任务名称、责任人、开始时间、结束时间、应提交的可检查的工作成果。
8、考虑项目的费用预算、可能的风险分析及其对策、需要公司内部或客户或其他方面协调或支持的事宜。
其中，计划的制定应留有余量，将人员变更、需求变更、项目沟通等不太确定性因素考虑进去；另外，计划的最初，还有许多动态因素（如需求范围未完全明确、工作量的评估不准确，工作进展落后逾期估计）未明确，这时的计划应留有不断完善的余量，在计划执行的过程中，通过项目进度跟踪及各个环节的不断明细，从而定期地完善工作计划。从而保证其合理、可行。
另外，如若遇到项目发生变更，要进行并更影响分析，得到批准后制定变更计划，并按变更计划执行。
问题二、文档未及时更新
Ø问题说明：
交行的数据大集中项目对文档收集工作非常重视，各类技术类文档（方案设计书、计划说明书、架构设计书、功能说明书、详细设计说明书、接口文档、压力测试报告等）及管理类文档（会议纪要、工作制度、项目通报、项目备忘、管理规范等）都得到了有效的收集及归档。
问题在于文档的变更未及时完成，往往项目编码更新并实施已经一两个月了，相关技术文档还未得到有效更新。
交行项目组也发现这个问题，同合作公司（未更新的文档主要是由合作公司负责编写及修改的）多次协商变更及变更期限问题，而合作公司认为这些工作属于需求变更问题，公司以需求变更量过大，耗费人力过多，超过开发合同条款所规定范围为由，婉拒了交行“及时更新文档”的要求。造成了文档更新的滞后。
Ø问题点评：
为了保证文档的正确性，文档的变更是非常重要的。陈旧的文档不光起不到知识参考作用，还会对项目开发起到误导作用，有时会导致项目返工的出现，从而影响项目质量，提高项目成本。
出现的扯皮现象在于合同管理存在漏洞，当初合同签订时未充分估计到需求变更的工作量，未在项目合同中对相关工作设置条款进行制约。
Ø解决方案：
1、合同管理要对文档更新问题进行约定。合同签订之前应先对项目工作量有一个评估，在科学的评估基础上，要对未来的需求变更工作量有大致正确的估算，并在合同中设置条款将需求变更部分的执行方式明确约定，以保证其正确无误地实施。
2、制定文档更新管理制度，保证其执行。开发人员对于文档编写有一种先天的惰性与轻视，为保证其实施，应制定切实可行的管理制度，明确文档编写要求与文档变更期限（在程序发生一定时间期限内要保证文档得到及时更新），从而保证文档编写与变更的及时性。
问题三、需求分析未完全纳入项目管理
Ø问题说明：
业务需求组予项目管理组是项目中的两个职能单位。其中业务需求组是由财会部牵头调集总、分行的需求人员组成，从属于财会部；项目管理组主要由技术管理人员组成，从属于科技部。
在两个小组之上设置了一个职能小组——总体组，它由各个部门领导组成，由行领导担任总指挥。总体组主要负责项目的整体管理及监控。而项目的具体管理及实施是由项目管理组负责的。
矛盾的焦点在于，项目管理组与需求组是事实上存在与总体组管理下的两个平行单位，项目管理组有权管理其他小组，唯独未将需求组纳入管理范围，对其所谓的“控制”，是项目管理组将项目控制安排与需求组中财会部领导商议后采取的折衷方案。
Ø问题点评：
需求是项目组成的重要部分，需求范围、需求变更、需求测试及验收等进程无不与需求管理密不可分，而需求管理是项目管理不可或缺的重要环节，它的进展与质量严重影响到后继的项目开发，关系到项目的最终成败。
从管理角度讲，需求组应该在项目管理组管理之下的。而交行项目中需求组与项目管理组权利的平行，会导致许多项目项目管理决定无法明确无误地实施，可能会在需求组“特殊情况”的要求下执行走样。
Ø解决方案：
项目实施前，应给予项目管理组仅次于“总体组”（有各部门领导组成，行领导坐镇）的管理权限，项目管理组在“总体组”领导下有全权的项目规划、执行、控制等权限，需求组应纳入项目管理组控制之下。
为保证各个项目组对项目管理组控制指令的有效执行，项目管理组在项目计划制定、项目实施里程碑等项目管理措施上应事先与各项目组有效沟通，并建立综合反馈机制，跟踪各项目组执行情况，保证其项目指令的正确可行性。
一旦项目管理组发布管理指令，令行禁止，大家都要认真照办，这样才能保证项目的可管理性。
问题四、工作量化不尽合理
项目进程中的项目计划制定、变更工作量评估、进度估算、成本评估、绩效考核等环节都是与工作量评估密不可分的，如何客观、合理评估工作量是每个项目组都“头痛”的难题。
Ø问题说明：
交行在工作量估算时，在需求范围大致确定的情况下，会采用WBS模型、根据历史经验和同业比较，经过各级专家会议论证，从而得到量化结果。
Ø问题点评：
1、交行缺乏相应的项目历史库，在工作量评估时从数据上来讲缺乏需要的项目数据来供参考。
2、交行项目组因为项目期限已先期由总行确定，工作量的评估被事先打了折扣，后果往往是项目不停的加人，人员不停的加班，最终对项目整体目标造成影响。
Ø解决方案：
工作量化实施方法：
1、制定量化分析计划，用来管理和分析活动；
1)明确量化分析的组织方针；
2)明确量化分析需要使用的资源；
3)明确测量和分析干系人的责任及权限；
4)明确培训计划；
5)明确量化和分析的共同利益者，确定其介入时机。
2、建立量化目标；
3、确定量化项目，主要涉及以下三个方面：
1)产品规模方面；
2)工作量和成本估计；
3)质量控制方面。
4、将量化目标与量化项目实际相结合，将其定义化、具体化；
5、确定数据采集和存储规程；
1)确定数据来源；
2)针对量化项目说明如何收集和存储数据；
3)建立数据采集机制和规程指南。
6、选择适当的数据分析方法和工具；
7、确定量化分析的人员、时间、通报的形式等；
8、确定评价准则，从而评价分析结果的可利用性及量化分析的执行情况；
9、收集量化项目数据；
10、对收集到的项目数据进行分析；
11、建立数据库，对量化项目数据、量化规范、量化数据分析结果进行存储，以利于查询和再利用。
从量化过程可以看出，项目历史库的建立是非常重要的，它的建立对于项目的控制、检查、其他项目的量化类比分析等有重要的参考作用。
在项目进程中，应通过文档、数据库等方式建立历史库，将项目开发进程中各类数据进行统计，如：计划的制定方式、工作量的评估方式、使用的技术及工具、计划、计划的修改内容、修改原因、每日编码量、每日返工量、每日测试量、需求变更量、文档的编制进度等等。对这些数据进行历史经验库登记后，我们就可以通过分析历史经验库中的数据了解个人工作量分配是否合理，个人工作能力的提高是否符合要求，是否需要进一步培训，是否需要调整工作计划等。此外，历史库还能为未来的项目开发提供历史依据。
问题五、项目组之间的沟通
Ø问题说明：
交行项目组之间对于项目的沟通是非常重视的，但对沟通的预见性存在不足，往往是随着需求的深入细化及各项工作的明朗化，在遇到需要协调解决问题的时候，通过沟通渠道进行信息沟通。
Ø问题点评：
这种沟通方式是国内大多数项目组的通病，他们的一个共同的特点，就是平常忙于项目开发，埋头苦干，在问题发生后，才发现许多案头工作应事先沟通解决。这种做法存在许多的弊端：
1、大家都在做各自的事情，许多工作是可以相互借鉴的，但因为工作重复，浪费了人力资源、物力资源等成本；
2、大家都在针对一种系统进行重复开发，如：一个项目组在做大集中核心系统，将综合业务系统向核心业务系统进行转变；另外一个项目组在做综合业务系统的衍生系统电话银行系统，双方都在争进度，但后果是后者的项目会很快被前者取代，但后者又为前者的开发增加了许多工作压力，有种怎么追也追不上的感觉。
Ø解决方案：
不光要“埋头苦干，更要抬头看路”。为保证沟通的及时性，要将项目沟通融入到项目运行机制中去：
1、建立通畅的沟通渠道，通过工作例会、电话、邮件、网络论坛及项目联系单等等方式，为项目问题协商建立良好的基础。
2、应事先对项目沟通进行评估，制定项目沟通计划。沟通计划决定项目干系人的信息沟通需求：谁需要什么信息，什么时候需要，怎样获得。
3、应事先对项目实施风险进行评估，制定项目风险计划。根据计划确定风险来源和类别、定义风险参数、制定风险管理策略等。
4、在项目过程中及时跟踪项目进度，做好项目报告。报告内容包括状态报告、进度报告和项目预测。
5、信息发布使需要的信息及时发送给项目干系人。将项目报告及时反馈给项目干系人，使之明确项目进展情况、项目中遇到的问题、应该采取何种措施来控制项目进度等。
CMMI是可持续改进模型，通过参照CMMI模型标准，我们可以找到自己项目过程的不足之处，不断的改进，持续的完善，从而达到加强控制完善管理的目的，这才是CMMI的精髓所在。
对于CMMI，我们也不应该盲目崇拜，它毕竟是“舶来品”，受限于企业文化背景、人员理解度、项目实施方式等实际开发情况，它严密的规范，有时可能会成为制约项目进度的阻碍。
如何将我们的国内特色与CMMI有机的结合，形成符合实际情况的项目管理及开发过程，这是我们要正视的。
