实际上这种测量系统分析的方法并非第一次使用，去年我们研究所的一个绿带项目做法极其类似，其原理如图3所示。
图3 某绿带项目的测量系统分析原理图示
这是一种典型的离散数据MSA的案例，在展示时，不少研发人员很吃惊：“原来MSA是可以这样做的”，或者“原来是可以这样得到量化数据的”。有很多人总是说研发过程中的数据量化不足，所以不适合做6sigma项目。其实不是6sigma不能用于研发领域，而是很多时候是我们没有找到正确的方法而已。所以多思考、多动手，这个从小老师就教我们的话，在工作中一样适用。
三、如何提高执行力?
记得前不久一位领导说：“我们公司从来不缺好的策划，我们缺的是好的执行。”软件中的问题有些就是执行的问题，如规范的执行不严格，流程不合理等等。有人会问：“如果解决方案就是执行的问题，可以依据其影响力选择合理化建议，或者团队项目来解决，并不适合做6sigma项目。”实际上，一来6sigma项目在开始时并不知道关键因子是什么，二来执行也不简单，知道和做到是两码事，正如一个黑带所言：“听到你会忘记，看到你会记住，做到你才会明白。”
言归正传，这个案例是另一个黑带项目《提高功能测试仪的软件研发效率》，研发效率的定义为单位软件的软件开发和维护人力成本。这个项目的特点首先是非常细致，每一个步骤都按照6sigma的思路、方法完整、清晰地描述，可以作为初学者的样板指导。然而对我而言，它更加重要的特点是它强大的执行力。在分析阶段，已经确认了三个关键因子：
1. 模块化程度不高;
2. 接口文档不规范;
3. 系统部、软件部、硬件部沟通机制不健全;
为了解决第一个问题，此项目提出建立10个模块的目标，而目前它只有3个模块;为了解决第二个问题，需要建立接口文档的模板，但是更重要的是得到使用者的认可和操作;而第三个问题更是需要三个部门的最高长官——部长来亲自沟通协调解决。以上这些，这个项目都做到了!怎么做到的?看看他的团队成员，有研究所的所长，一个产品总经理，三个相关部门的部长，还有相关的所有科长、开发经理，以及部分开发人员，这样的团队架构，还担心解决方案得不到执行吗?
案就是这么简单，每个项目负责人都需要慎重选择您的团队成员，力争让每个人各尽所长。团队中需要各种人员：首先是各方客户代表，然后是善于分析者，善于操作者，善于协调者，以及流程主管或组织负责人等等。记得以前有个项目，成员基本上都是项目经理，这样的团队沟通倒是通畅了，可是说到做具体的事情，大家都没有时间做，项目怎么进展呢?最后只有取消。想想有多少项目在到达终点之前倒下去，少有找不到解决办法的，但是做出来的方案无法兜售给使用方，从而不能达到项目目标，这倒是常见。为什么?多数是因为团队中没有使用方的代表，强加的东西谁都不喜欢。
也许有人会讲，其实说到执行，就是要把领导拉进来，搞定了领导，让领导出面推进执行和追踪，就一切OK了。这话不对，因为我们不可能把领导搞定的，只会是领导把我们搞定：选择项目一定要把握领导最关心的问题;即使不是最关心的，也要是在他的问题列表中位于前列的问题。如果你要做的就是领导非常想解决的问题，那么邀请他加入项目团队，请他做一些追踪工作自然顺理成章;然而如果选择的课题，在领导问题列表中远没有排在前列，让他分散精力，同时消耗他的资源来做事，他自然不肯。这就是目前我们强调自上而下产生项目的原因。目前，我们公司在一定程度上还是人治的社会，承认这个现实，并且主动调整我们的做法适应现状，才是做事的明智之举。
以上是我近期收集到比较典型和成功的软件6sigma项目。然而我不得不承认，在公司已经完成的上千个项目中，软件项目仍然是占非常少的比例。如果是因为没有成功的案例，影响到大家的信心，或者不知道怎么入手来做，希望本文能够为大家提供一些参考。CMM/CMMI与6sigma的结合和互相促进，在双方领域内都是新课题，还有很大的拓展空间。目前我们公司也有不少黑带身处EPG，选择的项目正是这个新课题。一年之后，我们再来回顾，希望能有更大的突破，让我们也在6sigma的历史上留下光彩的一笔。
文章来源于领测软件测试网 https://www.ltesting.net/
