- 项目经理经验总结 推荐度:
- 项目经理经验总结 推荐度:
- 项目经理经验总结 推荐度:
- 项目经理经验总结 推荐度:
- 项目经理经验总结 推荐度:
- 相关推荐
项目经理的经验总结
总结是对某一特定时间段内的学习和工作生活等表现情况加以回顾和分析的一种书面材料,它可以使我们更有效率,让我们一起来学习写总结吧。那么总结要注意有什么内容呢?下面是小编精心整理的项目经理的经验总结,欢迎大家借鉴与参考,希望对大家有所帮助。
项目开头阶段是一个最重要的阶段。项目经理在接手一个新项目的时候,首先要尽可能地多从各个方面了解项目的状况:
01、了解这是个什么项目,具体做什么,是由谁提出的,目的是什么
前期了解状况的工作越具体,后面的惊异就越少,项目的风险就越小。在国内许多甲方都很不成熟的状况下,千万不要依据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在你入坑以后一个月才发觉其实的是一个计算机生产管理帮助信息系统。
02、了解项目牵涉哪些方面的人,如投资方、具体业务相关方、运营方、技术监督方等
项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望,可以让你在做项目遇到问题的时候,就每件事情分析哪些人会在什么方面支持你,哪些人会出于什么目的反对你,从而提前预备联合伴侣去对抗敌人。没有永久的伴侣,也没有永久的敌人,只有全都的利益,这句话作为项目经理是肯定要记住的。
03、了解公司领导对项目的看法
高层领导是否重视,打算了你需要资源的时候,公司是否会为你的供应最有力的支持。领导口头确定是说支持的,你需要做的是了解公司对这个项目的实际期望,是想把项目越做越大还是想赚钱?是想做样板工程还是干脆想敷衍了事?公司领导对项目的态度打算了你做这个项目的战略,而这个战略方针将对项目方案产生直接影响。
04、做项目方案前,大致计算一下你手上的资源
首先是时间,现在市场竞争激烈,往往许多项目要在几乎不行能的时间范围里完成。因此你在做项目的风险掌握方案的时候要充分考虑;
其次是人员,依据项目预算和已往阅历,大致计算一下项目小组有多少种角色,每个角色目前公司是否有人,是否能完全归这个项目使用,是否需要此外聘请一些人员,聘请的预备工作要尽早启动;
最终是设施的预备,项目所需大件关键设施要尽早预定,否则以后不管发生设施等人还是人等设施的状况,铺张的都是你的时间。
05、现在是做项目说明书的时候了
项目说明书要描述项目做哪些事情、每件事情做到什么程度以及如何检查每一个结果。一份好的项目说明书不仅将要做的事情描述得很清晰,而且把如何检查也说明得很透彻。它不仅说明白了要做哪些事情,也让一般不懂技术的甲方的业务人员知道项目做成什么样就算完成了。
06、是到做总体方案的时间了吗?不,你现在已经知道了甲方的目标和你手上的资源,那么做方案以前,你还需要和你的经理、你的甲方充分沟通资源的问题。
由于许多资源是还不明确的,你需要写一份报告,具体分析这个项目的风险以及对资源的需求状况,以及假如一些问题不能得到解决的话,将发生什么样的后果。假如资源不够,就要高层转变策略,增加对这个项目的投入。甚至在条件许可的状况下,有些公司会放弃这个项目。总之,没有人能完成一个不行能完成的任务,假如项目经理不能尽早发觉风险,那就只能去当烈士了。
许多项目经理都没有自己选择组员的权利,那么就尽量发挥你的影响力去查找那些你想要的人吧。成员的组成很难有什么具体要求,但是肯定要有精通甲方业务的人,许多小项目里,这个人就等于项目经理本人。一般开发和甲方交谈时,会满口的专业术语,搞得甲方一头雾水,有时还会指责甲方不懂技术。其实,明白自己想做什么的甲方已经很好了,不知道自己要做什么,更不懂怎么做还要指手画脚的甲方遍地都是。要明白,是甲方选择了你,而不是你选择了甲方,有了甲方你才有工资拿,心平气和一点吧。
对于需求每天变的甲方,肯定要事先做好法规:
一、统一联系人,只和甲方指定的人员进行沟通。我项目组只认一个人的意见,不要王爸爸、李爸爸都来给我提意见,有什么要求你们内部先统一再和我谈,我不想卷入你们内部业务部门之间的冲突之中。
二、全部需求变更全部要有书面文字,这点切记!由于这样做好处多多:
以后他还想改,你有了他以前要求的证据,告知他:你以前可是这么说的。
便于需求变更管理,需求如何渐渐演化的历史可以看清晰,从而更深切地体会甲方的目。
对于甲方来说,只动嘴巴很便利,反正是你们做,不花他的资源,所以要求是否合理,是否和项目的目的全都,他是不负责任的。但是假如要他写书面要求,还要签字盖章,他就要谨慎多了,而且一写东西,思想就会更深入化,许多无理要求也就胎死腹中了。
07、现在你要面对三群人:你的领导、你的组员和你的甲方。和这些人沟通,让他们知道你准备怎么做,什么时候要他们做什么预备,这些事情将是你的主要工作。
既然沟通这么重要,那事先定义一下沟通的原则也是一件很要紧的事情。许多沟通原则都是“潜规章”,下面的东西看起来无聊,其实还是很管用的:
第一个是规定信息的流淌方式和介质,是推还是拉。推的意思就是项目经理将主动发布信息,保证将信息传达到每个人。这种状况适合小项目,人少。拉的意思就是项目经理就是一个web服务器,你需要什么信息就自己去问他。当然,没有项目经理睬把自己搞得那么累去通知每一个人,他会用发布信息到公共介质的方式去公布信息。而潜规章就是我发了你没去看就不要说我没告知你。当然,这些都是指一般的方式,而且不要确定化,一般状况下,主动沟通和被动访问是同时存在的,尤其是对领导,项目经理更加应当主动去和领导沟通。
其次个问题是写文档。为什么有时候项目经理有理却会说不清呢?就是由于没有证据。所以项目经理开头就要和甲方说清晰有些文档是必需签字的,比如项目经理的项目日志,每个星期至少让甲方签字。记住:说了的就和没说一样,只有写下来大家签字后才算真正发生了的。
08、好了,做了许多前期工作,定义了一些嬉戏规章,现在是坐下来做方案的时候了。
这一节,参考任意找一本项目管理的书都可以。这里强调两点:一,完成一个目标有许多种方式,你要选一种你最熟识的,而不是看上去最完善的,这个思路会让项目削减许多风险;二,把资源投到你熟识和有把握的事情上,战略打算优先级,而正确排列事情的优先级是一个项目经理力量的主要体现。
09、好,现在项目已经完成了前期工作,了解了项目的目标、搞清晰了手上的资源,制定了项目的策略,然后编制了项目的整体方案,项目进入实施阶段。
进入这个阶段反而是项目经理比较空闲的时候,不像前期的时候项目经理要像记者一样处处和不同的人接触,搞清晰他们在说什么,努力猜想他们在想什么和他们的真正目的,那才是最累人的事情。当然,小项目的项目经理往往自己也是一个资源,要做许多事情,这时候反而比谁都苦。
项目经理这段时间的主要工作是保持和甲方领导以及公司领导的沟通。和甲方领导沟通时特殊要留意,除非你需要对方给你支持,那么你才需要讲得具体一点,否则,告知他一切正常就可以了,而且态度要乐观一些,千万不要说一些领导不懂的细节,和自己的领导汇报也要留意这个问题。
和组员开会时避开不了有许多争辩会,需要大家用头脑风暴给出解决问题。与会人员许多时候都是技术人员,他们的特点是留意细节、缺乏大局观、自尊心强,所以,你只要负责提出问题和纪录下他们的观点,千万不要做评判者。由于技术人员往往精通一个方面,就自己的角度发表见解,他们提出的方案从他们的角度来看是最合理的。但你的特长是把握事情的优先级,评估各个方面的轻重缓急,从而依据他们的意见得出一个合适的(而不是正确的)方案。所以,在会议上,你要充分敬重每一个人的意见,千万不要把会议带入无休止的争辩。会后,你自己写文档、做打算。会议上大家的面子都被照看了,自己实施起来的阻力就小。
最终交付成果肯定要是可以被检查的,所以给技术小组布置任务的时候就要考虑如何检查结果。有些资深项目经理拿到项目是首先看如何验收和验收标准,然后打算工作方案。许多项目开头了很久,还不知道如何验收,那么这个项目出问题的可能性就很大了。做项目就是为了验收,我们的角色不是争辩机构,我们的目的就是在付出那么多劳动后得到结果。
10、接着,我们再谈谈最让人头痛的需求变更问题。
变更通常分为两种:一种是部分更改了原先的目标,即需求变更;另一种是没转变目标,但是甲方不满足目前的实现方式,大到流程的实现,小到界面的布局,都是属于这类。这时候,假如需要改并且你的战略是容许这种状况的,那么留意下面几点:
1.确保以前的文档甲方是否签过字,假如没有,尽快再和甲方自己确认一下你的方案,然后让他签字,避开以后说话没有凭据;
2.和甲方坐下来,研讨他修改的根本目的是什么,是不是有同样能达到相同目的、但是对你来说有代价更小的选择?
3.明确更改流程(项目初期的工作),一般是甲方签字后以正式项目文件的方式提交给你,然后做评估分析,分析对成本、进度的影响,在你的领导同意后,出相应意见书,主要是要说明更改设计的缘由和指出由此带来的不确定后果,然后再让甲方在上面签字。见过医院给病人做手术以前让家人签的免责条款吗?对,就学习那个,让大家都意识到任何的更改都有成本和代价。
11、系统开发告一段落后,就进入甲方培训、系统验收阶段。
给甲方做培训前,多留意一些表面功夫,至少要在界面上多花一点功夫。留意每个界面的布局、用词、链接的正确性等,不要让甲方看到一些他不该看到的东西。
作为项目经理,其实脑子里就是几样东西:做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的幻想,这四个方面都是相互冲突的。考虑问题的轻重缓急方面,各方领导都会给你最终期限,所以保进度是第一位的;省是其次位的,企业的根本目的是盈利,假如收入不能增加的话,至少费用要掌握住;好是第三位的,没方法,谁都想精益求精,但是,没有强大的资源保障,质量只好先牺牲了;最终是多,甲方的要求源源不断,如何降低甲方的期望值,让他们从抱负回到现实也是项目经理的分内工作。
验收前,除了做好文档工作,即可交付成果以外,多花时间搞清晰甲方的做事情流程是很重要的事情。要让甲方明白,所谓验收,就是依据测试文档的测试用例跑一遍,结果和预期结果全都就应当算通过了,而且还容许有一些小错误留在验收后改正,他可以对测试用例提意见。所以,验收前双方要确认测试方案和测试用例。
最终,认为系统完善了才能验收的想法也是错误的,微软那么多天才,做了XP还要每天打补丁,软件开发合同里肯定要注明验收以后维护期的费用问题,否则,甲方担忧一旦验收就得不到你们的支持,自然不协作验收,那么你这个项目经理就很难交功课了。
【项目经理的经验总结】相关文章:
经验总结最新05-08
月考经验总结11-07
教研经验总结11-24
军训经验总结11-16
装修经验总结03-09
高考经验总结07-09
物理教学经验总结08-25
小学数学经验总结09-29
学生学习经验总结04-14
个人销售经验总结04-28