【IT168 分析评论】

    －研发过程改进的6sigma之实践

    有人说6sigma给了我们一双善于发现的眼睛，那么我们现在用这双眼睛看看CMMI在研发过程改进中做得怎么样。

    首先要做的是策划，识别改进机会，确定改进的方向。从组织的高级流程，到一个一个研发过程域；从组织的高级管理单位，按照组织结构逐级分解任务和目标，直至个人。这个过程可以用6sigma在定义阶段的方法来做：关注提高客户满意度，关注提高企业绩效，分析关键流程，找出薄弱环节，从Y到y，确定关键质量特性，明确现状与目标。也可以按照CMMI的OPF来做：建立组织的过程需求，评估组织过程能力，识别改进机会，计划、实施这些改进措施，并发布改进效果。

    我们现在的做法基本上是按照OPF来做的：应用CMMI的SCAMPI评估法，对组织的CMMI过程域的满足程度进行度量。每个过程域经过查阅组织资产库、过程数据库，以及访谈，给出满足CMMI的符合程度：FI——完全实施，LI——大部分实施，PI——部分实施，NI——未实施。每个过程域的特定实践和通用实践均可以用此评价，一般FI与LI的评价含义是合格，PI与NI是不合格。那么如果将每个实践作为一个缺陷机会，被评价为PI与NI的实践是一个缺陷，就可以度量出此组织符合CMMI的某个成熟度等级的缺陷率。组织追求CMMI的某个成熟度等级的达标就可以此为起点，降低过程域的缺陷率到SCAMPI的通过标准，识别出需要改进的过程域和实践，逐个制定改进计划、分派职责、落实与跟踪。

    两种改进策划，同样执行了从高端、全局出发，识别出改进的机会，之后有改进行动的具体计划和实施。不同的在于，6sigma强调从最终客户出发，强调改进活动投资收益比，所以用数据说话，有财务收益可以衡量。而过程改进的财务收益衡量，更依赖于此组织已经建立的财务收益衡量方法，如一个过程的收益如何计算？过程指标改进的程度，如何衡量其收益？这方面我们的方式还不够健全，所以在过程改进策划时，没有考虑到投资收益比。而CMMI的改进方式，如果组织处于4级以下，一般来讲数据基础是比较薄弱的，用数据辅助决策改进方向，也还做不到。也有人认为，组织的高级管理层，下达追求CMMI的某个成熟度等级的达标就是已经高层决策好的改进方向，我们只要想办法做到就可以了，不必追究其来源。但是黑带的责任是帮助组织思考，要敢于发问：“为什么要这样做？”如果方向错了，越好的执行带来的组织损失越差。

    两种改进方式的差异，已经决定，研发过程改进如果采用CMMI的方式，必定会比强调量化和逻辑严谨的6sigma方式松散一些。这是好还是不好？需要看我们的研发过程现状，因为衡量一种做事方式是否有效的唯一标准，是它是否“适合”现状，能够达到改进目标。在我们的研发过程数据不严格、过程改进的财务衡量方法不健全的现在，如果要求严格的数据和逻辑，要求严格计算财务的投资收益比，以及6sigma的理论和工具使用技巧，势必会提高了参与改进的门槛。许多本来有热情做过程改进的研发人员被阻隔在这个门槛之外，把过程改进的工作又丢回给EPG自己承担，造成EPG与客户的隔离，使得研发过程改进更加困难。与之相比，采用CMMI的方式，显然启动更容易，对于研发人员也更容易接受，最近的非常好的实践评比活动证实了这一点。同样做了改进活动，非常好的实践与6sigma项目相比，同样解决了产品顽疾或者流程优化，然而无需为此新建度量机制，而且只关注于做自己最熟悉和擅长的本职工作，总结文档也不需要为了满足认证的要求而穷心竭力，只要简单地说明问题来源、解决思路、特点与推广建议即可。如此的轻装上阵确实有吸引力，每个月层出不穷的案例提交到评审委员的案头等待审核，而且无论质量和数量，都在逐步提高，真是一片繁荣景象。当然，这种自下而上的改进行为更加需要引导和规范，目前的高效率与低成本在组织的管理要求和财务核算更加严格后，也会逐渐丧失其优越性，但是至少目前还是可行的，因为需要鼓励更多的研发人员参与到过程改进中来。

    如果组织的过程成熟度在CMMI的4级或者5级，这个矛盾就不存在了，因为4级的OPP本身就是对过程性能的量化，而5级的OID是基于OPP，在量化管理组织过程的基础上，进行过程的革新策划的。

    在具体的改进活动的执行中，6sigma与CMMI的最大相似点就是：采用项目管理的方式运作。6sigma采用项目方式运作不稀奇，而CMMI的过程改进也采用这种方式，则是近来的事情。原因有两个：一是EPG承受了很多项目组的抱怨，认为制定的规程和流程繁复，缺乏可操作性，脱离了项目的实际；二是EPG的改进活动，在审核中暴露出与项目运作一样的弊病：进度严重延误，人员职责不清，任务目标不明确，需求变化不可控等等。这些促使EPG改进了工作方式：整个EPG按照一个项目运作，每个过程域的工作小组，类似于项目的开发组。于是在这个与项目一样的两层结构中，同样设定了满足SMART要求的项目目标，按照CMMI的要求进行计划、跟踪、审核等等活动。即使是组织内部对于过程改进的需求变更请求，和审核不合格项，也与项目一样走变更流程，由EPG的CCB来定期处理。由于EPG的成员对于自己制定的规程很熟悉，对于推荐的各种工具、方法也很熟悉，这种工作方式的转变进行得很快，改善效果也非常明显，一切看起来都在有条不紊地进行。这算不算是神奇呢？这就是CMMI的价值体现，它毕竟是软件行业多年来经验与智慧的结晶，而且现在的应用已经突破了软件行业的限制。

    我自信对于6sigma已经理解比较深入；然而当我越深入理解CMMI，就越相信它在研发领域是很好的方法。然而为什么我们在研发过程改进中还是进展缓慢呢？我想有两个原因：一是在面对多种都独自有效的工作思路时，既没有能力将之有效结合，使工作高效进展，也不敢决断地舍弃一些，坚持一些。二是，即使在决策之后，组织的执行力跟不上。以我们目前的改进来说，终于明确了在研发过程的改进中以CMMI为主，这是工作思路的明确；在实际执行中，按照CMMI对于项目管理的规范进行，各阶段目标明确，责任清晰，跟踪及时，所以成果凸现。照此下去，我对于达到既定的目标毫不怀疑。

    也许有人马上要问：你不是6sigma的黑带吗？如果这样，还要6sigma在这里做什么？我是黑带，可是我不是在为了做6sigma而存在，我为了完成EPG的岗位要求而做事：研发过程改进。那么无论采用哪种方式，只要能使组织达成目标就好。而且正如上面所述，CMMI能做到的策划和实施，6sigma也能做到，只是异曲同工而已。然而为了组织明确思路，行为一致，某一方有必要退让一些。正是“君子有所为，有所不为”，在领导明确工作思路后，需要6sigma有所不为。除此以外，6sigma仍然能在更加细节的地方，为研发过程改进添加助力。如多种工具以增强思维和决策的逻辑性，尽量采用数据决策也能促进组织对于度量的关注和改进；而CMMI在流程改进的财务收益衡量上的欠缺，也在6sigma的面前暴露无遗，这也能促进组织改进这方面的工作。不仅这些，6sigma对于完美的渴望，客户的关注，团队的沟通，以及传播这些知识和理念的定期培训，都在潜移默化地改变着组织的氛围，提高组织成员的素质。这一切都是在默默地推动着研发过程的改进，而结果也必定是组织在CMMI的成熟度级别评估中，越走越高。