读张维迎先生的《理性思考中国改革》一文，联想到软件企业所进行的CMM/CMMI过程改进工作，颇有感想。无论相对微观的过程改进还是宏观的改革，其思考方式看来是可以借鉴利用的。

　　张先生一文的内容可以概括为四个短语：换位想、向前看、讲可行、重逻辑，这些何尚又不是在软件过程改进工作中必须遵循的思考方式呢?

　　中国的改革是摸着石头过河，参照的样板和理论都是最先由西方人创造、提出，软件开发过程中的方法、工具、理论和规范更是来自欧美大的软件公司的实践，完全由中国人提出或实践得出的东西几乎为零，即使有，也是一些边角的局部的。基于这样的环境，理性思考我们的软件过程改进工作对我们在企业中开展过程改进就尤为重要。

　　换位想：在过程改进中，过程的主导者和过程实施者都应该具备换位想的思维方式，换个角度看问题，往往能得出不同的结论。作为过程主导者的EPG，往往不是第一线的软件管理、开发人员，经常容易犯紧靠CMMI条文的错误，而不是从执行者的角度来思考设计流程。因此，换位思维在过程改进活动中极为重要，EPG不但需要从执行者的角度来思考流程设计的质量，也要从管理层来思考目标的实现成本。在推行CMMI时，所有遇到的阻力，很大程度上是由于照搬CMMI的条文，不切合项目组的实际，没有具体情况具体分析而导致的。实际上，一线的管理、开发人员最了解事实真相和实际管理需要。谁了解实际，谁就有发言权。在制定CMMI规程标准时，尤其是在制定大家要执行的操作规程、模板和记录模版时，一定要得到执行者的认同，从执行者的角度来判断过程文件的质量。如果主导者没有换位思考，仅站在自己的立场看待问题，强行利用行政力量推行，表面上看来似乎大家照规程做了，其实是表面文章，对过程的改善没有实际帮助。执行者同样应该换位思考，把握流程实施的本质目标，从而对执行的困难和问题进行更有针对性的沟通，找寻到最佳的平衡点。如果执行者能换个角度思考，站在流程制定者的立场思考，清楚地知道为什么要这么做，规范是出于什么目的，就不会出现被动执行的情况，相反能积极地影响到流程制定者，将最真实的现状告诉他们。本身，一个企业中，软件过程改进人员和执行人员应该是基于同样的目标在工作，如果大家都仅从自己位置思考问题，就容易造成执行和沟通的障碍。有些时候，导致SPI工作受阻，其混乱产生的根源在于：EPG认为是执行的问题，执行者认为都按规定执行了但体系不切实际，结果就出现出现体系和实际是"两张皮"的情况。执行者的换位思考需要在体系培训文件时激发出来，甚至更早，而流程制定者的换位思维方式，在组建EPG时就应该灌输下去，让每个人都能抛开条文，真正落地到现实执行中。

　　向前看：对于过程改进人员而言，是否具备向前看的思维方式将直接影响到过程改进工作的持续性、继承性。一方面，流程制定要符合实际情况，另一方面，在分析差距、分析改进方向时要考虑到未来的变化，这种变化包括商业目标、环境、资源和人员的变化情况，从而系统地制定过程改进计划。 在很多过程改进的案例中，EPG执迷于过去经验，执迷于现状的情况不在少数。我们会听到这样的声音：&ldquo我们过去一直都是这样做的&rdquo，&ldquo我们现在没有这个能力&rdquo，或者只是简单地解决当前的问题，而不思考背后本质的原因。向前看，是指用发展的眼光系统地看待过程改进，而不是就事论事，只着手解决眼前问题和短期目标。向前看，需要高层管理对过程改进活动定义明确的目标和发展战略，真正将过程改进活动融合到企业的战略发展中。在同行的交流活动中，发现很多企业只是谋求一纸证书，对过程改进并未定义长期的发展目标，结果在实际执行时缺乏系统性和持续性。缺乏合理的发展目标，也是很多企业过程改进时从咨询公司拿来一套模板，改改公司名称就投入使用，这样的情况屡见不鲜。

