项目管理资源网

您的位置:项目管理资源网 >> 研发制造项目管理

软件研发项目管理案例分享

2015/9/25 10:45:41 |  3467次阅读 |  来源:网友转载   【已有0条评论】发表评论

发人员对于故障理解不同。

   (2)参加故障分类的研发人员没有能力按分类标准对故障进行分类。解决的办法是在故障分类前进行测量系统分析,确认故障分类标准是否已经明确,参加分类故障的研发人员是否具备了故障分类能力。

  对于故障分类进行的测量系统分析可采用离散测量系统分析。进行离散测量系统分析的基本步骤为:

1、 在需要分析的故障中随机抽取30个故障。

2、 多个开发经理按故障分类标准共同确定每个故障的分类结果。(作为“真值”——本文作者)

3、 让参加故障分类的研发人员按故障分类标准进行分类。(作为“测量值”——本文作者)

4、 一周后,让参加故障分类的研发人员重新按故障分类。

5、 进行离散测量系统分析,确定故障分类的准确性、重复性和再现性。

   如果通过测量系统分析,发现故障分类的重复性有问题,同一个研发人员对于同一个故障的判定结果不相同,则一般是研发人员自身素质的问题,采取的措施是需要加强对分类标准的学习。如果不同研发人员之间的再现性有问题,则一般是由于分类标准不明确造成,需要进一步明确分类标准。若重复性、再现性都符合要求通过,基本可以保证故障分类的标准定义是明确的,参加故障分类的研发人员的技能已经符合要求。

  实际上这种测量系统分析的方法并非第一次使用,去年我们研究所的一个绿带项目做法极其类似,其原理。

  这是一种典型的离散数据MSA的案例,在展示时,不少研发人员很吃惊:“原来MSA是可以这样做的”,或者“原来是可以这样得到量化数据的”。有很多人总是说研发过程中的数据量化不足,所以不适合做6sigma项目。其实不是6sigma不能用于研发领域,而是很多时候是我们没有找到正确的方法而已。所以多思考、多动手,这个从小老师就教我们的话,在工作中一样适用。

三、如何提高执行力?

   记得前不久一位领导说:“我们公司从来不缺好的策划,我们缺的是好的执行。”软件中的问题有些就是执行的问题,如规范的执行不严格,流程不合理等等。有人会问:“如果解决方案就是执行的问题,可以依据其影响力选择合理化建议,或者团队项目来解决,并不适合做6sigma项目。”实际上,一来6sigma项目在开始时并不知道关键因子是什么,二来执行也不简单,知道和做到是两码事,正如一个黑带所言:“听到你会忘记,看到你会记住,做到你才会明白。”

   言归正传,这个案例是另一个黑带项目《提高功能测试仪的软件研发效率》,研发效率的定义为单位软件的软件开发和维护人力成本。这个项目的特点首先是非常细致,每一个步骤都按照6sigma的思路、方法完整、清晰地描述,可以作为初学者的样板指导。然而对我而言,它更加重要的特点是它强大的执行力。在分析阶段,已经确认了三个关键因子:

1. 模块化程度不高;

2. 接口文档不规范;

3. 系统部、软件部、硬件部沟通机制不健全;

    为了解决第一个问题,此项目提出建立10个模块的目标,而目前它只有3个模块;为了解决第二个问题,需要建立接口文档的模板,但是更重要的是得到使用者的认可和操作;而第三个问题更是需要三个部门的最高长官——部长来亲自沟通协调解决。以上这些,这个项目都做到了!怎么做到的?看看他的团队成员,有研究所的所长,一个产品总经理,三个相关部门的部长,还有相关的所有科长、开发经理,以及部分开发人员,这样的团队架构,还担心解决方案得不到执行吗?

   就是这么简单,每个项目负责人都需要慎重选择您的团队成员,力争让每个人各尽所长。团队中需要各种人员:首先是各方客户代表,然后是善于分析者,善于操作者,

    项目经理胜任力免费测评PMQ上线啦!快来测测你排多少名吧~

    http://www.leadge.com/pmqhd/index.html

“项目管理生根计划”
企业项目经理能力培养和落地发展方案下载>>

分享道


网站文章版权归原作者所有,如有认为侵权请联系我们,将于1个工作日内作出处理!
网友评论【 发表评论 0条 】
网友评论(共0 条评论)..
验证码: 点击刷新

请您注意护互联网安全的决定》及中华人民共和国其他各项有关法律法规或间接导致的民事或刑事法律责任
·您在项目管理资源网新闻评论发表的作品,项目管理资源网有权在网站内保留、转载、引用或者删除
·参与本评论即表明您已经阅读并接受上述条款