项目经理经验总结

无论是开展项目，还是记录工作过程，都需要通过总结的方式，回顾项目或工作的情况，从中寻找出利于成长的经验，为以后的项目与工作实施，提供相关方面的参考。因此，我们需要在某个时期结束后，写一份总结，下面是小编为大家整理的《项目经理经验总结》相关资料，欢迎阅读！

第一篇：项目经理经验总结

项目经理经验总结

项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况：

01了解这是个什么项目，具体做什么，是由谁提出的，目的是什么

前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。在国内很多甲方都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在你入坑以后一个月才发现其实的是一个计算机生产管理辅助信息系统。

02了解项目牵涉哪些方面的人，如投资方、具体业务相关方、运营方、技术监督方等

项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的。

03了解公司领导对项目的看法

高层领导是否重视，决定了你需要资源的时候，公司是否会为你的提供最有力的支持。领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱?是想做样板工程还是干脆想敷衍了事?公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对项目计划产生直接影响。

04做项目计划前， 大致计算一下你手上的资源

首先是时间，现在市场竞争激烈，往往很多项目要在几乎不可能的时间范围里完成。因此你在做项目的风险控制计划的时候要充分考虑;

其次是人员，根据项目预算和已往经验，大致计算一下项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动;

最后是设备的准备，项目所需大件关键设备要尽早预定，否则以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间。

05现在是做项目说明书的时候了

项目说明书要描述项目做哪些事情、每件事情做到什么程度以及如何检查每一个结果。一份好的项目说明书不仅将要做的事情描述得很清楚，而且把如何检查也说明得很透彻。它不仅说明白了要做哪些事情，也让一般不懂技术的甲方的业务人员知道项目做成什么样就算完成了。

06是到做总体计划的时间了吗?不，你现在已经知道了甲方的目标和你手上的资源，那么做计划以前，你还需要和你的经理、你的甲方充分沟通资源的问题。

因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况，以及如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，那就只能去当烈士了。

很多项目经理都没有自己选择组员的权利，那么就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成很难有什么具体要求，但是一定要有精通甲方业务的人，很多小项目里，这个人就等于项目经理本人。

一般开发和甲方交谈时，会满口的专业术语，搞得甲方一头雾水，有时还会指责甲方不懂技术。其实，明白自己想做什么的甲方已经很好了，不知道自己要做什么，更不懂怎么做还要指手画脚的甲方遍地都是。要明白，是甲方选择了你，而不是你选择了甲方，有了甲方你才有工资拿，心平气和一点吧。

对于需求天天变的甲方，一定要事先做好规矩：

一、统一联系人，只和甲方指定的人员进行沟通。我项目组只认一个人的意见，不要王爸爸、李爸爸都来给我提意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中。

二、所有需求变更全部要有书面文字，这点切记!因为这样做好处多多： 以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的。

便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会甲方的目。

对于甲方来说，只动嘴巴很方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就胎死腹中了。

07现在你要面对三群人：你的领导、你的组员和你的甲方。和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备，这些事情将是你的主要工作。

既然沟通这么重要，那事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是“潜规则”，下面的东西看起来无聊，其实还是很管用的：

第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，保证将信息传达到每个人。这种情况适合小项目，人少。拉的意思就是项目经理就是一个web服务器，你需要什么信息就自己去问他。当然，没有项目经理会把自己搞得那么累去通知每一个人，他会用发布信息到公共介质的方式去公布信息。而潜规则就是我发了你没去看就不要说我没告诉你。当然，这些都是指一般的方式，而

且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。

第二个问题是写文档。为什么有时候项目经理有理却会说不清呢?就是因为没有证据。所以项目经理开始就要和甲方说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让甲方签字。记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。

08好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。

这一节，参考任意找一本项目管理的书都可以。这里强调两点：一，完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让项目减少很多风险;二，把资源投到你熟悉和有把握的事情上，战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。

09好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。

进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要像记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。

项目经理这段时间的主要工作是保持和甲方领导以及公司领导的沟通。和甲方领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，和自己的领导汇报也要注意这个问题。

和组员开会时避免不了有很多讨论会，需要大家用头脑风暴给出解决问题。与会人员很多时候都是技术人员，他们的特点是注重细节、缺乏大局观、自尊心强，所以，你只要负责提出问题和记录下他们的观点，千万不要做评判者。因为技术人员往往精通一个方面，就自己的角度发表见解，他们提出的方案从他们的角

度来看是最合理的。但你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的(而不是正确的)方案。所以，在会议上，你要充分尊重每一个人的意见，千万不要把会议带入无休止的争论。会后，你自己写文档、做决定。会议上大家的面子都被照顾了，自己实施起来的阻力就小。

