文档介绍：1项目管理心得-国内项目以下为我作为项目经理,管理项目的管理心得,供大家参考!这个项目是什么项目,具体做什么事情,是谁提出来的,目的是解决什么问题。在国内很多客户都很不成熟的情况下,千万不要根据项目的名称望文生义地去想象项目的目标。前期了解情况的工作越详细,后面的惊讶就越少,项目的风险就越小。这个项目里牵涉哪些方面的人,如投资方、具体业务干系方、技术监督方等等,很多项目里除了业主单位的结构很复杂以外,还有一些其他单位也会牵涉进来,如项目监理公司等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望,可以让你在做项目碰到问题的时候,就每件事情分析哪些人会在什么方面支持你,哪些人会出于什么目的反对你,从而提前准备联合朋友去对抗敌人,让事情向你所希望的方向发展。没有永远的朋友,也没有永远的敌人,只有一致的利益。基本了解了客户的情况后,下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视,这个决定了你在需要资源的时候,公司是否会根据你的要求提供最有力的支持。做整体项目计划前,还要大致计算一下目前确定的资源。首先是时间,现在的项目大部分对时间要求都非常紧,一般不会有很充裕的时间。对于这一点,你在做项目的风险控制计划的时候要充分考虑。其次是人员,根据项目预算和已往经验,大致计算一下未来的项目小组有多少种角色,每个角色是否有人,是否能完全归这个项目使用,如果不满足,尽快上报领导决定。最后就是一些设备的准备,项目所需大件关键设备要尽早预定,以后不管发生设备等人还是人等设备的情况,浪费的都是项目的时间。需求规格说明书的时候了。一份好的需求规格说明书不仅将要做的事情描述得很清楚(主要是讲做什么,而不是说怎么做),而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情,也让客户的业务人员(一般不懂技术)知道项目做成什么样就算完成了。项目的阶段计划开始实施了,这个阶段关系到项目的成败关键。在这个阶段涉及到详细设计书、数据库的详细设计、开发、测试等。这个阶段最怕的就是非常频繁需求变更,对于这种需求天天变的客户,你就一定要事先做好规矩:一、统一联系人,客户指定一个人和项目组进行沟通,不能张领导、王领导都来说几句,如果他们意见不一致,那你只有得罪领导的选择了,所以,项目的最初就要定好规矩,我项目组只认一个人的意见,有什么要求你们内部先统一再和我谈,我不想卷入你们内部业务部门之间的矛盾之中; 二、所有需求变更全部要有书面文字,这点切记!这样做好处多多: 有书面证据,以后他还想改,你有了他以前要求的证据,告诉他:你以前可是这么说的;便于需求变更管理,需求如何慢慢演变的历史可以看清楚,从而更深切地体会客户的目的;对于客户来说,嘴巴一动最方便,反正是你们做,不花他的资源,所以要求是否合理,是否和项目的目的一致,他是不负责任的。但是如果要他写书面要求,还要签字盖章,他就要谨慎多了,而且一写东西,思想就会更加深入,很多无理要求也就这样胎死腹中了。在开发过程中,内部管理还要注意的一点是时刻强调以验收为目的的思想,每个任务的最终可交付成果一定要是可以被检查的,比如,界面要求:美观大方、简洁明快,这个要求我就不知道如何检查,只能开发出一个让客户先确定评审签字。7、实施培训到了,给客户做培训前,多注意一些表面功夫。很多程序员认为,系统的逻辑核心是否正确是关键,至于界面如何,界面上的用词是否准确,那是无关紧要的问题,而且培训的时候也是信手拈来,想到哪里说到哪里,下面听讲的人不知所云,云山雾罩,培训效果自然可以想象。我的体会是,给客户做培训的版本,如果你在做多次测试以后仍然不能确定逻辑是否合乎要求,那么,你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等,总之不要让客户看到一些他不该看到的东西。文档方面,准备至少两个文档:用户手册和培训手册。这两个文档的内容很多都是一致的,但是角度完全不同。用户手册往往是站在系统设计者的角度,按照自己的思路,分模块讲解系统的操作和功能;而培训手册,一定要站在客户业务人员的角度,根据每个角色面对不同业务的办理,如何通过使用本系统的一系列功能来实现目标。所以,第一次培训以前,系统界面是否完整正确、培训文档是否完备都是很关键的因素,第一炮打不响,以后就麻烦很多。8、验收前,除了做好文档工作,即可交付成果以外,多花时间搞清楚客户的做事情流程是很重要的事情。我对验收最大的体会就是举证问题。你要让客户明白,所谓验收,就是我按照测试文档的测试用例跑一遍,结果和预期结果一致就应该算通过了,而且还容许有一些小错误留在验收后改正,他可以对测试用例提意见。所以,验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求,那么他应该举证,证明这个系统和最初设计相背离的。2对DJY要