项目经理管理心得体会范文Word格式文档下载.docx

项目经理管理心得体会范文Word格式文档下载.docx

《项目经理管理心得体会范文Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《项目经理管理心得体会范文Word格式文档下载.docx（7页珍藏版）》请在冰点文库上搜索。

　　变更计划在软件项目中经常遇到。

控制好软件项目的变更，首先需要做好项目的开始目标基准的确定，基准的用户需求明确，才能衡量出哪些是需要变更的。

否则变更的东西和开始要求的东西混在一起，变更计划就无从制定，变更的界限也无从划清。

　　自己做过的一个项目，开始为了占领市场和尽快拿下合同，在用户需求还没有详细提供的条件下，就与用户签定了合同，后来不仅费用受到限制，就连时间不够，在项目过程中，用户方还总是变更软件的功能和要求。

因为没有一个基点，我们认为是变更需求和新增功能，而用户方认为是合同范围，不能因此增加费用和时间。

这个项目在开始好象签定了合同我们争取了主动，其实需求不明确，使我们在后来的项目进程中一直处于被动。

　　所以项目从一开始就要做好计划，搞清目标。

只有项目的目标明确，合理安排时间、费用、人力和其他资源，控制好项目的变更，这些是保证项目能够顺利完成的基本条件。

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

　　需求管理是项目范围管理中的问题，这是因为它实际上是开发过程中的所有管理原则的先决条件。

只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。

实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。

计划、追踪、配置管理以及软件质量保证这些在其他关键过程中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。

　　什么需求?

需求是指“分配给软件的系统需求”，或者更简洁地说，“分配需求”。

这些需求有可能是技术方面的（比如：

功能和性能需求），也有可能是非技术方面的（比如：

发布日期，开支限度）。

　　区分开需求管理和软件需求分析是很重要的。

一旦分配需求被文档化，并且被所有受影响部门（客户，系统工程，软件工程）通过，需求管理的基本工作就完成了，所剩下的就是管理变更而已。

没有证据证明分配需求本身就可以十分清楚完整的作为软件开发的全部基础。

事实上，通常它们不是。

　　优化和精确描述需求，填补漏洞，将含义表达得更清楚是软件需求分析要做的，分析的结果被称为“软件需求”。

这样，作为需求管理的输出的分配需求实际上就成了软件需求分析的输入。

需求管理远远先于软件开发的技术行动，而软件需求分析则是关键开发技术行为的第一步。

　　从这里的描述看来，需求管理的活动简直太简单，太基础了，显然没有哪个软件开发组织会不有效的进行着这种活动。

问题经常出在企业对透明度的惧怕。

客户觉得保持需求含糊不清，松散或者无正式文件能够给他们更多的机会去说：

“那并不是我所要的，那并不是我认为的需求的含义”。

文档化清晰的需求可能迫使用户在系统满足了文档化的需求但没有满足实际需要的情况下，为开始变更负责。

相似地，开发人员觉得含糊不清，松散或者无正式文件的需求能给他们更大的余地，允许他们与预算和进度尽可能地接近，然后说：

“这就是我们所认为的需求的含义，如果你需要其他的什么东西，你必须另外付出代价。

”文档化清晰的需求会迫使开发者承担满足这些需求的义务，并使他们暴露于开支、进度评估不准确的风险之下。

　　这样一来，尽管客户与开发人员的利益动机相对，但他们却走到了一起。

每一方都认为他们在保护自己的利益，巩固自己讨价还价的地位，但是事实上每一方都在走向将来的失望和争吵，为项目埋下了一刻定时炸弹。

（励志天下）

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

　　以前进行项目管理时，是根据经验和每个人的工作特点，进行项目的分工的，软件项目基本是按照需求分析，概要设计，详细设计，代码编程，调试和测试，用户验收等几个主要过程来进行的。

但将项目分工更加细化，每个小过程的时间估算是多少，整个项目可以最短用多少时间来完成，怎样合理安排人员，怎样抓项目中的关键环节等等，这些都没有进行过量化的分析和管理。

　　项目管理的实施最为直观的就是缩短项目时间。

利用项目管理理论、方法，有许多缩短时间的例子。

美国路易斯维化

　　化工厂检修时把检修流程精细分解，按导向图建立起控制关系。

他们惊奇地发现，检修过程选择不同路径总时间是有差别的。

通过反复压缩最长路径上的任务，将工期反复优化，最后只用78个小时就完成了通常需125小时完成的检修，节省时间38%。

这就是至今项目管理工作者还在应用的著名的时间管理技术CPM，即“关键路径法”。

　　所以我们在软件的项目管理中，也要将时间控制理论运用进来，结合软件工程的实际，将任务分解的更加详细，并用网络图将整个工作过程建立起来，估算好每个阶段的历时，找出关键路径，并通过快速跟进方法，将关键路径的工期缩短，以提高工效。

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

　　我们在进行软件项目过程中，对软件的功能测试一直认为还是比较认真和严格的，每次测试都要有测试计划和用例的编写，然后才能进行测试;

测试要有记录，并将记录整理成测试报告。

　　但通过此次培训后，感觉到我们的测试工作与质量管理的要求还差的远，有距离。

质量控制要深入到每个与项目相关的人，要深入到项目的每个过程中，从一开始，就要树立质量第一的理念，每个过程都要进行质量的控制，而不是到最好测试时，才想到质量，才去衡量是否符合标准。

　　标准化设计，标准化管理是项目质量的保证。

参加质量体系认证有助于企业提高项目的管理水平，有利于提高工程项目质量。

