近2~3年来，软件能力成熟度模型在中国得到了广泛的重视，也进行了一些实践，但是总体效果并不令人满意，一些已经通过了CMM评估的企业的情况并没有得到应有的改变，其中的原因，让人深思。就Neco博士来看，这其中固然有一部分守旧的软件开发和管理人员对于先进管理模式的排斥。但是，更多情况下，是CMM的实施者不了解这个变革的艰巨性和复杂性，忽视了对CMM实施至关重要的一些方面。

Neco博士在此总结了一下，结合案例和大家探讨。

1. 实施CMM是公司层面上的战略行动

Neco博士认为，CMM是典型的“一把手工程”，必须由企业的负责人亲自主持。这不仅仅因为需要一个权威来克服CMM的实施中遇到的重重阻力。更深层次的原因是，CMM的实施将对公司的整体经营以至于核心竞争力产生影响，需要企业的负责人全面考虑。

企业实施CMM，从整体上来说，无疑将提高研发能力，降低缺陷，缩短产品周期。但是在具体实施的时候，却并非一定如此，或者说在每一个阶段都是如此。有研究证明，企业在实施CMM2级的时候，会出现不同程度的产品周期加长，客户满意度下降的情况，到了3级，这些情况才会得到解决。那么企业如何协调各方面的资源来度过这个难关，或者如何选择最合适的策略让企业受到的冲击最小，这都是第一决策人必须考虑的问题。

而且CMM所规定的仅仅只是一些抽象的条文，企业在具体实施的时候，有许多灵活的选择，这就需要结合企业的实际来进行，否则将会产生我们所不期望的后果。

以下就是一个案例

案例1：V公司和竞争对手相比，在技术上并不占有优势，于是V公司采用了“快速响应”的策略。无论是面对瞬息的市场，还是多变的用户需求。V公司总能够抢先于竞争对手推出产品，为此受到了市场的肯定。但是V公司在实施CMM的时候，却错误地选择了“瀑布式”的开发模型，加上相对复杂的实施流程，如果研发体系严格按照要求去做，那么对市场的响应速度必然大大降低，企业的核心竞争力受到威胁。但是如果H公司坚定“快速响应”的策略，现有CMM的实施就无法有效进行。V企业走入两难的境地。

V企业实施CMM并没有错，错的是他们在实施CMM的时候并没有考虑到企业的核心竞争力和总体战略，采用了错误的生命周期模型和相对复杂的实施流程，最后导致了这样的结果。

对公司的战略影响是一个方面，另外一个方面是，CMM的实施涉及到机构的重组，如果我们不能在组织架构，薪酬待遇，绩效考核等方面辅助以适当的政策的话，CMM的实施不可能顺利进行。

下面的案例可供参考

案例2：W公司为了推行CMM，组建了独立的QA部门。尽管在W公司的内部宣传材料上对QA的作用进行了大肆的宣传，认为其对于CMM的推行和项目管理都具有重要作用，但是实际上QA人员的资历都相对较浅，对开发过程，技术和工具都缺乏必要的了解。只能够照搬一些条文来要求开发人员，开发人员对此并不认账，认为QA人员是没事找事。另外，QA这个岗位在薪酬和升迁方面毫不吸引人。

为了避免QA部门成为新手和项目组淘汰人员的集中地，QA部门经理设法推行项目经理锻炼制度，让项目经理到QA部门锻炼一段时间，然后继续担任项目经理或者升迁。但是因为此项制度没有得到有效的支持，项目经理在QA部门工作一段时间以后竟然没有开发部门愿意接收，就更谈不上升迁了。QA部门在W公司的威望江河日下。

QA人员对于质量保证和CMM的实施至关重要，如果我们认可QA人员对于公司的价值，那就必须在人才和待遇上向QA部门倾斜。

2. CMM的实施要求行为习惯和企业文化的转变

Neco博士经常给别人进行CMM的培训和咨询，通常咨询者所关心的都是一些技术性和文档性的工作，诸如“我要编制如何的文档才能满足CMM的要求？”“你能否给我提供设计文档的检查表以及模版？”之类的问题，他们把CMM看作是条文规范一类的东西。

但其实呢，CMM要求的是企业行为的转变，是企业文化的变革。条文再精美只是条文，如果没有人去执行，它就一钱不值。

一般认为，要想在企业中很好地推行CMM，组织文化必须认同以下观点

　如果在推行CMM的时候，不辅助以文化改变的策略和行动，改革将会遇到阻力。

案例3：S公司在推行CMM 2级的时候遇到了极大的阻力，项目经理对估计和计划过程根本不感兴趣。其原因在于S公司有“倒排计划”的习惯做法。

项目经理对项目的进度安排没有决定权，当项目经理接受任务的时候，项目的发布日期早已确定，而且项目经理做出的人力资源请求一般也不会得到满足，项目经理被迫在一个资源短缺的环境下开展工作。既然Deadline已经确定，增加人手又不可能，项目经理怎么会对估计和计划有兴趣呢？

