后期维护的一点心得

近半年的主要工作还是对项目的后期维护,现在经手的项目从建立到如今也有将近一年半多的时间了,感触颇多。

当时记得项目经理语重心长跟我说,跟客户交流,沟通,直接到现场了解客户需求,是程序员技术提高的一个快速成长阶段。说真的,那时还真的有点不以为然,不就是改改细节嘛,会有什么难度呢

可随着与不同客户的交流的深入,才发现自己想法的幼稚。

单就项目而言,因为参与了项目的整个过程,包括需求分析,框架搭建,项目的核心编程,后期的维护测试整个阶段,就好比自己养着的小宠物,看着它长大,为它的健壮成长而欣慰,为它的生病而着急。

在与客户的沟通过程中,发现很多想法都太想当然了,说是说站在客户角度,可因为角色的错位和对项目的熟悉,很多时候还是以开发人员的思维去模拟客户的思想。而最大的区别莫过于界面的美观性和便捷性。

回想项目开发过程,在开始时,主要还是考虑程序的正确性,很少考虑到用户的心理,或者说以用户的思维去测试项目的正确性。比如以用户对项目的不熟悉程度,很可能在做一个操作后又进行了后退操作,特别保存的时候,就要防止程序的重复提交,删除也同理。有时候测试的结果很蹊跷,让人找不到头绪,很可能第一次进行某个操作是正确的,第二次就会报错,而第三次又是正确的,又或者报错的概率是随机出现的,这时候就需要静下心来耐心的测试。现在想想自己急躁的性格也在项目开发过程中磨合了好多,这也是一个收获吧

还有,在测试的时候,如果进行某个操作自己都觉得很不方便,特别是批量操作的时候,就要考虑优化程序了。同样,如果类似的代码在好多模块重复出现,就要学着去重构,或者将代码的抽象部分提取出来做成接口封装。

上半年学的模式其实很多都是平时项目中接触过的,而模式的学习只是系统的将平时的感想梳理了一遍,有了一个更加清晰的概念。

还有对客户的要求,刚开始是有求必应,客户说改什么就改什么,可能同一个问题会重复改来该去好几次,后来觉得这样效率太低了。在客户提出修改时,有必要要求一个正式的书面文档,一般是邮件,同时深入了解客户的需求。很多时候客户的要求其实很简单的,换个方式当前的功能就能够实现,这时就要看你的沟通能力了,如何在让客户对你提出的建议采纳的同时,还不能产生任何的不满。

同时,充分利用客户的沟通过程也是一个关键点。不少时候需要到客户现场进行改动,在跟客户交谈过程中,提出平时开发项目过程中的疑虑,一般客户是很开心你向他们请教问题的。在项目应用的逻辑上,比如档案系统,档案管理员对档案的了解就远胜于一般的非档案专业的人了。

 

这些只是在后期维护中跟客户交流的一些心得,可能很多人都已经亲身经历过了

还好,写的不是很罗嗦,呵呵

阅读更多
个人分类: 技术
上一篇如何阅读英文书呢
下一篇好久没登陆CSDN了,我又回来了
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