问题,这样处理是否合适?
项目进度推迟、项目预算超出计划,公司领导把项目经理叫去,严厉的批评了一顿,而没有责备过任何其他项目成员。
软件发布出去后,发现严重的缺陷,公司领导把测试人员叫去严厉批评,也没有责备过任何其他项目成员。
你们的团队中,有没有这样的情况:
只有项目经理为项目的进度、预算劳心劳累,其他人都在“安分”地完成“本职”工作,不会主动过问其他情况。
出现问题时,谁是问题责任人的皮球会被踢来踢去,没有人愿意承担责任。
为什么有这样的问题呢?应该如何处理呢?是责任定得不够清晰吗?
团队的每一位成员,肩负起自己所在领域的责任,团队的每一位成员共同对最终解决方案负责,同时鼓励小组成员对非他们直接负责的领域作出评论和贡献。
软件开发团队中,有项目管理、需求分析、设计、编码、测试等各个领域的人才,每领域的负责人对自己的工作负责。
另外一个方面,软件是团队共同劳动成果,所有人对最终的解决方案负责,最终解决方案只要有问题,就是整个团队的责任,最终解决方案取得优异成绩,就是整个团队的功劳。软件开发团队,是一个“一荣俱荣、一损俱损”的团队,只有这样才能把全部人的利益扭在一起。
了解了微软的这个原理后,大家对前面提到的问题是否有了答案?
关注交付的业务价值
客户需要的是一把梯子,系统分析员了解到的是一张凳子,开发人员做出来的是一张桌子,测试人员以为是一张椅子。看上去可笑,但这样的情况却经常发生在我们的身边。关注交付的业务价值,意思就我们工作中的每一份工作产品,都应该是需求驱动做出来的,这样才能保证我们最终做出的软件就是客户所需要的东西。这个原理有以下几层意思:
小组成员要对客户的需求有一致的充分的理解;
要让客户积极参与到项目过程中去,随时了解小组的理解和客户的需要是否一致;
需求驱动地完成所有工作,保证最后的软件产品符合客户的需要。
保持灵巧,预测变化
软件是智力型创造性活动,保持灵活、适应变化是软件开发的最高境界了,笔者认为这条原理是最难把握的一条了。
这个原理主要体现在以下方面:
软件开发过程
微软采用的不是RUP,也不是XP,而是类似于螺旋形的阶段式分版本发布。微软会把软件分成若干的版本发布,除了平时我们见到的Beta版、Release版,其实在Beta版之前还会有若干的内部版本。
每个版本都包含相对完整的功能,都能实现部分业务价值。每一个版本就是一个开发周期,每个周期包含远景、计划、开发、稳定、部署五个阶段。这样的一种开发模型,能很好地适应需求变化,发现设计、编码缺陷,优化设计,更容易控制软件质量,便于随时做出商业决策。
设计方案
执着于优雅设计的人士,可能很喜欢做出完美无缺的设计,关注于业务的人士,可能更关注于尽快要拿出软件。我们追求的是适度设计,而不是过度设计,如何做出一个简单的而又适应变化的设计,是对软件设计高手们的一大考验。
质量投资
“质量第一”是很多软件公司的口号,而且仅仅是口号而已,你们的项目有这样的一些问题吗?
代码没有经过简单的冒烟测试,甚至不进行是否通过编译的测试,就直接提交。
为了赶时间不写设计或者写了不能指导编码的设计文档。
开发进度推迟,测试时间被压缩,为了保证软件发布的时间,在不充分测试情况下交付软件,更甚者不测试软件,直接让客户测试。
开发过程中发现的问题,只要能不解决的就不解决,进度优先!
测试中发现的易用性方面的缺陷,因不会严重影响使用,一律不解决!
质量投资要求我们有零缺陷的意识,零缺陷意识要贯穿在全部的工作中,包括:
零缺陷文档
计划、需求、设计等开发过程中产生的文档,要用一次写好的决心来编写,所有文档都应该
项目经理胜任力免费测评PMQ上线啦!快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html