与此相对应，S公司的内部宣传材料在不断地表彰在资源短缺的困难情形下做出成绩的经理和开发人员，对“无原则服从命令”行为的赞许，已经成为了公司文化根深蒂固的一部分，并且得到管理层的默许和鼓励。

S公司的文化和CMM的要求是抵触的。CMM要求项目经理对任务的合理性进行分析，要求在理性的基础上做出判断，而不是盲目地服从。如果S公司不能够改变他们的文化，CMM就不能够得到有效实施。

3. 避免官僚主义的陷阱

CMM最初来源于美国国防部，从SW-CMM到CMMI，几乎都是按照军火商量身定做的。众所周知，武器研制项目一般都是大型项目，人数众多，预算高昂，对可靠性要求极高。在这种项目上产生的实践，必然有很多是不能应用到商业企业，特别是中小企业上面的，虽然SW-CMM的条文具备足够的灵活性和抽象性，但是一个没有经验的咨询师会很容易地受到误导，建议企业实施一个官僚气十足，步骤繁琐的管理框架。

案例4：A公司是一个小型公司，但却采用了一个步骤繁琐的CMM实施方案，而且没有采用任何自动化的过程工具，大部分由纸面文件传递来进行。比如在测试中如果发现了一个问题，必须由测试人员找到文件模版，填写好缺陷的种类和描述，打印出来，交给相关人员签字，开发人员的修改结果就只好填写在纸面上，最后还要找项目经理签字。相关人员浪费在文件传递上的时间可能比进行开发和测试的时间还要长。

以CMM为模型制订管理框架，其本质是为了规范管理，减少错误的发生。而执行这些管理规程，就其本身而言，并不是我们的目的，而仅仅是一种手段。对这些规程的执行也不创造任何价值。在条件许可的情况下，我们要尽可能地简化手续，提高效率。并适当地引入自动化工具。像A公司的情况，用一个缺陷追踪工具就可以大幅度地提高效率。

4. 技术和管理一样重要

CMM不是万能的，CMM针对的仅仅是过程管理中的问题，在软件开发中有许多问题并不是过程管理方面的纰漏，我们在改进过程管理的时候，一定要辅佐以先进的软件工程手段。中国实施CMM的特殊性在于，国内的软件企业不仅仅在软件过程管理上存在严重的不足，在具体的软件工程的理论和实践上也存在缺陷，一些软件企业甚至没有独立的测试部门和专职的测试人员，在这种基础上，如果仅仅建立一个软件过程管理框架，其实并不能为企业带来多少实质性的好处。

案例5：T公司M项目组的成员工作非常辛苦，但是回报和付出不成比例，M项目组在经历了十几轮系统测试之后，缺陷数仍然得不到收敛。QA人员试图通过加强代码评审等方式来提高质量，但是收效甚微。

原因在什么地方？M项目是在S项目的代码上修改的，而S项目的代码来自于C项目，C项目是H公司最老的项目之一。经过了几轮开发人员的修改和增强，C项目原来的软件架构已经千疮百孔，开发人员在上面进行缺陷的修补和功能增强，要付出数倍于平常的代价，而且经常引发其他问题。项目经理一语中的，“这些代码太旧了!”

W项目面临着“设计退化”（Design Deterioration）的问题，在这种情况下，W项目组应该有针对性地对某些软件架构的某些部分进行重新设计。而T公司也应当进行考虑，如果这个最早来源于C项目的平台仍然有利用的价值的话，专门成立项目组对其“翻新”是非常必要的。

下面这个案例可能更有代表性：

案例6：H公司和Z公司都在研发相同类型的C产品。H公司在推广CMM，采用了相对严格的过程规范，并且把相对重要的部分外包给了印度的CMM5级公司。这些手段Z公司都没有采用，但是Z公司却抢在了前面。

Z公司的“秘密武器”是一种形式化语言—SDL，Z公司采用SDL作为设计工具，这样C产品的相当一部分代码可以由SDL工具自动生成，而且在设计阶段就可以进行仿真运行，这样就大大地提高了效率并减少了缺陷。H公司虽然采用了相对严格的过程规范，但是因为全部代码为手工编制，所以，无论是效率还是质量，H公司都落后了。

H公司显然忽视了先进技术可能为生产率带来的进步，通过了CMM高级别的评估，只能说明被评估的组织机构在过程控制上做得更加细致，但是并不能够保证你的开发过程是高效的。某些沉迷于CMM的组织机构忘记了先进的软件工程技术的重要性。

5. 重视企业自身的实践，重视细节

CMM的实施者容易犯的另外一个毛病是不注重企业自身的实践，尤其是一些细节。他们往往热衷于参加各种讲座和培训班，希望从美国或者印度人那里发现一些灵丹妙药，以为照搬一些条条框框就能够让生产力突飞猛进。却不去关注企业当前遇到的问题，不去倾听一线人员的呼声，不注意提炼和总结企业运作中的经验和教训。