CMM模型已得到广泛的认可和接受，CMMI沿用其模型的组织方式，有5个等级和18个要素。

通过5个等级的认证和加强管理，企业对项目的管理将经过5个境界的提高：

从混乱，到里程碑的检查，到定义清楚的管理体系和标准，到进行统计过程控制量化管理，到最后的优化过程、评价工作流程、进行工作过程的改进。

　　本人以前参加过为日本软件进行部分功能的设计和编程工作。

日本的软件企业对一个项目的质量控制就做的比较细致，用我们的观念衡量简直是不可容忍。

做一个模块的详细设计，要用他们提供的标准的图形语言进行描述，用标准的设计摸版进行说明;

并在设计完成后组织相关人员对这个设计进行评价，有问题需要修改设计，然后在评价直到通过才能开时以此为设计文件，进行代码。

代码写完后，不是见到结果就完事了，要将代码打印出来，相关人员对代码的整个实现过程进行评价，提出修改建议，代码修改后，需要再审，也是通过以后才能提交入代码库，进行代码的组装。

　　当时认为日本的方法太浪费时间和人力了，对技术人员个人的能力估计的太低，怎么能提高工作效率呐。

可是软件质量问题的频繁出现，是我们不断的认识到，开始浪费一些时间和人力，控制好每个细节的质量，就是省去了许多时候为解决质量问题而进行的新的时间和人力的支出。

省去了大量的软件后期的质量维护费用。

总的来看是核算的。

为提高项目的质量，降低成本，必须从项目的开始就要做好质量的控制工作。

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

　　做项目就需要与客户接触，就会出现一些正式和非正式的谈判。

双方都会为自己方的利益而进行讨价还价。

与客户之间搞好沟通，是项目进展是否顺利的一个条件。

沟通中有许多的策略在平时的实际工作中可以使用，目的不是坑害别人，而是为了更好地完成项目，达到双方事先确定的目标，而采用的一些艺术手段而已。

沟通的技巧包括：

下达最终期限，使用吃惊方法，采用有限权利法，不露面的人，公平合理，战略延迟，双方一起论理，撤退，不合理，既成事实等。

本人就是成功的采用了战略延迟法，将客户方的一笔项目质保金及时地催要了回来。

　　体会还有很多，总之通过这次学习自己对项目的管理又有了新的认识，我会将这些理论知识运用到实际工作中去的。

以提高项目的管理水平，提高项目的质量，降低项目的成本，降低项目的风险，最终提高企业的效益。

　　项目经理心得体会

　　1、抗住——价值（抗住意味着长久。

项目压力大，时间紧，任务重，客户挑战大，合伙人承担了巨大的项目风险，我们在难得的项目机会历练中，只有找到自己的价值定位，提供价值的切入点，持续输出价值，才能抗住压力赢得客户长久的尊重和认可;

手段是通过抗住压力+快速学习+整合资源，持续为客户创造价值）;

　　2、放下——格局（格局意味着共识。

计较眼前的一城一池容易患得患失，就像张开刺的刺猬一样想随时保护自己，而日久见人心，有胆放下眼前得失，本着长期为企业提供价值，格局增大看长远才能放下，放下了安定下来就能生智慧，对环境有更强的感知，对人的需求及关系、对事情有更强的判断，最后，双方私下感情共鸣，彼此认可，专注做事，大大减少人事上的纠纷;

方法:

气量修炼+真心倾听，才能真正理解企业内各类人群的需求和心声，进而适当团结该团结的、安抚该安抚的、打击该打击的）;

　　3、推进——独立（独立意味着动车组。

1天多次与各模块人员确认，逐渐支持组员独立承担模块，这样不再是项目经理一个人推动项目组往前走，是每个项目模块负责人都是动力源，形成动车组共同发力推进项目组前进，将大大提升工作效率和成果。

做到独立的方法：

精神+专业的双重支持。

项目经理是项目组员坚强的后盾，给予精神和专业上的双重支持和信任，让项目成员敢于尝试并在受伤后得到抚慰并有胆再次上阵PK，逐步积累到独立面对客户;

项目经理则从项目总监、外部资源获取专业上的帮助，自己额外还从重复看《士兵突击》获得精神上的力量和支持。

这样在给予精神上的信任鼓励和专业上的帮助支持后，对于已经良好运转的模块就让负责人单飞，对于不安心的模块需要多次确认多帮助多找资源支持，逐渐支持其独立，完成动车组的打造）。

　　项目管理心得体会范文

　　经理项目管理心得体会要紧的就是要明白什么是因地制宜：

因势利导，只有最合适的，没有什么叫对的，什么叫错的，经理项目管理心得体会最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。

　　本人做经理项目管理心得体会工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，经理项目管理心得体会最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。

以下是本人一些做项目的个人体会，写出来供大家指点，在讨论过程中共同提高水平。

　　项目开始阶段是一个最重要的阶段。

经理项目管理心得体会在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：

　　项目管理心得体会1：

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

在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。

一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。

前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。

　　项目管理心得体会2：

这个项目里牵涉哪些方面的人，如投资方：

具体业务干系方：

项目建成后的运营方：

技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司：

业主的行业主管机构等。

经理项目管理心得体会需要了解每个方面的人对这个项目的看法和期望是什么。

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

没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为经理项目管理心得体会是一定要记住的;

　　项目管理心得体会3：

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

首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。

领导口头肯定是说支持的，你需要做的是了解公司对这个项目管理心得体会的实际期望，是想把项目越做越大还是想赚钱?

是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响;