今天跟客户介绍CMMI V2.0。其中一大改变，它把以前的通用实践都用治理(GOV)与实施基础条件(II)两实践域取代。V2.0更强调CMMI实践的价值和目的，及过程改进的效果。

我问：过程改进最重要的成功要素是什么？

有一位很资深的经理回答：高层的关注。

我说：很正确，但在V1.3模型没有明确写出来，现在在V2.0的治理 (GOV)实践域中，就明确提出高层应如何支撑整个过程改进。我在美国参加培训时，老师强调,不仅仅看 GOV 与 II的 practices （详见附件1），也要看v2.0的概述(Overview)；

例如：概述二列了十三条过程改进的成功关键因素：

如何成功采用CMMI (Part Two: Successfully Adopting CMMI )

• 展现出高管的积极支持 (Demonstrate visible and active senior management support)

• 让执行者参与 (Involve the people who do the work)

• 首先记录“现状” (Record the “As Is” first)

• 专注于实现业务目标 (Focus on meeting business objectives)

• 沟通，沟通，再沟通 (Communicate, communicate, communicate)

• 建立明确的改进基础条件 (Establish clear improvement infrastructure)

• 对准恰当的细节层次 (Target the right level of detail)

• 计划并提供培训 (Plan and provide training)

• 通过度量获得业务结果 (Measure to achieve business results)

• 强化良好的行为 (Reinforce good behavior)

• 管理干系人的期望 (Manage stakeholder expectations)

• 为差异定制计划 (Plan for differences)

• 变更不要太多 (Recognize change can overwhelm)

大家看到其中有“展出高管的支持”；

另外“专注于实现业务目标”也很重要。

我接着问：你们清楚高层的目标吗？

他们一起回答：2 1 1。

如果大家细读概述二，你会发现每一点都应是我们做过程改进的注意项。

从以下案例，大家便可以了解这些要素的作用。

目录

1杭州客户实例

1.1背景


1.2过程改进


1.3如何进一步改进

2不良例子

3如何可以利用CMMI V2.0 做好过程改进？

4总结

5反馈

6附件1：GOV治理与 II 实施基础条件的practices

杭州客户实例

背景

• 专门做政府部门IT项目

• 持续使用CMMI做过程改进超过６年

过程改进

今年年初，高层定了以下改进目标：

1. 信息化管理项目

2. 项目独立核算

针对一，PMO进一步推广IT项目管理系统的应用 (在上次CMMI评估后，已经购买了项目管理系统，开始只用于集成/实施项目——因研发项目因开发人员反对，到去年底，一直还是使用本来的开源BUG/任务管理系统。今年所有项目都使用了。)

针对二，以前项目经理是不需要管进度/成本，只要管技术与客户协调，从今年开始项目经理必须把项目管好，所以今年建了很多项目的标版(Dashboard)：从不同维度——收入、进度、完成程度等等来对不同项目来观察排名。

本来项目只能依赖每周手工写周报给主管来管理——项目跟踪信息分散在邮件、钉钉等，技术总监觉得这太零散，无法在一个报表里看到项目的主要信息。利用这个系统后，今年每个项目都使用项目管理工具的论坛功能，再通过一个监控小程序集合问题：

好处是所有在项目管理系统的讨论记录都不能被随意修改，操作都会留有痕迹，不会像以前人手靠邮件/钉钉提交，很难找到整个记录，通常只可看到上一周的内容。

高层也要求每个项目都要按计划活动，在系统上上传传活动的产出物，假如活动有延误，除了会被汇总到包含每个项目的标版外，监控小程序会自动引发“钉钉”提醒。例如：论坛提交了吗？周报提交了吗？每个活动的产出物（文档）提交到项目管理工具了吗?

研发主管说：以前靠主管或自己本人“手工”提醒，没有效果，原因：

1. 很繁琐，

2. 不一定被执行

公司每年有上百个项目，很难靠人工管理，现在都是利用系统，项目经理都很清楚项目的“成绩”与现状：如延误了多少，或有多少没提交。

我说:这些都挺好，起码比我在６个月前，或12个月前看到的情况进步多了，开始有一些客观数据可以帮助。

我就问他们:中间推进的过程如何?

他们说:整个过程不是一步到位，也是一步步逐渐变，才到现在的状况，如果变得太多，项目组也接受不了，到现在，他们已经习惯了这“新”做法。

