文/北京瑞贝泰格管理咨询有限责任公司总经理  刘宇辉

随着中国软件产业的不断发展，越来越多的企业开始意识到规范软件开发过程与软件产品质量之间的微妙关系。在这种情况下，国外近年来成功的软件研发经验和模型，如CMM(Capability Maturity Model), RUP(Rational Unified Process), MSF(Microsoft Solution Framework), XP(eXtreme Programming)等越来越多地映入了人们的眼帘。特别是近年来引入的CMM，完善的认证体系和有效的市场驱动使之成为了其中最为广泛关注的一个，目前国内已经有上百家公司通过了CMM的2级3级。但是从实施的情况来看，似乎情况并不乐观，大家都认识到一个问题：成功的软件开发过程的含义已经远远超出了传统软件工程教科书中的简单软件生命周期，瀑布模型等等的内涵，甚至已经超出了单纯技术的范畴。于是越来越多的高层领导在倡导软件产品过程改进的同时，逐渐开始关注文化的问题。我认为对于软件企业而言，过程改进的过程就是企业文化重塑的过程，这个过程虽然艰难而又漫长，但确是一个营造良性循环的过程，有了文化做基础，过程改进会非常顺利，而持续改进的实施对营造良好的文化氛围有会起到推波助澜的作用。

本文主要结合过程改进的几个关键过程域，谈谈过程改进与企业文化重塑的关系。

让我们先来看看软件企业的特点。

软件企业目前的工作特点

某公司为了拿到该项目，在没有经过认真的分析和估算的情况下，承诺在半年内完成项目的实施，并只提出了竞争对手一半的项目经费。招标公司考虑节省成本并且看到该公司有几位具有多年编程经验的高手，最终和该公司签订了项目合同。由于项目时间紧迫，该公司在作了简单的用户需求调研后就开始了编码工作。为了保证项目的质量，项目由该公司最好的程序员来设计和主持。在项目初期的一个月中，各个子模块的进展很快。随着项目的规模越来越大，该公司在项目中投入了更多的人力。由于缺乏前期的规划和文档，新的程序员花了大量的时间和精力来熟悉已有的编码都不得要领，以前的程序员不得不停下手头的工作来讲解系统的设计思路和实现方法，整个项目的进度慢了下来。招标公司感觉到了一些问题，不断地敦促该公司加快进度，而且在这个过程中，发现系统的设计和当初的设想有较大的差距，于是提出了很多修改的建议。该公司感觉到了很大的压力，但为了保住这个订单，公司发动大家每天加班修改设计和代码。持续了几个月后，大家都精疲力尽，眼看半年的限期将近。该公司只得放弃很多原来设计的功能，开始集成系统的各个模块。但是更大的问题发生了，好不容易集成在一起的系统一运行就发生了严重的系统崩溃和数据丢失。带领系统开发的程序高手经过几天紧张的调试，发现问题是由于最初设计时的重大失误造成，解决这些问题不得不修改一些基本的数据结构，但赶在半年的项目验收期之前是不可能的。

软件企业中人的特点

软件行业是我们大家都公认的高智商领域，从事软件研发工作普遍被认为是一个崇高的职业，而衡量某一个人是否适合这个领域，衡量他的工作绩效，主要是看他的技术水平，所以现在在谈到过程改进中软件度量的概念的时候，人们首先想到的技术代码行数，bug数，而且认为只要有这些东西，就是做了度量工作，更有甚者，在有些企业中，技术总监们甚至把这些数据和个人的薪酬挂钩，弄得人人自危。归结这种现象正是由于该行业的高度专业性造成的，根据哈佛大学的一项调查，技术导向性的企业多数属于分裂性的组织，该组织明显的特点就是员工表现出较低的组织成员意识，他们通常认为只是在为自己工作，或者他们只认同职业团体，通常是专业团体；在工作行为上，分裂组织成员多喜欢独自闭门工作，与同事之间的交往极少；相互之间很少就组织目标、成功的关键要素以及工作绩效标准达成共识，组织内和睦程度很低。 分裂型组织听起来像是一种非常恶劣的办公场所，管理人员都不愿意为一个分裂型组织工作，但是，正如黑格尔所说，凡是存在的，就一定有它存在的合理性。在这个领域，我们也走访了很多家公司，他们普遍认为的确存在着要求建立这种文化的必要，甚至是更加极端的情况。我想老板们在说这种话的时候，可能也多少有一些无奈的情况。

事实上，研究发现，分裂型组织能够成功运作，因为那些训练有素的专业人士具有独特的工作风格，而且工作本身几乎不存在相互依赖关系，工作主要由个人而不是小组完成，通过控制投入就能达标，个人之间几乎没有互相学习的机会等。对于多数中小型的软件企业，在创业之初，正是这样一种情况造就了这样的文化。同时我们可以假设如果企业可以一直保持着这种小的状态，这种文化也可以一直保持下去，当然也没有必要进行什么过程改进。正是因为我们的企业做大了，人多了，发生了象上面介绍的那些问题的时候，企业才会考虑进行过程改进，现在我们就以实施CMM为例，来分析一下过程改进为什么举步维坚。