案例7：G公司的B项目组是一个分布式系统，这种项目在G公司极为普遍，各个模块之间通过TCP/IP协议互相发送消息包。在高层设计阶段，B项目组的两个工程师发现，B项目组的子系统C和子系统M采用的消息格式有很大的不同，子系统C采用字节型（8位）作为消息的ID。而子系统M采用短整型（16位）作为消息的ID，在系统运行中必然会出现问题。两位工程师通过电子邮件发出呼吁，要求重视这个问题，但是没有引起关注。最终在几个月之后，项目经理意识到了问题的严重性，项目组不得不花费一周的时间来进行修改和重新测试。

对于这个案例，大家通常会认同“倾听和理解”的重要性。但是精明的过程管理专家会有更深刻的思索。既然类似项目在H公司极为普遍，那就有必要在开发规程中制订条例，要求项目组在设计阶段必须统一消息格式，并给出指导，否则这种问题还会重犯。

这一点在下一个案例中体现得更为明显。

案例8：H公司的B项目是一个庞大的项目组，技术相当复杂。名词术语很多，而且对于同一件事物的表达方式也不尽相同。项目组非常有必要制定一个规范的术语表，既统一了说法，也方便项目组的新人查阅。但是事情的发展是很有戏剧性的。

项目组在起初并没有重视术语表的编制，因为人少，产生的文档也不多，所以这件事情无人重视。但是到了项目进展了1/3左右，术语的混乱已经相当严重的时候。B项目组的一个工程师X自发地开发了一个小程序，用于查阅术语的名称和缩写。项目经理对X工程师的做法提出了表扬，并委任X开发和维护这个标准术语表。

项目经理和相关部门的始终没有意识到：（1）开发和维护这样的标准术语表是项目经理和配置管理人员的职责，不是某一个软件工程师的任务。（2）类似的问题在别的项目组一定出现过，以后的项目组一定也会遇到，必须在开发规范上堵住这个漏洞，让别的项目不会重蹈覆辙。

所谓的“管理无大事”，过程管理的真谛就在于这些看似细节的小事。基本的过程管理原则和规范只是“骨架”，而“血肉”是要靠这些看似细枝末节的小事来丰满的。积沙成塔，集腋成裘，点滴持续地改进，其效果最终是巨大的。

对细节的忽视在国内的IT企业几乎随处可见，下面有个案例

案例9：Neco博士曾经审查过M公司的W项目，W项目是一个用Visual C++开发的项目。但是W项目组对于代码文本和目录结构都相当漠视。W项目组所属的部门有一个编码规范，但是几乎没有人看过，也没有人愿意遵照执行。W项目的C++代码混乱不堪，不仅毫无美感可言，而且成为BUG滋生的温床。M公司对开发人员使用的工具几乎没有什么限制。在国内盗版泛滥的大环境下，获取开发工具几乎是免费。所以在M公司，选择工具是很随意的，开发人员甚至可以按照个人的好恶进行选择。这造成了维护的极端困难，而且因为开发工具太多，公司无法集中资源进行培训和指导，所以开发人员的技能无法获得有效地提高。

6. 总结和建议

了解企业的现状，对症下药

实施CMM其目的是为了解决企业目前存在的问题，为了增强企业的核心竞争力。要解决问题，那就首先要知道企业目前面临的问题是什么，要明白我们采用CMM这个工具能够得到什么。以下有个案例：

案例：H公司的C项目组是一个大型的项目，而且因为C项目是一个复杂的分布式系统，所以各个子系统之间的接口和消息交互就显得特别重要。

但是C项目组的配置管理人员却不把接口作为一个单独的配置项来管理。C项目组配置项仅仅是整篇文档或者一段代码，这样就为接口的变更带来了极大的麻烦，为了避免麻烦，开发人员只有在接口发生了足够多的变更之后才会更改配置库中的接口定义文档。这样就影响了相关人员获取信息的及时性，而且他们要查阅整个接口定义文档才能够确定和自己有关的接口是否得到了修改。

项目组的成员仅仅把配置管理库作为一个“档案库”来使用，而采用邮件通知的的方式私下协商和通知接口变更情况。那么实际上等于接口变更失去了控制。

循序渐进，不可操之过急

案例：Q公司在实施CMM的过程中，采用了合适的策略，那就是针对当前重点，循序渐进。Q公司的产品用于比较关键的场合，但是因为不重视质量，所以出了几次事故，影响了公司形象。Q公司在改进之初，狠抓了测试，建立了测试队伍，对系统进行了仔细的测试，这样在其产品的下一个版本上就仅仅出了一次不重要的问题，公司上下对改进的效果都很认可。这样他们借机进行了文档的标准化，开发人员也很高兴可以通过文档从以前的项目脱身，在第二步成功的基础上，他们又开始关注需求过程的改进……