最终交付成果一定要是可以被检查的，所以给技术小组布置任务的时候就要考虑如何检查结果。有些资深项目经理拿到项目是首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。

10接着，我们再谈谈最让人头痛的需求变更问题。

变更通常分为两种：一种是部分更改了原先的目标，即需求变更;另一种是没改变目标，但是甲方不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：

1.确保以前的文档甲方是否签过字，如果没有，尽快再和甲方自己确认一下你的方案，然后让他签字，避免以后说话没有凭据;

2.和甲方坐下来，探讨他修改的根本目的是什么，是不是有同样能达到相同目的、但是对你来说有代价更小的选择?

3.明确更改流程(项目初期的工作)，一般是甲方签字后以正式项目文件的方式提交给你，然后做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果，然后再让甲方在上面签字。见过医院给病人做手术以前让家人签的免责条款吗?对，就学习那个，让大家都意识到任何的更改都有成本和代价。

11系统开发告一段落后，就进入甲方培训、系统验收阶段。

给甲方做培训前，多注意一些表面功夫，至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等，不要让甲方看到一些他不该看到的东西。

作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的。考虑问题的轻重缓急方面，各方领导都会给你最后期限，所以保进度是第一位的;省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住;好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了;最后是多，甲方的要求源源不断，如何降低甲方的期望值，让他们从理想回到现实也是项目经理的分内工作。

验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚甲方的做事情流程是很重要的事情。要让甲方明白，所谓验收，就是按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。

最后，认为系统完美了才能验收的想法也是错误的，微软那么多天才，做了XP还要天天打补丁，软件开发合同里一定要注明验收以后维护期的费用问题，否则，甲方担心一旦验收就得不到你们的支持，自然不配合验收，那么你这个项目经理就很难交功课了。

第二篇：项目经理经验总结

作为一个项目负责人，一定要明白这个工作最要紧的就是要明白什么是因地制宜、因势利导;只有最合适的，没有什么叫对的，什么叫错的。项目负责人最忌讳的就是有完美主义倾向，尤其是从做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。

项目前期阶段是一个项目最重要的阶段。项目负责人在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：

1、 这个项目是什么项目?具体大概做什么事情?是谁提出来的?目的是解决什么问题?

项目前期对工程情况了解的越详细，工作做的越细致，后面的“惊讶”就越少，项目的风险就越小;

2、 这个项目里牵涉哪些方面的人?如投资方、建设方、项目建成后的运营管理方、技术监督方等等。

项目负责人需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面对这个项目的看法和期望，可以让你在做项目碰到问题的时候，就每件事情具体分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。

没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目负责人是一定要记住的;

3、 基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。

首先是高层领导是否重视，这个决定了在你需要资金、人力等资源支持的时候，公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的，但你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是只想赚点钱?是想做样板工程还是干脆想敷衍了事。

公司领导(尤其是高层领导)对项目的态度决定了你做这个项目的战略目标，而这个战略方针将对你做项目计划产生直接的影响;

4、 在做整体项目计划前，还要大致计算一下你手上的资源。

首先是时间。现在市场竞争非常激烈，有一些项目会要求在几乎不可能完成的时间范围里完成。对于这一点，你在做项目的风险控制计划的时候要充分考虑。

其次是人员。根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。

最后就是一些设备的准备。项目所需大件关键设备生产周期很长，所以要尽早订货，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间;

5、 是到做总体计划的时间了吗?不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的领导和客户充分沟通资源的问题。

因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目负责人不能尽早发现风险，那么就只能去当烈士了。

6、 明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。

很多项目负责人都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，

7、 现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作

第三篇：项目经理经验总结内容介绍

项目经理是在施工管理实施阶段全面负责的最高项目管理者，是企业在项目上的委托代理人。在施工过程中，项目经理是协调各方关系、使之相互紧密协作配合的桥梁和纽带，是对施工项目实行控制各种信息的集散中心，自下、自外而来的信息通过各种渠道汇集到项目经理手中，通过指令计划和办法，对下对外发布信息，通过信息的集散达到控制的目的。搞好一个项目既是对公司负责也是对自己的团队负责，在项目管理过程中，作为第一领导者一定要以身作则、要以诚待人。项目管理亦是经营管理，就如经营一项生意，无非是为了赚到利润，作为项目经理，要反复吃透其中的设计意图，琢磨施工的关键工序，细心布置施工规划，从中寻找利润空间。当然好管理才能出高效益，项目管理又分为内部管理和现场管理。内部管理的第一要务是用人，按岗选人、各司其职，建立健全各项管理制度，加大检查、评估、考核力度，规范管理。现场管理最重要的要亲历亲为，全方位管理，使现场管理的各项工作有条不紊顺利进行。作为一名项目经理，就多年来本人在项目管理中的责任成本管理、安全生产管理、质量管理总结出一下几点自己的心得体会。

