和朋友志刚每每谈到公司的标准过程规范，就都颇有些愤愤不满起来。公司和软件所互联网实验室有密切关系，互联网实验室主要研究方向是软件工程，培育了一批过程改进方面的“专家”。公司刚成立一年，但因为是从实验室里走出来的，实验室前几年过了CMMI四级，因此公司虽然刚成立，却也成立了质控部、测试部、开发部等等，同时必须遵循一套为CMMI四级组织制定的过程规范。然而实际情况是，开发团队最近重组，一切还处于比较混乱的阶段，根本达不到CMMI四级规范的要求，现在却被迫去执行，因此不少开发人员都有抵制情绪，有抵制就有冲突，这造成开发效率降低，大家都不愉快。

静心想想，过程改进确实是非常好的工程实践，但如何实施过程改进，如何有效愉悦的推行过程改进，感觉目前公司的做法还存在许多不足。下面列举一二：

首先，过程改进应该是自发的而非强迫。譬如要开发人员写文档，最好的办法应该是“诱使”开发人员去写，要让开发人员认识到写文档能让自己获益，对自己的技术和发展都有好处，要说之以情、动之以理，从开发人员自身的角度而不是从公司的角度去谈写文档的好处。这样的话，相信绝大部分开发人员都会很乐意去写文档的。而且只有这样，才能保证文档的质量。现在公司里，感觉质控部这点做得不够好，甚至有时还会拿“这是公司的规范，大家都这么做，为什么你不这么做”这种不是理由的理由来强迫开发人员。这种说辞，除了会加剧冲突外，不会带来任何好处。

其次，过程改进应该是渐进的而非跳跃式。实施过程改进前，最重要的一点是要去观察团队目前处于哪个阶段。如果团队还处于较低级别，就不应该将高级别的规范硬性推广。目前国内的CMMI过级大多只是噱头，真要实施过程改进，首先就得评定出团队的实际级别，然后根据实际级别去推行相关的规范，这才会真的有助于团队的发展。目前我们公司的开发部，就我的观察来看，最多处于CMMI二级水平，但却被迫戴上CMMI四级的镣铐跳舞。在这种镣铐下，舞会除了唉声怨气，是不大可能有愉悦的氛围的。

最后，过程改进应该是一种互动过程而非执行规范。制定规范，不应该只是监察者的职责，而应该和规范的执行者也密切相关。对于我们公司而言，质控部制定了一套标准规范，简单开个会介绍下，开发部就得执行，缺少一种从一开始就互动的过程。这样制定出来的规范，必然会在执行时受到质疑和抵制，这就很难达到预期效果。希望质控部在制定规范开始时，就应该让开发部也参与进来讨论；同时开发部在执行规范时，也应该得有一套有效的机制来保证规范能根据实际情况做修改。这样，规范才能真实有效，如果规范是开发人员自己参与制定的，都喜欢上了规范，还愁规范的执行么？呵呵。

上面三点可能都有点太理想化了，但真的希望公司能对过程改进本身做一次过程改进，高效愉悦的管理和开发软件，这都是大家热切期望的。