【摘要】
本文以我参与过的资源管理系统为实例,探讨了在项目管理过程中,在范围管理方面遇到的实际问题及相应的解决办法,认为在项目管理过程中,如果范围管理做到位,将有利于项目下一步工作的有序展开,最终促使项目走向成功,并满足各利益相关者的需求和预期期望。在此项目中,我担任了系统开发方的子系统开发经理,参与了整个系统的建设任务,项目从启动至验收历时15个月,系统至今运行稳定,获得了客户的一致好评,很大程度上得益于范围管理方面的工作做得扎实到位。
【正文】
一、本项目简介
某通信运营商为解决各专业网络的资源管理问题,分别开发建设了数据、交换、传输、
无线等四大专业网络资源管理系统,这四大专业系统在一定程度上,缓解了该企业在网络资源管理方面所面临的压力。但是,由于这四大专业资源管理系统是分散建设的,水平也参差不齐,在一定程度上制约了这四大专业网络资源信息的共享和应用。因此,该通信运营商向集团公司申请进行四大专业网络资源管理系统的整合工作,开发综合网络资源管理系统,此系统在某年某月得到集团公司的正式批复,随后开始启动综合网络资源管理系统的全面建设。我负责资源展示子系统和报表子系统的需求调研和系统开发工作。
系统于2009年8月起上线运行,系统上线以来,运行稳定,并在各地市推广应用。其中,无线专业在济源进行了实施;话务、数据等专业也在相关专业科室投入了使用。系统投入使用后,在资源利用率、网络运维能力、业务支撑能力的提升等方面发挥了重要作用。
二、我在本项目中的工作内容
第一步:需求调研
按照我们制定好的综合资管项目调研计划,我与网管中心的A主任取得联系,通过我和A主任的沟通对话,让A主任非常清楚我此次去用户现场调研的业务目标,以便A主任根据我此次调研的目标,及时安排相关业务的科室负责人配合我调研需求,到了用户现场之后,我们会和用户现场业务骨干人员针对现场具体业务进行深入具体的沟通交流。
第二步:原型制作
我对网管中心的业务调研告一段落之后,我即开始根据调研到的需求,制作静态的原型页面,也就是系统演示Demo,此Demo操作起来,感觉和真实系统相似,只是没有编写后台代码实现功能。
第三步:客户确认
原型制作好了之后,我再次主动和网管中心的A主任取得联系,预约时间,以便向网管中心主要人员演示综合资管系统Demo。此次演示的目的,主要是为了让用户和我们一同,以Demo这种所见即所得的直观方式,来确认我们开发方对需求的理解是否正确无误,如果用户看过Demo之后,指出了我们需求调研之后,理解不正确的地方,我们会及时的修改Demo,一直循环下去,知道Demo正确为止。
第四步:设计架构和编写代码
三、我遇到的范围管理问题
场景缺失:我在进行资源展示子系统的需求调研阶段,在和客户沟通交流需求的时候,经常会找不到某一个需求的应用场景,比如对于绘制大量的拓扑图模板,从而构成拓扑图模板库,进而由模板库和数据库数据,实时的生成拓扑图实例这一需求,对于这一需求,用户一度提出,这么大量的拓扑图模板有谁来绘制?是由用户还是开发方的实施人员?绘制模板的依据来自于哪里?
还有很多这样的类似需求,急需找到相应的应用场景,得到用户的认可,只有得到了用户的认可,我们的项目才会累积一个有一个的增值点,增值点的多少和我们项目的价值是成正比例的。应用场景找不到,意味着这个需求将要被废掉。
四、本项目从以下几方面入手来解决遇到的范围管理问题
首先,现场走访用户业务骨干人员,进一步深入学习研究业务。通过走访,获得了使用软件的一线用户的意见,他们指出,由于许多业务的拓扑图结构有相似之处,如果一个一个绘制,工作量巨大,并且拓扑图中的数据不能实时更新,拓扑图的价值大打折扣,因此实际工作中确实存在自己绘制拓扑图模板的需求,只要建模工具用起来顺手,好用,比如说想visio那样易于操作,他们也愿意使用建模工具,自己动手绘制拓扑图模板,由于一线骨干人员对业务较为熟悉,并且他们手头有平时工作过程中积累的业务资料,因此绘制拓扑图模板是有依据的。其次,通过查询运营商集团下达的业务规范,我们也查找到运营商集团下达的统一建模工具的要求,为此需求提供了相应的支撑。最后,参考其他省份的类似需求,也找到比较成熟的建模工具应用场景。
五、项目总结和展望
项目最终成功上线,并运行良好,成功的经验固然是宝贵的,不足之处同样值得重视:
不足之处:
在需求调研阶段,我们部分同事在和客户沟通的过程中,言行不得当,在和客户说了一些让用户感觉不好的话语,比如对于某些用户感觉很重视的功能,我们的同事,未加深思,当场予以回绝,说这个功能程序实现不了。对用户认为某些需要深耕细作的需求,草率的答应,致使用户对我们产生了怀疑。
在实际开发的过程中,开发组长有的时后没有按照调研的需求,严格用程序实现,而是想当然的认为,这样或那样做会更好一些,导致程序开发告一段落后,才发现与客户的需求不一致,偏离了需求,导致开发脱离了需求。
如何改进:
在去客户现场调研之前,应当对去做需求调研的调研开发人员,进行有效的系统培训。
包括沟通技巧,业务知识预热,不应当让自己对业务都不太懂的人员去现场做需求调研,导致用户对我们的业务能力产生了怀疑。
同时应当加强业务培训,加强开发组长对需求的理解程度,让开发组长,真正的理解需求,为什么要这样做。