我还记得，去年的时候，研发人员还习惯用“X道”系统填工时、做管理，很抗拒使用项目管理系统，现在基本所有项目自动每周/每天填写。因高层更关注每项目的情况，财务也希望更好地知道项目实际成本。以前没有系统监控实际项目成本，需要财务人员去问项目经理，项目经理也没有数据，只能猜，变成到最后才知道项目是否超支。现在，财务可以从项目管理系统直接知道项目的实际成本跟本来预算的比较，因为项目管理系统输入了每个岗位的平均成本，系统可以根据项目的工时表，自动计算实时的项目实际成本与偏差。

如何进一步改进

总监与PMO问我:你知道我们现状，有什么好的建议，让我们可以再进一步改善？

我把CMMI V2.0 的十三条，放在桌上。

我说其实你们对应这清单，已经做了不少，我们也可依据这十三条建议，再改善。

你现在这些统计的表，哪些人可以看到？他们说基本是管理层。

我说：有没有考虑把非敏感的数据公开，让每个项目经理、项目组都知道?因为我们利用度量数据，加强沟通。为什么要让他们知道呢？应把团队从一个按公司主管工作 - 提升到让团队自发发现问题所在，自我不断改进。管理者应是团队教练，而不是他们的家长，指挥他们，才更让他们有创新能力，所以我需要把这些数字让他们知道，让他们参与，分析如何改善，因他们才是天天面对客户的前线人员，你们管理层通常没有像他们熟悉项目情况。

也应该让团队多参与，我上次已建议你们加强过程改进小组，例如今年目标是提升项目管理，便应让多些项目经理进入项目过程改进小组，一起参与，不是单靠你们两自己想如何提升。你们心里可能已经想好一些好方法，但最好还是先一起讨论，在会议中你们引导，最好尽量让他们自己提出，他们才会觉得这是他们的事，而不是仅仅服务管理层。

刚才我没看到你们现在的基线与量化目标 / 商业目标，可能你们都有概念，但没有明确写出，例如：项目延误要从现在的什么水平提升到多少；每周提交多少，现在是什么情况，希望达到多少？没有明确的量化目标，所有的过程改进便缺乏正确的方向。例如，要提高项目组生产效率，降低延误，团队培训很重要，但不仅仅是项目管理系统的培训。问你们两位：“你觉得如何可以把项目的效率提升？减少延误？比如你现在用系统，有两方面你可以考虑，比如我们刚才讨论，项目延误的主因是需求常常变。

你们说有些客户变化很频繁，例如周一说了A,周二就变成B，后面有几轮变化，增加了C与D，可能最后还是觉得变回A更合适，把BCD推翻。这样的项目当然会延误，开发人员也无法集中精力。所以你们可以严格遵从敏捷2周的迭代模式，2周内不容许其他变更，才能让项目经理和项目人员专心做好项目，所有的需求变更都规定必须在2周冲刺才处理。另外，你们可以利用系统来定不同的基线，项目组的偏差是跟变化后的基线比较，而不是与最早变化前的基线比较。

但我们不能单靠他们自发， 培训也很重要，比如我以前说过如何做回顾、复盘、根因分析，现在有了数据，整个根因分析就更具体。培训也不要仅考虑传统授课形式。培训的目的是希望通过培训让大家知道新的方法应如何做。如没有合适培训，大家很可能走弯路，浪费资源。

还有什么可以提升项目组效率？

我说：很简单，尽量在早期找出缺陷，减少返工。

另外就是项目人员个人的时间管理。

缺陷管理我在之前的同行评审的文章中详细提过，时间管理你们应该都学过。

其实道理很简单，如果每个人时间都管不好，每天很多骚扰，不会集中做一些重要的事情，把它完成，整个项目管理的时间延误管理肯定不会好。所以，在做改进时，要对有影响效果的主因做改进 - 如果项目组人员做事方法没有变化，项目组便不会有提升。

不良例子

我来讲一个反面例子，让大家知道，为什么不注重这些要素会失败。

比如一政府的内部ＩＴ部门，他们也做ＣＭＭＩ过程改进很多年，但是他们管理者的心态是“不追求高分，及格就足够”。

管理层这心态便会妨碍了整个改进。比如他们希望咨询顾问帮他们更新过程，引进敏捷项目实践。

我说：好啊，你们这些项目应该不会完全没用过敏捷的方式，让我们一起了解，参与一起改善不是很好吗？

