测试积点老人 发表于 2018-12-7 16:17:55

项目质量管理之持续改进

持续改进(Continual improvement),也叫持续改善(Kaizen),最初是一个日本管理概念,指逐渐、连续地增加改善,是日本持续改进之父今井正明在《改善-日本企业成功的关键》一书中提出的。Kaizen意味着改进,涉及每一个人、每一环节的连续不断的改进,从高层管理人员、中层管理人员到工人。

持续改进的关键因素是:质量、所有雇员的努力、介入,自愿改变和沟通。提出持续改进的原因是在做项目的过程中,如果发现一个问题,要在吸取经验教训之后进行改正,主要用于推动事情发展的。项目不能反复地踩同一个坑,大家如果遇到了一次问题,下次再遇到这样的问题你就不会再犯错误,这时候就已经叫做改进了。从这个角度来说,持续改进是质量管理重点关注的内容。

项目管理有一个很重要的原则叫做吸取经验教训,吸取经验教训的背后其实就是要持续改进。每次我们吸取了经验教训下次不犯了,这个就叫持续改进。

本文基于软件项目,探讨如何持续改进软件质量。

一、遇到的问题

在做项目过程中,经常出现“反复踩同一个坑”的情况。一个团队里小李犯了一个错误导致生产事故,没多久后,小王又因同样的错误导致生产事故,又没多久,小张因类似错误导致生产事故………

作为项目管理人员,碰到团队成员一而再、再而三的出现这个问题,绝对恼火。组织开会讨论,强调安全生产、生产无小事等等,让团队成员紧绷一根弦。

短时间可能有效,但我们发现,没过多久,还是会出现类似的错误。

二、持续改进办法

1、测试改进

从测试阶段来说,通常包括单元测试、系统测试(SIT)和验收测试(UAT),每个测试阶段的关注点不同,但相同的目标都是检查产品质量、找出产品存在的缺陷。所以,我们欢迎测试人员在项目的各个阶段发现缺陷、提出问题,但我们更欢迎在早期发现问题。发现越早,改造成本越小。

从测试手段来说,包括手工测试和自动化测试。手工测试由测试人员依据需求、设计编写案例,采用脚本或客户端操作的方式进行验证。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果后,与预期结果进行比较。

手工测试更多的依赖测试人员的经验和责任心,而自动化测试可以集大众经验,且节省人力、时间和硬件资源,提高了测试效率,目前比较受推崇。

遇到问题后,我们需要做测试改进,更新测试案例或测试手段,比如,增加死循环检查的案例、超时的案例、边界值的案例等等。在这个问题上,自动化测试更占优势。

2、直面问题,不避讳、不隐瞒。

创造一种直面问题、不避讳、不隐瞒的工作氛围。

这个事情说起来容易,做起来难。通常出问题后,我们总是希望知道的人越少越好,以免给部门带来不好的影响。通常来说,隐瞒是为了考核、是为了绩效。大部分公司都有健全的绩效考核制度,出现生产问题时,会扣责任人的考评分数或工资。倒不是说应该取消这项制度,但HR部门最好能将两个事情结合起来考虑,建立一种怎样的考评机制,能让大家敢于直面问题。

让应该知道的人知道。哪些人是应该知道的人呢?项目团队,跟你从事同一个岗位、负责同一个系统的小伙伴们。有了问题、出了事情,怎么解决的,原因是什么等等,一定要让这些小伙伴们了解清楚。

3、建立问题比对机制(逐项比对,逐项打勾)

从某个角度讲,犯过的错误也是一种资产、一种财富,当然要建立在对这些错误充分分析、提出改进措施的前提下。我们将团队成员犯过的错误登记下来,团队范围内共享,并且,投产评审时,要将这些问题比对一遍,确保历史问题没有出现。

在有的公司里,将历史问题登记在《代码走查单》中,做代码评审时,逐项勾对。刚开始的时候还好,后期可能就变成一种形式,起不到预想的作用。

4、搭建问题墙。

我们已经相当习惯搭建荣誉墙,这样看着舒服,团队成员面子上也有光,但成绩都是历史,这些还是放在晋升报告里写吧。在这里,我们要搭建问题墙。将团队成员犯过的错误张贴在墙上,当然,这个匿名比较好,只谈问题、谈原因、谈解决办法,也就是对事不对人。问题上墙的前提还是第一条,团队要有直面问题、不避讳、不隐瞒的工作氛围,这个时候团队经理要起表率作用,可以将自己以前犯过的错、踩过的坑都贴出来,让大家效仿;鼓励团队成员贡献自己的“历史问题”。

有新问题产生时,团队经理带领大家分析、解决问题后,将问题贴上墙,一来让大家学习,二来起到警钟作用。

以上,是本人在项目管理中用到、想到的方法,应用这些方法后,的确提升了软件质量。然而,提升软件质量无止境,方法也必然很多,需要项目经理们不断总结经验教训,不断提升!

页: [1]
查看完整版本: 项目质量管理之持续改进