　　向前看，另一个意思就是发展的看，过程改进是改良行为，不能做成革命，不可能一步到位，而是逐步发展，逐渐成熟。因此，在过程改进中，会有反复，或有错误，需要管理层和执行层用发展的眼光看待，而不是只看到眼前。

　　讲可行：就是充分考虑ROI和执行条件。可行性一方面指操作上易于实现，流程所需的能力和资源符合企业实际情况，另一方面指执行的成本符合最优化管理原则，用尽可能少的投入获得预期的过程控制效果。阅读过一些体系文件，也听过一些讨论，发现有些文件定义得非常好，理论上论证充分，完全符合CMMI模型要求，但实际执行时成本太高，达不到预期效果。有些体系文件中，为了满足GP2.1的要求，方针政策定义得很超前，要怎么样管理规范，要怎么样。因此，在过程改进活动中，要充分考虑成本投入和可行性问题，如果为了过程改进而改进，则是舍本逐末，偏离了过程改进的本质目的。曾见过一家企业的做法，一份过程实施的裁剪表需要包括PM、QA、EPG和部门经理四种角色进行审批方能视为符合流程规定。从一定程度上看，似乎这样的控制手段可以保证裁剪表完全符合要求，但其执行成本明显过高，管理上冗余成本很高，容易走向官僚主义。在一般的投资行为中，我们总是希望投1块钱收获2块钱或更多，在过程改进中，一样要考虑ROI。就像风险管理中，如果缓解成本大于损失成本，我们根本不应该执行该缓解措施。一样的道理，如果一个流程执行成本高于收益，企业投入成本执行该流程就是负收益，因此，管理上需要一个度，不是控制手段愈多，流程愈规范就是合理的。

　　重逻辑：软件开发过程不同于一般的管理流程，既包含通常的管理方法、方式，又牵涉到具体的技术应用，所涵盖的知识领域比较广泛，因此在制定过程改进计划、定义过程文件的时候，需要将过程改进活动的范围、约束条件、边界以及流程体系与行政管理、运营管理规范和制度之间的关系从逻辑上梳理清楚。例如，在IPM中有关于工作环境的定义要求，而通常软件企业会有专门的行政制度、IT政策来定义这部分的内容，那么体系文件中相关部分的内容就必须逻辑上分清流程的边界。另外一方面，过程体系中规定的控制方式、管理办法要在理论和逻辑上遵从相关知识领域的内容，比如项目管理体系与PMP知识领域、开发管理与软件工程领域，它们要在一定程度上保持一致，有不同时也应能界定相异点的原因。这样，具备不同知识领域背景的员工在执行时，就不至于产生冲突，不至于导致员工对体系认知上的分歧和抵触。同时，过程体系内部不同文件的边界和逻辑关系也要分析定义清楚。CMMI模型本身，不同PA之间存在交叉和联系，这样，在架构体系文件的整体框架时，就需要从逻辑上分析清楚不同体系文件内容之间关联，避免重复定义、交叉引用、遗漏定义等状况的发生。 过程改进的逻辑性，一方面决定了体系文件的严肃性，体系文件是企业的管理制度之一，不适于频繁变化;另一方面决定了体系文件的专业性，就软件开发过程而言，其专业程度相对很高，制定者需要有一定的工程背景、管理背景，才能保证体系文件能正确指导到员工实施。既是制度，又是培训教材或者指导手册，因此重视体系的逻辑性非常重要。这种逻辑性需要贯彻到整个过程改进活动中，包括改进计划的制订，从没有规范的企业和有一定成熟度规范能力的企业，其中不同阶段的计划，一定存在差别，其重点不同，计划内容也应该不同。

　　在过程改进活动中，把握这四个短语的精髓，从方法论层面解决认知问题，企业的过程改进活动一定能踏实、有序、富有成效的开展下去。