但这内部ＩＴ部门主管心态不同，比如政府项目都要招标，必须先写清楚要做什么，然后投标。他的想法是你们顾问过来诊断/差距分析，依据你的专业知识，帮我们写一套详细的敏捷流程，评审可以的话就按这个推广就可以了。

你可以看到刚才这种思路很可能失败——所有的变更不是一步到位，才能一步步让受影响的人接受。如果他们在前期，不按照他们的现状，让他们参与，他们就没有动力后面跟顾问设计的最佳流程走，最后变成一堆放在总经理书柜的无用文档。

还有他误解，以为只要写好这些流程，按这个做就可以了。

反而，刚才杭州案例的经理说，“按我们改进的经验，写过程文档太多反而没有作用，有系统支撑，按系统来走，才是有效的让他们按流程来走。”

我非常赞同。

这不良例子也可以帮我们更了解V2.0这13条在成功过程改进的作用，例如：当管理层以为CMMI就是一堆定死的过程，按着去做就会有结果。导致管理层只依赖外聘的顾问来推动整个过程改进，而他们自己没有主动参与，这类过程改进很难成功。

在制定理想的新过程以前，必须先了解现在团队如何运作，记录现状，所以让执行者的参与。希望一次性靠外部专家写一些敏捷的过程，直接在整个部门推，也不现实，因为改变人的习惯最困难，所以要注意每次变更不要太多。更新或创建新的过程，比如敏捷过程，不要想可以一步到位，一次性把所有的内容都写上，真正成功的改进都是由一步步的小变更组成。

如何可以利用CMMI V2.0 做好过程改进？

回顾你们有很明确的高层的目标211，有一系列的度量，我看你们的度量，都是一些KPI和结果导向的，没有度量可控因子，导致最后你们也说了要有一些指标、定义，说了很长时间也没有结论，因为不同事业部觉得定义和他们不合。

我说过一个要注意的地方，千万不要把度量做为一个直接绩效考核的指标，你可以想象很多度量要靠做事的人提供的，如果他们知道你这个数是和收入奖金有关，你就很难收到真正实际的数字，导致整个度量分析失效了。

你们公司也不断有做复盘。

我问：你们有利用你们的复盘数据进行度量讨论吗？

答：不多，一般是做定性主观的判断。

我说： 其实复盘或回归必须要有一些客观的数据支撑，才能知道:

1. 这些改进活动确实有效果或者没效果

2. 从以往的数据，帮我们更好做根因分析，识别出达不到目标的主因，对症下药

所以建议你们多把那些辛辛苦苦收集的数据，变成一些标版，分享给项目组，也配合一些依据数据的根因分析的培训，让他们更好实际做好那些复盘和回顾，以刚才我说的度量，你可以参考我前面说的同行评审的案例，增加一些可控因素，比如说你想控制好交付质量，你应该不仅仅度量缺陷，也要看看代码的复杂度，耦合性等，大家都知道，如果项目模块越复杂，问题很可能越多。

总结

从以上的讨论，大家应赞同度量不应该仅仅是度量结果，而且要避免把度量作为考核指标（这在上次分享的同行评审验证确认文章中也详细说明过），你们公司比较好，整个奖励的系统比较完整，当团队确实努力，做了一些改进，有成绩的话，对团队或者个人给予一些奖励，不然的话就很难依赖他们会持久地提升。

因为持续改进挺耗精力，你们为公司做质量保证，也应了解不同的事业部的差异很大，一个七千人的大公司，不可能一套度量或者改进方式就适用所有事业部。但无论如何，原理是共通的，可以借用V2.0这13条做辅导团队提升的座右铭。

反馈

以下是一总工的经验之谈，验证了CMMI提倡的数据支撑与高层参与都很重要，缺一不可：

CMMI改进没有高层参与就无法落地，始终停留在讨论和计划层面上。同样，CMMI改进措施没有数据支撑就很难得到领导的认可，始终停留在做与不做的争论之中。

从前年开始，我们向领导要求增强QA和项目内部测试力量，领导一直不同意，并反复问我们依据是什么。后来，我们收集了项目版本发布频率，项目存在问题与QA缺失的关联数据等现状的量化数据，多次反复提交给领导，领导终于同意再新增QA人员，新设项目内部测试人员。

从这件事可以印证，高层不参与，任何改进都无法推进。同样，没有数据支撑，就没有足够的说服力去撬动改进之路。

• 源文出自高等级主任评估师：宋世杰
  
  
  

附件1：GOV 治理 与 II 实施基础条件 的 practices