不管业界对CMM持怎样一个看法，基于我个人对CMM的理解，我认为CMM作为一种机制，非常适合大中型软件企业的成功运作，今天这里不谈东西方文化的差异，只谈谈人和事。

同行评审

CMM中所倡导的同行评审，主要是利用人和人之间的差异性在产品生产各个阶段的早期发现问题，从事节省修复成本，提高效率。这其实是CMM实施中最容易实施的一个关键过程域。但在企业里我们听到了什么声音？太忙，没有时间！在分裂性的组织中，评审即使做了也一定会流于形式。试想，如果在一个崇尚个人绩效的环境中，我们又怎么能期待我们的员工心甘情愿的去做一些看起来对个人没有直接影响的工作呢？

配置管理

配置管理是CMM中的中心环节，讲的是利用技术和管理的手段来标识和记录各配置项的功能和物理特性，控制其变更，记录和报告变更的过程和实现的状态，并检查与特定需求的符合性。（IEEE对SCM的定义）。越来越多的企业开始谈论配置管理，引入配置管理工具，似乎没有人怀疑其有效性，但同时又确实看不见什么效果，为什么？配置管理是整个过程改进过程中和开发人员关系最为密切的一个KPA, 我发现一个有趣的现象，有不少企业中不乏一些技术人员在一段时间之内，热衷于配置管理，为什么？一个最主要的原因，可以解释以上两个问题，配置管理被当成了一项技术！很多人认为弄通了clearcase, clearrequest是可以提高一个技术人员的身价的，很多企业认为上了复杂的配置管理工具是可以体现公司形象的，可是大家同时忽略了IEEE的定义中说配置管理利用的是技术和管理的手段，因此对于更多号称进行着配置管理的企业而言，不如说仅仅在使用配置管理工具而已，而且大多数企业不过是用一些工具进行版本管理罢了，还谈不到是一个完整的配置管理。因此说配置管理看不到什么效果也自然在情理之中了。

软件度量

软件度量应该说是CMM的核心，也是西方量化细想的体现，对于习惯于宏观思维的东方老板们确实不是那么容易被接受的。我认为这还不是最主要的。我在前面提到过了，有不少企业一谈到度量，首先想到的代码行，bug，没错，这些数据非常重要，我们必须收集，但是如果我们只关心这些数据就有可能犯一叶障目，不见森林的错误。然而我见过太多的技术总监抱着技术不放，而忽略了人和环境的因素。我们度量的目的是什么？是为了提高效率，如果我们可以度量出我们每一次同行评审的时间和工作量之间的关系，就可以提高同行评审的效率；如果我们对整体项目的工作时间和工作量进行统计，对下一次同类的项目把握就会更大一些。其实，我认为度量的效果本身不在乎你度量什么指标，而在于你如何看到度量的目的。我们在咨询过程中，经常会被问到需要度量哪些数据？其实我认为这并不重要，倒是我们要这些数据干什么？作为软件企业所有支持过程改进的领导，如果不能从技术这个狭隘的圈子里走出来，支持过程改进不过是一句空话罢了。

以上几个KPA只是一些具有代表性的过程，通过对这些过程的分析，我们不难看到，在技术改进的同时，无处不体现企业文化的变革和重塑。如果组织依然是一个分裂性的组织，如果企业的领导仍旧纵容技术至上的精神，那么过程改进注定是要失败的。对于大多数软件公司的老板，主要有两类，一类是具有市场背景的，这类领导更容易纵容技术人员，因为他们基于技术人员更懂技术的假设，相信包容个性是对员工最好的激励，这是在助长组织的分裂性；另一类老板是技术背景，整个公司的技术核心是老板带头弄出来的，这类老板很容易事必躬亲，使自己陷于繁杂的细节工作中，而忽略了对整体战略把握的能力。这是两种极端具有代表性的现象。其实，什么叫公司文化，就是公司最高层的处事方法，公司文化的重塑，更重要的是领导观念的转变。这种转变说来并不容易，但也不是无章可循，根据我们的经验，我认为就是一方面让企业内部更多的技术管理人员有计划，有步骤的在关注技术之余，接受更多管理方面的培训，给他们关注下属，关注环境的时间，另一方面就是加强制度的约束，流程的约束，杜绝纵容技术人员我行我素的现象，尤其对于企业的技术精英。在这方面，像Motorola，IBM外企有很多值得我们借鉴的地方。

具体有一些和企业过程改进相关的企业文化再造的方法，比如：招募一些兼容性强的人（那种既懂技术，又看起来很可能自然地成为朋友的人）和其他的员工提高分享思想、利益以及感情；组织办公室内外的比较随意的聚会活动，比如晚会、远足甚至读书俱乐部等等，来增进员工之间的社会接触；管理人员对员工要像对朋友一样，关心有困难的员工，树立一种和蔼亲切的榜样形象等等。另一方面，我必须强调的是，严格的对流程进行约束，不要担心下属以完不成任务相威胁，只要前几项工作做的到位，过程改进的工作还是比较容易推进的。谁说大象不能跳舞？