1、加强施工质量管理，切实把质量作为本项目部工作中心

2、切实编制科学合理的施工进度计划，缩短有效工期

3、逐步完善技术管理体系，健全技术管理制度

4、编制施工成本计划、做好项目成本的全过程控制

从项目管理工作五大控制入手，分别对施工管理、技术管理、HSE管理、成本管理、人力资源现状及队伍建设、精神文明建设及企业文化推进、项目施工管理中的不足、下阶段的工作计划、建议等涉及到项目管理工作的九个方面进行了总结分析

第四篇：项目经理心得体会与经验

十四冶项目管理培训心得

创鑫公司

工程部

李自光

一. 项目要进行整体管理，善始善终

整个项目开始要做好项目整体计划，在项目的整个过程中，始终要按照项目计划执行，如若遇到项目发生变更，要进行影响分析，得到批准后制定变更计划，并按变更计划执行。变更的影响情况，如：费用，时间进度等要通知相关的项目利益干系人，说明变更的原因和产生的影响。 项目首尾工作也是项目管理中，一项重要的工作。需要将项目过程中产生的文件资料进行整理，归档;对项目的费用和进度进行审计和审核，对项目的质量进行检验和验收;对项目的整个过程的利弊得失进行总结和交流。

变更计划在软件项目中经常遇到。控制好软件项目的变更，首先需要做好项目的开始目标基准的确定，基准的用户需求明确，才能衡量出哪些是需要变更的。否则变更的东西和开始要求的东西混在一起，变更计划就无从制定，变更的界限也无从划清。

自己做过的一个项目，开始为了占领市场和尽快拿下合同，在用户需求还没有详细提供的条件下，就与用户签定了合同，后来不仅费用受到限制，就连时间不够，在项目过程中，用户方还总是变更软件的功能和要求。因为没有一个基点，我们认为是变更需求和新增功能，而用户方认为是合同范围，不能因此增加费用和时间。这个项目在开始好象签定了合同我们争取了主动，其实需求不明确，使我们在后来的项目进程中一直处于被动。 所以项目从一开始就要做好计划，搞清目标。只有项目的目标明确，合理安排时间、费用、人力和其他资源，控制好项目的变更，这些是保证项目能够顺利完成的基本条件。

二. 项目范围管理理论解决了项目开始需求不清的问题

需求管理是项目范围管理中的问题，这是因为它实际上是开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在其他关键过程中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。

什么需求?需求是指“分配给软件的系统需求”，或者更简洁地说，“分配需求”。这些需求有可能是技术方面的(比如：功能和性能需求)，也有可能是非技术方面的(比如：发布日期，开支限度)。 区分开需求管理和软件需求分析是很重要的。一旦分配需求被文档化，并且被所有受影响部门(客户，系统工程，软件工程)通过，需求管理的基本工作就完成了，所剩下的就是管理变更而已。没有证据证明分配需求本身就可以十分清楚完整的作为软件开发的全部基础。事实上，通常它们不是。 优化和精确描述需求，填补漏洞，将含义表达得更清楚是软件需求分析要做的，分析的结果被称为“软件需求“。这样，作为需求管理的输出的分配需求实际上就成了软件需求分析的输入。需求管理远远先于软件开发的技术行动，而软件需求分析则是关键开发技术行为的第一步。从这里的描述看来，需求管理的活动简直太简单，太基础了，显然没有哪个软件开发组织会不有效的进行着这种活动。问题经常出在企业对透明度的惧怕。客户觉得保持需求含糊不清，松散或者无正式文件能够给他们

更多的机会去说：“那并不是我所要的，那并不是我认为的需求的含义”。文档化清晰的需求可能迫使用户在系统满足了文档化的需求但没有满足实际需要的情况下，为开始变更负责。相似地，开发人员觉得含糊不清，松散或者无正式文件的需求能给他们更大的余地，允许他们与预算和进度尽可能地接近，然后说：“这就是我们所认为的需求的含义，如果你需要其他的什么东西，你必须另外付出代价。”文档化清晰的需求会迫使开发者承担满足这些需求的义务，并使他们暴露于开支、进度评估不准确的风险之下。

这样一来，尽管客户与开发人员的利益动机相对，但他们却走到了一起。每一方都认为他们在保护自己的利益，巩固自己讨价还价的地位，但是事实上每一方都在走向将来的失望和争吵，为项目埋下了一刻定时炸弹。

