经理心得体会

时间：2022-04-16 10:37:07 心得体会我要投稿

经理心得体会

　　当我们备受启迪时，不妨将其写成一篇心得体会，让自己铭记于心，这样能够培养人思考的习惯。但是心得体会有什么要求呢？以下是小编帮大家整理的经理心得体会，欢迎大家分享。

经理心得体会

　　经理心得体会1

　　项目经理，顾名思义就是做项目的，一个项目的成功百分百归功于这个项目团队，而失败则百分百责任于项目经理人一人，可能失败的责任归于一人用之过大，但其实不然，作为一个项目经理，首先要对项目的需求、进度等情况了如指掌，知道自己要做什么，正在做什么，下阶段要做什么，当别人问起时，才能脱口而出，不会一问三不知。

　　那么我们需要从哪几个方面来做呢？

　　第一、项目需求：

　　项目经理接到一个项目，首先应该问商务人员索取项目方案书或招标文件，通读全文，对项目有个大概的了解，明确项目范围，知道你的项目应该要做些什么？什么时候开始？什么时候结束？最后自己能提出一些问题！为调研时做好准备工作！有疑问的地方应该找市场人员或售前工程师了解咨询！

　　第二、项目调研：

　　有些人连项目方案书都没看过，就匆匆忙忙去客户处调研了。那么结果就是在跟客户沟通时，一问三不知，很被动，只能听客户讲；客户提出一些不在项目范围内的需求时，你也不知道，只能暂时应承下来！

　　前面一点我提到要找市场人员或售前工程师了解咨询的另一原因就是，客户已经跟我们讲过的问题，如果项目经理再去跟客户提问时，那么就会给客户一种我们内部缺乏沟通的感觉！

　　第三、项目计划：

　　发现在工作中有些人不重视项目计划的制定，有些人可能会说，这个项目太小，周期也不长，几天就搞定了，没必要去浪费时间去做项目计划了。项目不管大小，哪怕只有一个人，哪怕周期再短，我们也要制定项目计划，不同规模的项目，制定的项目计划规模也有所不同。

　　且不管我们制定项目计划祥略与否，但起码已经有了一个好的开始，在以后的工作也不会一团乱麻，主次不分。而制定项目计划的另一个目的，就是明确相关干系人，避免在项目过程中发生推委扯皮现象。该找谁就找谁，应该由谁负责就由谁负责，计划里面很明确。

　　大多项目经理是从技术出身，在制定项目计划时，不要只考虑开发的计划，还应涉及到跟客户的沟通确认，需求调研、商务方面的协调、实施部署、项目验收后的维护等内容！

　　第四、项目沟通：

　　在实际工作中，有些人把项目中遇到的问题仅仅跟客户或项目干系人汇报一下就认为是沟通了，其实不然，所谓沟通用最简单的方式来说就是你所说的内容能得到对方的认可，我认为就算沟通成功了！当然有能力的项目经理会说服对方按你的想法来走。

　　第五、项目协调：

　　在项目实施过程中，不仅要跟客户协调、项目成员协调；还需要跟其他公司的人员进行协调。例如在客户现场开发时，我们需要的办公环境、网络环境都需要事先跟客户协调好，不要到进场时才发现缺这缺那，让客户很被动；又例如硬件情况，如果硬件是其他供应商提供，应协调硬件到位安装的情况，免得我们系统要布暑了，结果服务器也没有。

　　注意点：在对外协调沟通时，最好由项目经理去沟通协调，不要不同的人去跟客户提同一个问题或同一件事，那么客户会很反感！

　　第六、项目控制：

　　常听人说制定好项目计划后，这个项目就成功了一半，那另一半是什么呢？那就是项目控制。很多人作了一个项目计划表，从来就没有跟踪或更新过，这样的项目很难按计划做好，我们应该经常根据项目的实际情况进行调整或变更等，到达每个里程碑时，应该根据计划内容检查这一阶段的交付物（成果）。

　　第七、项目汇报：

　　我们千万不要错过项目汇报的合理时间，在每个阶段应及时对项目情况进行汇报，可以是给老板，也可以是给客户，不管是给谁看，及时性是放在首位的。例如：今天与客户开过了一次沟通的会议，项目延期或变更了，应在第一时间发给相关的人，这里的相关人不仅仅是参加会议的，也包括关注此项目的人。

　　除了以上20%知识之外，另外 80%的东西才是重点：

　　1、协调能力！

　　这是一个合格的项目经理必须具备的能力

　　什么叫协调能力？就是与各色人等打交道的能力。项目经理的职位，在很多外企里其实是没有行政管理的权力的，就是对项目内的成员没有管理的权力，更多的时候做的工作是一个项目协调人。一个项目启动后，项目的成员可能都是临时从各个部门调来的，作为项目经理，需要与各个部门的人去协调每个成员的参与项目的时间期限。项目经理需要安排工作与每个项目成员，人都是一个个体，各种性格都有，如何与不同性格的人交道，这可不是一时半会儿能学得会的。

　　项目经理也需要与上层领导协调，当项目推迟了，如何向领导解释原因，如何向领导申请更多的资金与资源，如何说服领导更加支持这个项目，这都是协调能力的.体现。除此之外，项目经理还需要与客户协调，面对客户漫无边际的需求要求，如何加以限制，面对客户的种种苛求，如何一一化解，当最终产品提交给客户后，如何减少客户的抱怨，尽早的签收，这些都需要项目经理有非常强的，把与项目相关的所有全部摆平的能力。这一点，应该占到 40%的比例，也就是说，如果达到上面两条，你就可以做一个及格的项目经理了。但这还是远远不够的。

