项目管理不仅适用于客户的项目,同样也适合于生活中的项目. 有了它生活变得非富多彩,有了它管理客户的项目更加轻松愉快.项目管理没有一成不变的方法, 唯一的办法就是根据项目的实际情况去灵活的处理, 不论你采用敏捷模式(Agile), 还是使用瀑布模式(waterfall) , 最终的结果就是按时,保质保量的完成客户确定的目标. 正如兵书所云,只有天时,地利,人和,才能取得战争的胜利, 项目管理尤是.
一个项目成败,有几个关键的因素影响着,诸如项目范围,时间,费用和质量.实际上在项目管理中,我认为对需求变更的管理以及对质量的控制显得尤为关键.由于工作在外企,所以有机会和国外的客户(项目经理)一起合作项目. 这里举个实际项目的例子,一起分享我是如何管理需求的变化以及控制项目的质量.
简单介绍一下项目的背景,项目的名字(dZine)既是公司名字也是项目名字, 是为国外的一家机场开发的信息实时发布系统, 软件整体的功能由服务端, 中转端, 以及客户端三部分功能组成. 软件是基于客户原有的一套系统上开发的, 需求及业务逻辑都很复杂.项目整体采用敏捷模式.
需求变更的控制
项目启动后, 作为项目经理的我,开始进行项目的监控活动,每周的项目进度周报都及时地发给客户,以便客户了解项目的状况.有一天, 收到客户的一封邮件, 大致意思是,希望增加一个新功能,并且很急.我立即召集项目组骨干成员,对新需求进行了分析,并且考虑了它可能的一些潜在的风险,诸如,它对整体架构的影响, 技术实现的可行性,开发费用以及所需的工时等等. 讨论的结果是,我们项目组可以接受这个变更,在CCB(控制变更委员会)同意之后, 我随即给客户写了反馈邮件, 并且附带了RFC(需求变更单),在变更单中包括一些需要确认的信息:完成新功能所需的人/日,开发费用,完成开发的截止日期等等,同时完成了对Blueprint(需求文档)的更新.结果当天就得到了客户的确认反馈, 他同意这次变更以及由此产生的费用.
以后的事情,变得清晰而明了,我们开发了新功能,并且按计划提交了测试版本.客户看似很满意, 没过多久,客户有了第二次变更, 功能与第一个变更有关,只是业务逻辑更复杂,有了之前的处理办法,变更这件事看似很简单,评估需求的影响,分析潜在风险,费用估算,CCB的审批,最后到客户确认. 一切都还顺利,按时提交了版本后, 我们满心欢喜的等待着客户的反馈.
几天之后,得到了客户的反馈,只不过不是表扬,而是质疑我们为什么不经过他的同意就擅自修改需求,并且给我指出了问题所在,这还不算,这封邮件还抄送给公司的总经理. 我马上意识到问题的严重性,在客户是上帝的今天,我丝毫不敢怠慢,马上召集项目组成员,一起查找以往的变更历史,通过需求跟踪矩阵进行反推,最后终于找到了此次变更, 并且找到了客户的确认邮件,看到这份客户确认的需求变更单,我如获至宝,当我把客户以前的确认邮件转发给他,并且抄送了总经理后,此时的心理充满了胜利的喜悦.果然第二天收到了客户的道歉邮件, 承认是自己的问题,并且又增加了新的需求,当然在邮件中也没有忘记表扬我一下.客户的反馈对我们这些项目经理至关重要.半小时后,又收到了总经理的回复邮件,仅仅两个单词, Well done!足矣,这两个字既包含对我工作的认可,又包含了对我的信任. 这一案例,后来被总经理多次提及,并且被收集到公司的资产库中,作为其他项目的参考案例.以至于在后来的项目总结会上, 我无不感慨地说,项目成也需求变更,败也需求变更.如果处理不好,的确对项目造成很大的影响.
质量保证管理
在国外开始推广Q