三.项目时间管理理论指导我们在项目管理中怎样抓主要矛盾 。

以前进行项目管理时，是根据经验和每个人的工作特点，进行项目的分工的，软件项目基本是按照需求分析，概要设计，详细设计，代码编程，调试和测试，用户验收等几个主要过程来进行的。但将项目分工更加细化，每个小过程的时间估算是多少，整个项目可以最短用多少时间来完成，怎样合理安排人员，怎样抓项目中的关键环节等等，这些都没有进行过量化的分析和管理。 项目管理的实施最为直观的就是缩短项目时间。利用项目管理理论、方法，有许多缩短时间的例子。美国路易斯维化工厂检修时把检修流程精细分解，按导向图建立起控制关系。他们惊奇地发现，检修过程选择不同路径总时间是有差别的。通过反复压缩最长路径上的任务，将工期反复优化，最后只用78个小时就完成了通常需125小时完成的检修，节省时间38%。这就是至今项目管理工作者还在应用的著名的时间管理技术CPM，即“关键路径法”。 所以我们在软件的项目管理中，也要将时间控制理论运用进来，结合软件工程的实际，将任务分解的更加详细，并用网络图将整个工作过程建立起来，估算好每个阶段的历时，找出关键路径，并通过快速跟进方法，将关键路径的工期缩短，以提高工效。

四. 质量管理是项目成败的关键

我们在进行软件项目过程中，对软件的功能测试一直认为还是比较认真和严格的，每次测试都要有测试计划和用例的编写，然后才能进行测试;测试要有记录，并将记录整理成测试报告。 但通过此次培训后，感觉到我们的测试工作与质量管理的要求还差的远，有距离。质量控制要深入到每个与项目相关的人，要深入到项目的每个过程中，从一开始，就要树立质量第一的理念，每个过程都要进行质量的控制，而不是到最好测试时，才想到质量，才去衡量是否符合标准。标准化设计，标准化管理是项目质量的保证。参加质量体系认证有助于企业提高项目的管理水平，有利于提高工程项目质量。CMM模型已得到广泛的认可和接受，CMMI沿用其模型的组织方式，有5个等级和18个要素。通过5个等级的认证和加强管理，企业对项目的管理将经过5个境界的提高：从混乱，到里程碑的检查，到定义清楚的管理体系和标准，到进行统计过程控制量化管理，到最后的优化过程、评价工作流程、进行工作过程的改进。 本人以前参加过为日本软件进行部分功能的设计和编程工作。日本的软件企业对一个项目的质量控制就做的比较细致，用我们的观念衡量简直是不可容忍。做一个模块的详细设计，要用他们提供的标准的图形语言进行描述，用标准的设计摸版进行说明;并在设计完成后组织相关人员对这个设计进行评价，有问题需要修改设计，然后在评价直到通过才能开时以此为设计文件，进行代码。代码写完后，不是见到结果就完事了，要将代码打印出来，相关人员对代码的整个实现过程进行评价，提出修改建议，代码修改后，需要再审，也是通过以后才能提交入代码库，进行代码的组装。 当时认为日本的方法太浪费时间和人力了，对技术人员个人的能力估计的太低，怎么能提高工

作效率呐。可是软件质量问题的频繁出现，是我们不断的认识到，开始浪费一些时间和人力，控制好每个细节的质量，就是省去了许多时候为解决质量问题而进行的新的时间和人力的支出。省去了大量的软件后期的质量维护费用。总的来看是核算的。为提高项目的质量，降低成本，必须从项目的开始就要做好质量的控制工作。

五. 沟通管理中的一些策略的使用可以使项目更好的完成

做项目就需要与客户接触，就会出现一些正式和非正式的谈判。双方都会为自己方的利益而进行讨价还价。与客户之间搞好沟通，是项目进展是否顺利的一个条件。沟通中有许多的策略在平时的实际工作中可以使用，目的不是坑害别人，而是为了更好地完成项目，达到双方事先确定的目标，而采用的一些艺术手段而已。沟通的技巧包括：下达最终期限，使用吃惊方法，采用有限权利法，不露面的人，公平合理，战略延迟，双方一起论理，撤退，不合理，既成事实等。本人就是成功的采用了战略延迟法，将客户方的一笔项目质保金及时地催要了回来。 体会还有很多，总之通过这次学习自己对项目的管理又有了新的认识，我会将这些理论知识运用到实际工作中去的。以提高项目的管理水平，提高项目的质量，降低项目的成本，降低项目的风险，最终提高企业的效益。

第五篇：项目经理经验

项目经理是什么?

Q: 项目经理是什么?

项目经理是公司委派，负责实现项目目标的个人，是公司授权的项目负责人，是项目的直 接组织者和管理者。

