项目管理经验谈-2.docxVIP

??

?

??

项目管理经验谈

?

??

?

?

?

?

?

?

?

???

?

?

?

?

?

?

?

项目管理不仅适用于客户的项目,同样也适合于生活中的项目.有了它生活变得非富多彩,有了它管理客户的项目更加轻松愉快.项目管理没有一成不变的方法,唯一的办法就是根据项目的实际情况去灵活的处理,不论你采用敏捷模式(Agile),还是使用瀑布模式(waterfall),最终的结果就是按时,保质保量的完成客户确定的目标.正如兵书所云,只有天时,地利,人和,才能取得战争的胜利,项目管理尤是.

一个项目成败,有几个关键的因素影响着,诸如项目范围,时间,费用和质量.实际上在项目管理中,我认为对需求变更的管理以及对质量的控制显得尤为关键.由于工作在外企,所以有机会和国外的客户(项目经理)一起合作项目.这里举个实际项目的例子,一起分享我是如何管理需求的变化以及控制项目的质量.

简单介绍一下项目的背景,项目的名字(dZine)既是公司名字也是项目名字,是为国外的一家机场开发的信息实时发布系统,软件整体的功能由服务端,中转端,以及客户端三部分功能组成.软件是基于客户原有的一套系统上开发的,需求及业务逻辑都很复杂.项目整体采用敏捷模式.

需求变更的控制

项目启动后,作为项目经理的我,开始进行项目的监控活动,每周的项目进度周报都及时地发给客户,以便客户了解项目的状况.有一天,收到客户的一封邮件,大致意思是,希望增加一个新功能,并且很急.我立即召集项目组骨干成员,对新需求进行了分析,并且考虑了它可能的一些潜在的风险,诸如,它对整体架构的影响,技术实现的可行性,开发费用以及所需的工时等等.讨论的结果是,我们项目组可以接受这个变更,在CCB(控制变更委员会)同意之后,我随即给客户写了反馈邮件,并且附带了RFC(需求变更单),在变更单中包括一些需要确认的信息:完成新功能所需的人/日,开发费用,完成开发的截止日期等等,同时完成了对Blueprint(需求文档)的更新.结果当天就得到了客户的确认反馈,他同意这次变更以及由此产生的费用.

以后的事情,变得清晰而明了,我们开发了新功能,并且按计划提交了测试版本.客户看似很满意,没过多久,客户有了第二次变更,功能与第一个变更有关,只是业务逻辑更复杂,有了之前的处理办法,变更这件事看似很简单,评估需求的影响,分析潜在风险,费用估算,CCB的审批,最后到客户确认.一切都还顺利,按时提交了版本后,我们满心欢喜的等待着客户的反馈.

几天之后,得到了客户的反馈,只不过不是表扬,而是质疑我们为什么不经过他的同意就擅自修改需求,并且给我指出了问题所在,这还不算,这封邮件还抄送给公司的总经理.我马上意识到问题的严重性,在客户是上帝的今天,我丝毫不敢怠慢,马上召集项目组成员,一起查找以往的变更历史,通过需求跟踪矩阵进行反推,最后终于找到了此次变更,并且找到了客户的确认邮件,看到这份客户确认的需求变更单,我如获至宝,当我把客户以前的确认邮件转发给他,并且抄送了总经理后,此时的心理充满了胜利的喜悦.果然第二天收到了客户的道歉邮件,承认是自己的问题,并且又增加了新的需求,当然在邮件中也没有忘记表扬我一下.客户的反馈对我们这些项目经理至关重要.半小时后,又收到了总经理的回复邮件,仅仅两个单词,Welldone!足矣,这两个字既包含对我工作的认可,又包含了对我的信任.这一案例,后来被总经理多次提及,并且被收集到公司的资产库中,作为其他项目的参考案例.以至于在后来的项目总结会上,我无不感慨地说,项目成也需求变更,败也需求变更.如果处理不好,的确对项目造成很大的影响.

质量保证管理

在国外开始推广QA(质量保证)之后,我们公司也开始引入这一重要的环节,来提高产品的质量,尽管很多人都认可QA,但是一旦执行起来,并不是每个人都愿意接受它.

一个优秀的测试人员不但具有发现问题,记录问题和跟踪问题的能力,同时还应具有帮助项目经理分析问题的能力,这些都可以通过测试报告来体现.一个测试报告的价值要体现在它如何展现有用的数据,如何分析数据,而不是表现在数据的简单罗列以及文档的页数上.

下面的图一,是我们项目组给客户作的测试报告.之前提到过,这个项目是和国外的团队一起合作开发的,所以在每个Sprint结束之后,我们都要制作测试报告,给国外的开发团队及客户一个反馈.在这个截图中,我们根据发现的这些缺陷(Bugs),分析了可能造成这些缺陷的原因,并且对这些缺陷进行了归类.以图表的形式展现给客户.这样的报告,对客户来说,是清晰的,明了的.让客户感觉到我们在用心做事.

图一

项目在每次测试之后,会给出一个测试结论,见图二.这里面还包含一个