文档介绍:项目经理工作小结
对于这种需求天天变的客户,你就一定要事先做好规矩:
一、统一联系人,客户指定一个人和项目组进行沟通,不能张领导、王领导都来说几句,如果他们意见不一致,那你只有得罪领导的选择了,所以,项目的最初就要定好规矩,我项目组只认一个的意见,有什么要求你们内部先统一再和我谈,我不想卷入你们内部业务部门之间的矛盾之中;
二、所有需求变更全部要有书面文字,这点切记!这样做好处多多:
*有书面证据,以后他还想改,你有了他以前要求的证据,告诉他:你以前可是这么说的;
*便于需求变更管理,需求如何慢慢演变的历史可以看清楚,从而更深切地体会客户的目的;
*对于客户来说,嘴巴一动最方便,反正是你们做,不花他的资源,所以要求是否合理,是否和项目的目的一致,他是不负责任的。但是如果要他写书面要求,还要签字盖章,他就要谨慎多了,而且一写东西,思想就会更加深入,很多无理要求也就这样胎死腹中了;
系统开发告一段落后,就进入客户培训、系统验收阶段,这个阶段,我一般会注意以下几个问题:
给客户做培训前,多注意一些表面功夫。很多程序员认为,既然很多系统采用原型法,有一个由粗到精的过程,那么系统的逻辑核心是否正确才是关键,至于界面如何,界面上的用词是否准确,那是无关紧要的问题;而且培训的时候也是空手上台、信手拈来,想到哪里说到哪里,下面听讲的人不知所云,云山雾罩,培训效果自然可以想象。我的体会是,给客户做培训的版本,如果你在做多次测试以后仍然不能确定逻辑是否合乎要求,那么,你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等,总之不要让客户看到一些他不该看到的东西,否则,仅仅因为一些无关紧要的报错就让客户第一印象觉得系统不稳定,那你就真的比窦娥还冤了。如果工作再做得详细一点,可以做一些类似flash的东西,把一些你要强调的重点用通俗易懂、轻松愉快的方式表达出来。文档方面,准备至少两个文档:用户手册和培训手册。这两个文档的内容很多都是一致的,但是角度完全不同。用户手册往往是站在系统设计者的角度,按照自己的思路,分模块讲解系统的操作和功能;而培训手册,一定要站在客户业务人员的角度,根据每个角色面对不同业务的办理,如何通过使用本系统的一系列功能来实现目标。所以,第一次培训以前,系统界面是否完整正确、培训文档是否完备、培训时所举的例子是否有代表性都是很关键的因素,第一炮打不响,以后就麻烦很多。
上面讲的是培训的时候,丑媳妇要化妆好再去见公婆的问题。其实,项目实施中还有一个考验项目经理功力的就是如何调动客户积极性的问题。一般来说,客户是懒的,这就是他花钱找你做事情的原因。一个项目的成败,和客户的配合程度很有关系。根据我的分析,一般项目中的客户都可以分