Q：项目经理的职责是什么?

   对项目全过程进行组织和管理，按预期交付项目的成果 管理客户关系，以取得客户对交付的成果和过程最满意的评价 管理项目团队，使之高效而愉快的工作，并获得最满意的工作体验 Q：IT项目经理的主要任务是什么?

1. 支持售前过程。IT项目一般比较复杂，交付风险大，需要在合同中约定工作范2. 3. 4. 5. 围，进度 计划要估算成本和人力资源，制定切实可行的实施方案。

负责项目交付。围绕目标，按照规范执行项目计划。按期汇报进度，保证项目在计划内 交付。

完成项目收尾。完成交付成果之后，要讲成果转移给客户，确保客户可以稳定地使用系 统。

管理干系人的关系。沟通各方人员信息，保持密切联系，解决矛盾冲突。

管理项目团队。寻找合适的资源，优化资源配置，建立合理的组织结构，确定清晰的职 责分工，打造高效的项目团队。 需要什么素质?

领导力。领导力是指通过他人来完成工作的能力。领导力并不意味着『官』，而应 该是『领头的』。不仅要求别人做的自己能做到，而且要知道『下一步』，目标在哪里。

责任心。出于对承诺的负责，会倾尽全力达成目标。 积极主动。善于利用自身的优势改变局势。

压力承受。需要在压力中仍能保持镇定，冷静思考。 需要的知识和技能 专业知识

   1.

2. 3. 4.

项目管理专业知识 IT技术 行业知识

实践技能

 商务技能。要代表公司管理项目，履行合同。  项目启动。真正进入项目的第一个阶段往往是最慌乱的，必须清楚知道每天要做什么，这 样才能有条不紊。

计划的制定需要工具和平台，执行需要推进，质量需要把控。明确质量管理内容，以及在 什么情况下有权利喊『停』。 

软技能

   沟通和协调。沟通包括识别沟通对象，建立沟通渠道，明确沟通信息。 团队和激励。必须让成员能够团结，为了共同的目标而努力。 政治和文化。

项目启动的第一周

项目启动时，需要做的事情：

  建立组织和制度。建立组织结构，确定职责分工，确定基本规章制度和工作流程。 明确工作思路。一边是要确认工作范围，制定工作计划;另一边要确定开发方法，特别是 马上要确定需求文档格式和工作流程。

启动的准备工作

1. 确认项目范围。项目中范围包括两大类：一类是产品范围，也就是应该覆盖的业务 需求;一类是为了实现项目目标所需要完成的工作。 将功能层级进行约定：

1. 子系统：指相对比较独立、功能完整一组业务功能。 2. 功能集：指在子系统内，按照业务特性归集的一组操作。 3. 执行单元：一次完成的一个独立业务操作。

粗略工作量估算。

人力资源的配置。

确定开发过程。按照项目的实际情况，制定一个《项目开发过程》的文件。明确项 目的开发阶段，明确各阶段的交付物，制定交付物的模板。 群策群力，制定项目计划的方法

    根据WBS方法指定活动清单。 确定活动之间的依赖，绘制网络图。

根据网络图的依赖关系和工期需求，分配资源，确定进度计划和资源计划。 根据资源和进度计划，制定项目预算。

通过需求矩阵，进行具体项目管理

需求矩阵按照子系统、功能集和执行单元的结构列出所有的功能需求，每列对应每项工作的 工作步骤以及每个步骤的工作量。

制定活动清单

计划过程的步骤如下：

排序和网络图分析

有了活动清单和依赖关系，就可以进行排序了。我们可以使用节点表示任务，用箭头表示依 赖关系。

通过对网络图进行分析，可以得到项目与时间相关的一些重要信息：    给定项目的预计和开始时间，能够计算每项活动必须开始和完成的最早时间。 给定项目的要求完工时间，能够计算每项活动必须开始和完成的最晚时间。 确定项目的关键路径，也就是最长活动路径。

资源和进度计划

进度计划是将工作计划安排到日历上，它不仅规定了整个项目各个阶段的起止日期，还规定 了所有项目的开始和结束日期。可以使用甘特图进行项目中的进度管理。 进度计划排定时，重点考虑两点：

  资源的使用情况是否合理，是否存在资源冲突的情况。

对于那些有较大浮动时间的活动，可以初步确定是越早开始越好，还是越晚开始越好。

执行和检查

对于辛苦制定地计划，如何让每个人按照计划工作?如果知道每个人的工作进展?

阻碍计划落地执行的原因

