|
多年的管理经验告诉我，CMM/CMMI与6sigma能够结合，互相促进。在项目管理培训中，你可能会听到：“CMM2级企业不适合实施6sigma，应该等到CMM4级之后，度量体系比较完善时再进行。”现提供几个典型案例，它们各具特色，在此一一分享。转自项目管理者联盟
一、6sigma能帮助解决软件技术问题吗?项目经理圈子
第一个项目项目名称是《XX网管系统提高告警吞吐率》，问题是在大量告警上报时，UNIX服务器的告警处理吞吐率仅为8条/秒，同时占用CPU达90%，导致其它模块的操作基本上不能进行。用户对此非常不满，要求我公司尽快解决此问题，提高吞吐率到至少48条/秒，而系统成本不能有较大幅度增加。如何解决这个问题?一个解决方案是提高硬件的配置，从而提高处理性能，但是这样做会大大增加采购成本，而性能并不会有极大的提升，实际上降低了产品的可销性，这样的投入收益比极不合算，此方案被拒绝。项目组在花了大量时间和精力，仍然寻找不到合适的解决办法之后，想到了6sigma。大家知道，6sigma项目的选择就是那些“难度大、影响力大”的问题，于是这个项目组的成员将此问题立项，期待6sigma能在黑暗中带来曙光。项目管理者联盟
除去定义与测量阶段，此项目的分析思路是这样的：首先是头脑风暴鱼骨图，罗列所有大家能想到的可能原因;然后将这些原因按照告警的逻辑处理流程组织成FMEA，进行RPN分析，筛选出RPN值大于100的少数因素，作为潜在的关键因子;之后对这些潜在因子逐一试验，进行确认。整个项目的突破就出现在第一个因子的试验中，流量增加时，服务器的处理延时反而有较大的降低。这个现象如果没有针对此原因的试验，没有这些数据是无法看到的。PgMp.mypm.net
分析这个现象的原因，难不到我们的软件工程师，很快就得出了结论：TCP协议参数设置不当。修改此参数后，重新做同样的试验，其告警吞吐率基本上与输入流量呈线性关系增长，瓶颈已经消除。这不仅仅是确认了此因子是关键因子，同时也验证了改进措施的有效性。另外几个因子也是类似的，通过针对每一种可疑因子的试验，或确认此因子为关键因子，或筛选影响不大的因子;然后针对每个关键因子寻找技术上的解决办法，就更不在话下了。此项目的成功为公司创造了每年166万的收益。项目经理圈子
回顾这个项目，又应验了一句老话：“解决难题经常是99%的努力在于寻找关键原因所在，而修改只需要1%的努力。”6sigma本身并不提供技术解决方案，但是它的思路引导我们向着正确的方向迈进，而数据是保障我们方向正确的重要依据。此项目虽然是软件项目，但是问题本身Y是可以清晰度量的，这也是它能够适应6sigma特色，得以成功的一个原因。
二、主观判断的结果有说服力吗?转自项目管理者联盟
这个案例是黑带项目《降低异常代码故障率》，它从CQ分析的主要故障类型之一：异常代码故障率居高不下而来，这体现出负责人主动从失误中学习和进步的精神，也给很多仍然为找不到合适项目的同事一个启示：CQ库是一个很方便的项目宝库。项目管理者联盟
此项目对于故障分类的测量系统分析，是离散数据做测量系统分析的典型。在研发过程中，我们经常遇到“只可意会不可言传”的情形，大家都是主观判断“拍脑袋”，这样的分析如何具有说服力?主观判断不等于拍脑袋，这个项目可以作为参考，感觉上的东西通过制定一定的准则，能够将大家的主观判断达到基本一致和准确的标准。以下摘自此项目负责人的总结文章：bbs.mypm.net
在确定了故障的分类规则后，对于故障进行分类，对于同一个故障不同的研发人员分类可能出现不同的结果。出现这种问题可能是有两个原因：bbs.mypm.net
(1)故障分类的标准还不够明确，参加故障分类的研发人员对于故障理解不同。项目管理者联盟
(2)参加故障分类的研发人员没有能力按分类标准对故障进行分类。解决的办法是在故障分类前进行测量系统分析，确认故障分类标准是否已经明确，参加分类故障的研发人员是否具备了故障分类能力。项目管理者联盟
对于故障分类进行的测量系统分析可采用离散测量系统分析。进行离散测量系统分析的基本步骤为：项目管理论坛
1、 在需要分析的故障中随机抽取30个故障。项目管理者联盟
2、 多个开发经理按故障分类标准共同确定每个故障的分类结果。(作为“真值”——本文作者)项目管理者联盟
3、 让参加故障分类的研发人员按故障分类标准进行分类。(作为“测量值”——本文作者)blog.mypm.net
4、 一周后，让参加故障分类的研发人员重新按故障分类。项目管理者联盟
5、 进行离散测量系统分析，确定故障分类的准确性、重复性和再现性。项目经理博客
如果通过测量系统分析，发现故障分类的重复性有问题，同一个研发人员对于同一个故障的判定结果不相同，则一般是研发人员自身素质的问题，采取的措施是需要加强对分类标准的学习。如果不同研发人员之间的再现性有问题，则一般是由于分类标准不明确造成，需要进一步明确分类标准。若重复性、再现性都符合要求通过，基本可以保证故障分类的标准定义是明确的，参加故障分类的研发人员的技能已经符合要求。项目管理者联盟
实际上这种测量系统分析的方法并非第一次使用，去年我们研究所的一个绿带项目做法极其类似，其原理。项目管理者联盟
这是一种典型的离散数据MSA的案例，在展示时，不少研发人员很吃惊：“原来MSA是可以这样做的”，或者“原来是可以这样得到量化数据的”。有很多人总是说研发过程中的数据量化不足，所以不适合做6sigma项目。其实不是6sigma不能用于研发领域，而是很多时候是我们没有找到正确的方法而已。所以多思考、多动手，这个从小老师就教我们的话，在工作中一样适用。项目管理者联盟
三、如何提高执行力?项目管理论坛
记得前不久一位领导说：“我们公司从来不缺好的策划，我们缺的是好的执行。”软件中的问题有些就是执行的问题，如规范的执行不严格，流程不合理等等。有人会问：“如果解决方案就是执行的问题，可以依据其影响力选择合理化建议，或者团队项目来解决，并不适合做6sigma项目。”实际上，一来6sigma项目在开始时并不知道关键因子是什么，二来执行也不简单，知道和做到是两码事，正如一个黑带所言：“听到你会忘记，看到你会记住，做到你才会明白。”blog.mypm.net
言归正传，这个案例是另一个黑带项目《提高功能测试仪的软件研发效率》，研发效率的定义为单位软件的软件开发和维护人力成本。这个项目的特点首先是非常细致，每一个步骤都按照6sigma的思路、方法完整、清晰地描述，可以作为初学者的样板指导。然而对我而言，它更加重要的特点是它强大的执行力。在分析阶段，已经确认了三个关键因子：
1. 模块化程度不高;pmp.mypm.net
|