　　2、文笔！

　　项目经理几乎可以不用写代码，但更多的工作是写文档以及报告。这几乎占据了项目经理大半的工作时间。从合同到项目计划再到项目报告，项目经理都需要极强的文笔写作功底。清晰，明确是文档的基本要求，更多的时清晰，明确是文档的基本要求从合同到项目计划再到项目报告清晰候，项目经理需要从不同的角度解析同一个问题，而让人得到不同的结果。当然，如果你能把死的写成活的，黑的写成白的，项目经理需要从不同的角度解析同一个问题，而让人得到不同的结果、

　　3、沟通能力！

　　不仅仅是语言沟通能力，还包括察颜观色的能力。项目经理未必需要口若悬河，出口成章，但说出的话一定让人清项目经理未必需要口若悬河，出口成章，项目经理未必需要口若悬河楚的明白；同时，也要通过表情，动作等身材语言，了解对方的内心想法楚的明白同时，也要通过表情，动作等身材语言，了解对方的内心想法。这一点，真得很难，有的人一辈子未必学得同时会与别人沟通。所以，只能看你的天份了。这一点，应该点到 10%。最后 10%，就是抗压能力，作为项目经理，一定要能承受常人不能承受的巨大压力。尤其在项目遇到问题，进展不顺的时候，在成本上升和面尤其在项目遇到问题，进展不顺的时候，尤其在项目遇到问题临着最终期限快到的时候，如何承受并缓解那种压力，不是每一个人都能够做到的。临着最终期限快到的时候，如何承受并缓解那种压力，不是每一个人都能够做到的。如果你遇到一点事就郁郁寡欢，放不下，那在项目的重压之下，会是对你精神与身材的双重折磨。

　　经理心得体会2

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

　　整个项目开始要做好项目整体计划，在项目的整个过程中，始终要按照项目计划执行，如若遇到项目发生变更，要进行影响分析，得到批准后制定变更计划，并按变更计划执行。变更的影响情况，如：费用，时间进度等要通知相关的项目利益干系人，说明变更的原因和产生的影响。项目首尾工作也是项目管理中，一项重要的工作。需要将项目过程中产生的文件资料进行整理，归档；对项目的费用和进度进行审计和审核，对项目的质量进行检验和验收；对项目的整个过程的利弊得失进行总结和交流。变更计划在软件项目中经常遇到。控制好软件项目的变更，首先需要做好项目的开始目标基准的确定，基准的用户需求明确，才能衡量出哪些是需要变更的。否则变更的东西和开始要求的东西混在一起，变更计划就无从制定，变更的界限也无从划清。自己做过的一个项目，开始为了占领市场和尽快拿下合同，在用户需求还没有详细提供的条件下，就与用户签定了合同，后来不仅费用受到限制，就连时间不够，在项目过程中，用户方还总是变更软件的功能和要求。因为没有一个基点，我们认为是变更需求和新增功能，而用户方认为是合同范围，不能因此增加费用和时间。这个项目在开始好象签定了合同我们争取了主动，其实需求不明确，使我们在后来的项目进程中一直处于被动。所以项目从一开始就要做好计划，搞清目标。只有项目的目标明确，合理安排时间、费用、人力和其他资源，控制好项目的变更，这些是保证项目能够顺利完成的基本条件。

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

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

　　什么需求？需求是指“分配给软件的系统需求”，或者更简洁地说，“分配需求”。这些需求有可能是技术方面的（比如：功能和性能需求），也有可能是非技术方面的（比如：发布日期，开支限度）。区分开需求管理和软件需求分析是很重要的。一旦分配需求被文档化，并且被所有受影响部门（客户，系统工程，软件工程）通过，需求管理的基本工作就完成了，所剩下的就是管理变更而已。没有证据证明分配需求本身就可以十分清楚完整的作为软件开发的全部基础。事实上，通常它们不是。优化和精确描述需求，填补漏洞，将含义表达得更清楚是软件需求分析要做的'，分析的结果被称为“软件需求“。这样，作为需求管理的输出的分配需求实际上就成了软件需求分析的输入。需求管理远远先于软件开发的技术行动，而软件需求分析则是关键开发技术行为的第一步。从这里的描述看来，需求管理的活动简直太简单，太基础了，显然没有哪个软件开发组织会不有效的进行着这种活动。问题经常出在企业对透明度的惧怕。客户觉得保持需求含糊不清，松散或者无正式文件能够给他们。更多的机会去说：“那并不是我所要的，那并不是我认为的需求的含义”。文档化清晰的需求可能迫使用户在系统满足了文档化的需求但没有满足实际需要的情况下，为开始变更负责。相似地，开发人员觉得含糊不清，松散或者无正式文件的需求能给他们更大的余地，允许他们与预算和进度尽可能地接近，然后说：“这就是我们所认为的需求的含义，如果你需要其他的什么东西，你必须另外付出代价。”文档化清晰的需求会迫使开发者承担满足这些需求的义务，并使他们暴露于开支、进度评估不准确的风险之下。

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

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

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

【经理心得体会】相关文章：