主要计划落地的主要原因有两点：

 没有将计划细分，个人和计划之间缺少一个桥梁。但是将计划拆分到每天做什么也不现实， 所以，这里是一个工作的难点。 执行项目的人员之间水平有差异。 

任务的分解和委派

为了解决上述问题，初步有了以下方案：

1. 每组安周一周作为单位指定落实到个人头上的计划，制定一份一周工作计划表。 2. 一周工作计划表每天检查，如果出现了异常，随时修改。 3. 周五大家根据一周的工作内容，整理工作周报。 这个方法是不错。但是如果将工作分解到每天的粒度呢?

基本思路是将工作按照工作的流程，分解为『关键步骤』，每项任务的一项关键步骤，作为 一个人的工作任务，也是最小的管理单元。个人工作任务只有『完成』和『未完成』两种状 态。

检查和调整

为了有效控制和掌握进度，检查和调整是很重要的一个环节。 每日记录

每天下班前，可由相关人员自己在标记当日工作计划的完成情况，有完成、延迟完成和延迟 中三种状态，并进行汇总统计。并且可以提出自己的问题，由相关人员讨论解决问题或者安 排时间专门讨论。 周例会

周例会检查和调整项目计划，需要一定的讨论，讨论的重点是：任务完成了吗?没完成的原 因是什么?怎么调整?

质量管理 管什么?

经过多年的发展，质量管理已经有了一套基本的理论和方法。质量管理包括质量保证和质量 控制两大类。质量保证是指在项目过程中实施的有计划、有系统的活动，确保满足相关的标 准，典型的例子是评审和审计。质量控制是指采取适当的方法监控项目结果，确保结果符合 质量标准，典型的例子就是测试以及之后的缺陷跟踪。

在IT行业软件开发领域中，常见的公认的质量活动包括：配置管理、评审、测试以及缺陷跟 踪。

  评审：检查项目中间产品，早期发现缺陷以减少后期项目返工和修改的工作量。

测试：直接检测软件产品中的缺陷，确保符合质量要求。一般通过单元测试、集成测试、 系统测试和性能测试实现。

缺陷跟踪：记录和追踪缺陷从发现到解决的整个过程，确保所有的结论都有结论。 审计：对项目工作过程进行检查，确保所有活动按照规程进行。 变更控制：版本本更控制，也是重要的一环。

配置管理：记录中间和最终产品(配置项)的变更历史。 质量经理在项目中的职责如下：          贯彻公司的质量管理规范，负责质量管理过程中的检查和指导。 负责制定项目开发/测试环境的标准和规范。

负责项目的配置管理，通过权限控制和备份机制确保交付物的完备和安全。 负责组织同行评审，确保中间交付物的质量。

制定测试策略和测试计划，组织测试，确保最终交付成果的质量。

项目配置管理

项目配置管理是一项看不见的财富，可以在无形中减少因为版本意外等开发中出现的问题导 致的返工、重做等资源浪费。 Q: 什么是项目配置管理?

配置管理是在某一特定时点，确定软件配置的一个过程，通过对已标识的软件配置的一个过 程，通过对已表示的软件的配置的变更进行系统控制，从而在整个软件生命周期中保持软件 的整体性和可追溯性。 Q: 配置管理的具体要做什么?

通常来说，软件配置管理主要通过计划、标识和控制变更和发布配置状态报告来协调软件开 发，目的是使错误率达到最小并最有效地提高生产效率。

质量评审

评审的目的是尽早发现问题，一团和气的评审会完全达不到发现问题的目的。 Q: 评审中的角色有哪些?

首先要把评审中设计到的各个人员确认下来。评审过程中涉及的角色主要有四种：责任人、 主审人、评审专家和记录员。

主审人要先选定评审组的成员，然后再做评审的前期准备。在 评审过程中保证规范和高效， 评审结束后要将结果及时发布被评审相关人员。最后，还要对 评审中发现的问题追踪，直 到问题关闭。

责任人就是要被评审的对象。他们在评审之前准备好资料，在评审过程中解答提出的问题。 对于发现的问题要积极修正后提交给主审人。

记录员就是在评审过程中，把专家提出的问题都记录下来，还要记录责任人的回答信息，最 终要行程会议纪要，并且记录评审结果。

评审专家要彻底了解被评审的资料，其任务是寻找这些资料中的缺陷，侧重于发现问题而不 是解决问题。要保持客观。 Q: 评审的过程是什么?

评审的过程分为计划、预备会议、准备、评审会议和追踪几个阶段。

 计划阶段与项目计划同步，也就是说项目中有哪些要评审在项目计划中就已经提前定义好 了。

