CMMI证书到手了之后，企业还要做些什么？
CMMI认证进入我国软件领域的这十多年来，对我国软件产业的健康发展作出了巨大贡献。但一些软件企业只是以获得证书为根本目的，而忘记CMMI认证的出发点是改进软件生产过程。
这致使我国一些通过CMMI5级的企业的项目平均延期率依然在25％以上，并且数据并不稳定。尤为不幸的是，目前没有任何公开数据表明我国通过CMMI高级别认证的企业，提高了生产效率，降低了成本，提高了产品质量。
CMM/CMMI在中国的过程改进领域到底是一个伟大的经典还是一个因水土不服而失败的理论？CMMI后的软件过程改进又将如何演绎？
CMMI（Capability Maturity Model Integration, 即能力成熟度模型集成模型）自20世纪90年代中期传入中国以来，有些软件企业只是一味地追求高级别CMMI认证，以为拿到更高级CMMI证书就获得了进入外包市场的国际通行证，而忽视了对软件生产过程真正持续的改进。从而导致CMMI认证在中国出现一些令人担忧的现象。
怪相一：证书摆桌面 体系放一边
2006年笔者曾到某软件园进行调查，对通过CMMI评估的8家企业进行走访，发现有5家企业在通过评估后基本上放弃了。CMMI评估的证书高高挂在墙上，做过程改进的人员已经不见踪影，企业也不再按照原来的体系执行了。其实这5家企业本就没想真正去改进过程。那为什么还要去做CMMI评估呢？因为企业有补助。
2000年有关部门鼓励软件企业做CMMI评估。不少地方鼓励企业实施过程改进，并陆续出台资助政策。当企业通过评估后，可从不同部门获得资助。有些企业为拿到资助，突击通过CMMI的评估，于是便出现了“证书摆桌面，体系放一边”的现象。
其实企业失算了。企业获得的资助大都给了咨询公司。企业要编制体系文件和项目的直接与间接证据，要安排人员接受访谈。这都要耗费巨大的人力和物力，其成本可能超出资助金额，所以企业的实际投入也很大。那些一心想要补助的企业得到了什么呢？对他们有用的估计就剩下一个证书了。
怪相二：证书拿到手 体系大调修
笔者曾接触过两家企业，在通过CMM或CMMI评估后，在很短的时间内就对过程体系进行了大幅度的裁剪。其中一家公司的负责人讲：“原来定的体系太烦琐，为了通过评估，我们原来忍了，现在必须裁剪！”难道只有烦琐才能通过CMMI的评估吗？难道简约就不可能通过CMMI的评估吗？
这是对CMMI的误解！
在CMMI的各种构件中，只有目标是必需的，实践是期望的，子实践是解释说明的。所以首先要满足模型中每个目标的要求，目标的达成是根据实践的执行情况来判断的，模型中给出的实践是可以替换的。只要能达成目标，采用什么实践都是可以的。
CMMI评估要求主任评估师必须具有10年以上的软件工程经验，评估组的成员必须平均具有6年以上工程经验，评估组累计不少于25年工程经验，每个生命周期阶段要有两个人具有实践经验，至少要有一个成员有6年以上的管理经验，评估组累计要有10年以上管理经验。这些要求其实是为了更好地进行专业判断，避免机械照搬。
CMMI要求企业建立裁剪指南。在实践中，裁剪指南往往比体系本身更重要。僵化的体系是不可能真正在组织里推行下去的，要保持体系的灵活与敏捷，就必须定义详细的、实际的裁剪指南，并在实践中逐步完善。
简约与烦琐都可能达到模型的要求，关键取决于起草体系的人员对模型的理解。企业在开始导入CMMI时，一般是请咨询顾问介入，而目前国内的CMMI咨询公司、咨询顾问鱼龙混杂，客户难以在短时间内做出正确的评价，往往依赖某些网站或协会之类的独立组织的推荐，根据网民投票所选出的“咨询公司排名榜”按图索骥。如果咨询顾问对模型的理解不深刻，自身的过程改进成员又欠缺经验，或者咨询顾问参与的工作量很少，则难免怪相横生。
怪相三：工期依然拖 缺陷照常多
某企业实施CMMI到一定阶段后，EPG抱怨领导意识有问题，领导在言谈举止中对过程改进的支持力度不够。而领导却说该授权的也授权了，该奖励的也奖励了，该惩罚的也惩罚了，但是项目依然拖期，仍然存在质量问题，就认为EPG没有解决核心问题。
问题究竟出在什么地方呢？
过程改进的目的可以概括为“多、快、好、省”：多，即项目组能满足客户的需求越多越好，企业能承接的项目越多越好；快，即能够提高企业的估算能力、应变能力，使项目能够按期完工，减少拖期现象；好，即提高交付的产品质量，减少售后维护的工作量；省，即降低项目的开发成本，提高企业的赢利能力。
对于不同企业而言，在上述4个目的中可能侧重点有所不同。当实施过程改进时，一定要紧紧围绕企业的改进目标做工作，针对企业领导关注的问题、企业最薄弱的环节实施改进，这样才能事半功倍，快速见效，否则见不到实际效果，任何管理方法都不会长久，任何领导也不会持续投资。
很多情况下，企业在过程改进时，找到了病根，却没有找到有效的解决方案。比如单元测试和代码走查是提高软件质量的有效措施，已经在工程界得到了充分认可，但是在软件生产企业中推广时，往往会遇到开发人员的阻挠。开发人员会认为做单元测试与代码走查浪费了大量的时间，不如直接做黑盒的功能测试更简单。业内认可的最佳实践在企业中未必推行得下去。这就需要EPG成员采取各种各样的手段，努力使这些业内的最佳实践变成企业的最佳实践。上面提到的EPG与企业领导之间的互相抱怨问题，很大程度上归因于此。
怪相四：文档一篇篇 不见有人看
有一家已经通过CMMI3级评估的软件生产企业，完成一个项目需要项目组填写接近90份文档。当笔者去做CMMI的差距分析时，发现在那些文档中有大量显而易见的错误。而这些文档还要给项目经理、QA人员及高层主管等多个角色去看，却没有人发现这些很明显的错误。其实这些人根本就没有去看这些文档！既然没有人去读，何必要写呢？
CMMI评估需要企业提供3种证据：直接证据、间接证据和人证。每条实践都必须有直接证据。直接证据包括了产出的文档、使用的工具等等。由于直接证据是必须的，于是，为了满足评估的需要，很多企业做了上百个文档来满足模型的要求，其实这是不对的。模型是强调直接证据，但是并非文档越多越好。文档只是用来证明某个实践你做到了，只要达到了这个目的就可以了。而且一个文档可以满足多条实践的要求，可以作为多条实践的证据，这是最经济的做法。只要内容有了，也并非在乎文档的多少与格式。
实施CMMI之前，项目组往往不写文档或者很少写文档；实施CMMI之后，写的文档又可能太多—这是两个极端，需要平衡。