预备会议，针对要评审的资料对评审组进行培训，并讨论评审资料。 准备工作，是评审专家要彻底熟悉评审资料，以保证评审的质量和高效。 评审会议，是主审人和评审专家对项目资料中的错误和缺陷进行确认。 跟踪，主审人要确保责任人采取必要的措施修正发现的错误。 一个评审反馈表如下：    

让测试深入人心

保证质量最有效的措施就是测试。 Q: 为什么要有多种测试呢?

不同的测试是针对不同的开发活动来设置的。下面是软件测试的一个『V模型』：

 单元测试，主要是开发人员对编写的代码进行自测或相互进行交叉测试，用以检查代码是 否符合编码规范，是否存在逻辑错误。

集成测试，将经过单元测试的模块组装成完整的程序。工作任务包括制定集成测试策略， 确定集成测试步骤，设计集成测试用例，然后逐一添加模块进行测试。

系统测试，是为了验证需求分析确定的功能是否被正确的实现，同时还要对安装、部署、 适应性、安全性、界面等非功能性需求进行测试。

性能测试，用来测试系统是否满足规定的性能需求。性能测试通常选择一些典型的功能， 检验这些功能在大量用户同时使用时是否稳定。

用户验收测试，目的是验证需求与系统的匹配性，以及界面的友好性，响应时间等等。 







缺陷跟踪

Q: 为什么要进行缺陷跟踪?

缺陷跟踪可以记录测试结果，确定代码质量，是确保问题得到解决的一个关键流程。其目的 是规范评审、测试、试运行等过程中发现缺陷的更改活动;跟踪缺陷处理的各个环节、避免 缺陷修改失控和遗漏;如实的反映缺陷处理过程。 Q: 怎么进行缺陷跟踪?

缺陷跟踪的起点是各种发现缺陷的活动，发现缺陷之后就进入了缺陷的跟踪流程，包括提交、 判断、分发、修改、复核和关闭几个关键步骤。

缺陷跟踪除了记录和跟踪缺陷的修复过程，很重要的还有对缺陷进行分类、统计和分析。 缺陷的类型一般分为一下几种：

缺陷类型 描述 可能的缺陷来源 详细设计

架构设计、概要设计 用户界面 用户界面显示或者操作存在问题 架构 接口 系统存在架构方面问题

系统内、外部接口错误，不能正常连接和工作 架构设计、概要设计

需求分析、需求规格 架构设计、概要设计 业务功能 业务功能不完善、未实现或者出现错误 系统功能 与业务无关，但是系统必须实现的功能不完整、未实现或者出现错误 性能 系统的响应时间、吞吐量、并发量等不满足需架构设计、概要设计、求 编码 缺陷类型 描述 可能的缺陷来源 概要设计、编码 概要设计、详细设计 可重用性 不满足被其他系统或者模块复用的要求 可移植性 不满足可跨平台移植或者部署的要求

缺陷的严重性说明了缺陷给最终交付的系统或者产品可能造成的影响程度。其中A级影响程 度最大，E级最小。

严重性等级 描述

A级(系统级) 系统整体崩溃，或者不能稳定地连续工作

B级(应用级) 部分应用或者子系统不能运行，或者不能稳定地连续工作 C级(业务级) 导致业务流程终止，或者因结果错误、数据不一致失败;因安全、容错性和性能问题等非功能性问题影响使用 D级(操作级) 不易于学习使用，界面操作困难;难以理解而不容易使用 E级(文档级) 安装手册、操作手册、在线帮助等文档不能提供帮助或者存在错误

第六篇：项目经理管理心得体会与经验

杭州奥体博览中心主体育场项目经理 赵纯阳

一. 项目要进行整体管理，善始善终

整个项目开始要做好项目整体计划，在项目的整个过程中，始终要按照项目计划执行，如若遇到项目发生变更，要进行影响分析，得到批准后制定变更计划，并按变更计划执行。变更的影响情况，如：费用，时间进度等要通知相关的项目利益干系人，说明变更的原因和产生的影响。

项目首尾工作也是项目管理中，一项重要的工作。需要将项目过程中产生的文件资料进行整理，归档;对项目的费用和进度进行审计和审核，对项目的质量进行检验和验收;对项目的整个过程的利弊得失进行总结和交流。

变更计划在软件项目中经常遇到。控制好软件项目的变更，首先需要做好项目的开始目标基准的确定，基准的用户需求明确，才能衡量出哪些是需要变更的。否则变更的东西和开始要求的东西混在一起，变更计划就无从制定，变更的界限也无从划清。

自己做过的一个项目，开始为了占领市场和尽快拿下合同，在用户需求还没有详细提供的条件下，就与用户签定了合同，后来不仅费用受到限制，就连时间不够，在项目过程中，用户方还总是变更软件的功能和要求。因为没有一个基点，我们认为是变更需求和新增功能，而用户方认为是合同范围，不能因此增加费用和时间。这个项目在开始好象签定了合同我们争取了主动，其实需求不明确，使我们在后来的项目进程中一直处于被动。 所以项目从一开始就要做好计划，搞清目标。只有项目的目标明确，合理安排时间、费用、人力和其他资源，控制好项目的变更，这些是保证项目能够顺利完成的基本条件。

二. 项目范围管理理论解决了项目开始需求不清的问题 需求管理是项目范围管理中的问题，这是因为它实际上是开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在其他关键过程中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。 什么需求?需求是指“分配给软件的系统需求”，或者更简洁地说，“分配需求”。这些需求有可能是技术方面的(比如：功能和性能需求)，也有可能是非技术方面的(比如：发布日期，开支限度)。

区分开需求管理和软件需求分析是很重要的。一旦分配需求被文档化，并且被所有受影响部门(客户，系统工程，软件工程)通过，需求管理的基本工作就完成了，所剩下的就是管理变更而已。没有证据证明分配需求本身就可以十分清楚完整的作为软件开发的全部基础。事实上，通常它们不是。

优化和精确描述需求，填补漏洞，将含义表达得更清楚是软件需求分析要做的，分析的结果被称为“软件需求“。这样，作为需求管理的输出的分配需求实际上就成了软件需求分析的输入。需求管理远远先于软件开发的技术行动，而软件需求分析则是关键开发技术行为的第一步。

从这里的描述看来，需求管理的活动简直太简单，太基础了，显然没有哪个软件开发组织会不有效的进行着这种活动。问题经常出在企业对透明度的惧怕。客户觉得保持需求含糊不清，松散或者无正式文件能够给他们更多的机会去说：“那并不是我所要的，那并不是我认为的需求的含义”。文档化清晰的需求可能迫使用户在系统满足了文档化的需求但没有满足实际需要的情况下，为开始变更负责。相似地，开发人员觉得含糊不清，松散或者无正式文件的需求能给他们更大的余地，允许他们与预算和进度尽可能地接近，然后说：“这就是我们所认为的需求的含义，如果你需要其他的什么东西，你必须另外付出代价。”文档化清晰的需求会迫使开发者承担满足这些需求的义务，并使他们暴露于开支、进度评估不准确的风险之下。

这样一来，尽管客户与开发人员的利益动机相对，但他们却走到了一起。每一方都认为他们在保护自己的利益，巩固自己讨价还价的地位，但是事实上每一方都在走向将来的失望和争吵，为项目埋下了一刻定时炸弹。

三. 质量管理是项目成败的关键

我们在进行软件项目过程中，对软件的功能测试一直认为还是比较认真和严格的，每次测试都要有测试计划和用例的编写，然后才能进行测试;测试要有记录，并将记录整理成测试报告。 但通过此次培训后，感觉到我们的测试工作与质量管理的要求还差的远，有距离。质量控制要深入到每个与项目相关的人，要深入到项目的每个过程中，从一开始，就要树立质量第一的理念，每个过程都要进行质量的控制，而不是到最好测试时，才想到质量，才去衡量是否符合标准。

标准化设计，标准化管理是项目质量的保证。参加质量体系认证有助于企业提高项目的管理水平，有利于提高工程项目质量。CMM模型已得到广泛的认可和接受，CMMI沿用其模型的组织方式，有5个等级和18个要素。通过5个等级的认证和加强管理，企业对项目的管理将经过5个境界的提高：从混乱，到里程碑的检查，到定义清楚的管理体系和标准，到进行统计过程控制量化管理，到最后的优化过程、评价工作流程、进行工作过程的改进。

四. 沟通管理中的一些策略的使用可以使项目更好的完成

做项目就需要与客户接触，就会出现一些正式和非正式的谈判。双方都会为自己方的利益而进行讨价还价。与客户之间搞好沟通，是项目进展是否顺利的一个条件。沟通中有许多的策略在平时的实际工作中可以使用，目的不是坑害别人，而是为了更好地完成项目，达到双方事先确定的目标，而采用的一些艺术手段而已。沟通的技巧包括：下达最终期限，使用吃惊方法，采用有限权利法，不露面的人，公平合理，战略延迟，双方一起论理，撤退，不合理，既成事实等。本人就是成功的采用了战略延迟法，将客户方的一笔项目质保金及时地催要了回来。 体会还有很多，总之通过这次学习自己对项目的管理又有了新的认识，我会将这些理论知识运用到实际工作中去的。以提高项目的管理水平，提高项目的质量，降低项目的成本，降低项目的风险，最终提高企业的效益。