心得体会是工作或学习中的体验和领悟到的感受性文字，心得体会是我们日常生活中经常写的感受性文字，下面是总结社小编为您分享的项目总结心得7篇，感谢您的参阅。

项目总结心得篇1

最近两周通过听胡百师老师的讲课和公司同事关于项目管理经验的交流会议，在项目管理上学到不少东西，感受最深的是项目管理就是要合理的利用资源，而人无疑是一切资源中最重要的一环。

我们做任何工作都不是孤立存在的，工作不论繁复，都可以看作是一个项目。而要完成一个项目就需要各式各样的人员整合到一起，扮演不同的角色。如何发挥这些人的特色，分配适合的角色，从而更快更好的完成各自的分工，就是项目最需要考虑到问题了。但要真正发挥每个人都特色却不是这么容易就能做到的。因此就需要我们不断的学习，培养自己的思考力。思考力提高了观察敏锐了，才能发掘出他人的特色，并善加利用。

发掘出每个人都特色并分配好各人在项目中所处的职位后，就需要采取有效的管理来监督把控每个环节，以确保项目能够按照计划执行。以往我们在工作中都接触过各式各样的表格，说起来各个环节似乎都有表格可以监控。可是由于这些表格都是分散开来，针对单独某一个环节的，结果就使得整体管理上缺乏统一性，实施起来难免会出现混乱的感觉。经常出现一个人只着眼自己负责的某一环节，却忽视了整个项目的情况。一旦某一环节上出现了调整，其他人员却无法第一时间得到消息，无法及时作出调整。结果就使得整个项目的工作节奏都被打乱了。

因此就像项目管理经验交流时有人说到的：“表格需要做减法”，我们首先应该以项目为单位，将涉及到的所有环节和资源都整合到一起，这样大家就可以知道自己在这整个项目中所处的位置，了解在项目中于自己相关的前后环节的进展情况，这样执行起计划来就更有依据了。

通过这两次项目管理的经验交流，大家准备已一本书作为一个项目，进行项目管理，设计出适合我们用的项目管理表格。这是与各个部门都相关的工作。一旦做好了，将会大大减少进度管理上的时间成本。使得管理更简单化也更人性化。

希望这项工作能够尽快的展开，尽早制作出适用于我们公司的项目管理表来，相信所有人都会尽力配合的。

项目总结心得篇2

前段时间，我负责了一个项目的管理与开发。在时间短、任务紧，而团队人员又大部分是没有经验的菜鸟的恶劣情况下，我带领接近40人的团队，终于在客户规定 的时间范围内如期交付产品。这其中，经历了需求变更、人员变动(因为其它任务，先后有近10人离开团队)等诸多问题，项目仍然取得了成功，不能不说有几分 侥幸，但此外也有一些经验与教训可以与大家分享。

项目开发方面

项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于eas项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。

需求必须获得客户的确认。通过需求调研与分析后获得的用户需 求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点(用例)。eas项目在前期对需求不够重 视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从 而使得项目在客户验收时，有了充分的保证。

项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。(软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师)从eas项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。

项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接 口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人 意。

注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有 好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生 变更，而开发人员实现的需求也可能会与客户的要求偏差。

注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了eas项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求追踪，任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用)

控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时，这一点项目经理与项目管理小组要担负一定的责任。(范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否则容易引起计划的频繁调整而发生混乱)

项目总结心得篇3

经过这段时间在中国传媒大学凤凰学院的学习，我收获很大，想想2014年3月开始进行这个课程的学习，如今算算也快1年的光景了，通过各个专家教授的讲解，我觉得收获最大是就是把我的思想带到了另外一个高度，作为一个基层的媒体人，平时工作很忙，学习的机会和时间可以说几乎没有，但是当今这个社会又的确发展的太快，单单靠一次学习，就可以受用一生的时代已经一去不复返了，所以我们要时常进行充电。

从《影视项目运营管理实务》、《团队建设与团队管理》、《好莱坞营销体系》等课程的系统学习，我自己的头脑得到了充实，巧妙的是，面对百多人的大课堂，主办者并没有把课堂简单设计成报告会的形式，而是精心安排了每堂课课后由一名学员分享心得、对个别主题开展分组讨论、组织团我们进行经验交流会等环节，让更多的学员积极主动参与到学习中来。如果说专家学者宏观视角的讲授是把大家的思想带进一个更大的格局里，而那些跟我一样在这个课堂里的学员们的互动交流，则让我学习着在这个格局之下，如何在实际工作生活中踏踏实实把脚扎进更深的泥土里。

每次总会格外认真聆听同伴的发言，每次也在默默问自己，假使我站在那个位置，我会如何思考、如何表达。培训班的学员是来自市直机关各单位的团青干部，个个充满朝气，思维异常活跃，当这样一群优秀的青年在一起，碰撞出的不仅仅是思想的火花，也更容易让人比照出自身的差距。所以始终观察着，从他身上、从她身上，从他们身上我应该去学习一种什么品质，掌握一种什么方法，获得什么其他未知领域的新知识、新信息，于是也更加明晰未来的道路上自己身上还有哪些需要完善提升的部分。

项目总结心得篇4

经过五天的java实训，感触很深，收获也很大，对自己的缺点也有了很多的认识，回首本学期java学习，重点还是在学习概念等一些常识性的东西，关于类型、变量、接口、输入输出流、分析异常、抛出异常，后期主要是小程序运用，gui界面设计和事件。

在我学习的语言中，我自己认为java是一门比较强大的面向对象的编程语言，不仅仅是因为它的跨平台型还有它的较强的实用性，强悍的嵌入性。

本次实训主要是针对我们对项目流程不熟悉和对整体项目的把握不清楚，学习数据库的设计和表的建设以及表与表之间的联系，还有一些代码的编写，这些都是我们所不熟悉的也是我们最薄弱的部分。

通过这一周的实训，虽然实训的时间不长，但是总体上收获挺大的，当我们正式准备学习实训java编程技术时，让我感到非常高兴，因为java一直学的是课本知识，所以实训对于我来说是必须要学会熟练操作的。当然开始学习后也并非是想象中那样顺利，开始的学习让我异常感到学习任务的艰巨，因为学习中我遇到了很多以前未曾遇到的难点，有时后也难免会失去耐心，但是，通过老师的指导，自己的努力的练习，我顺利的化解了一道道的障碍。克服了java学习上的一道道难关，现在自己已经基本掌握了java的基础知识。

有些知识点以前没有学过，但我也没有去研究，实训时突然间觉得自己真的有点无知，虽然现在去看依然可以解决问题，但要浪费许多时间，这一点是我必须在以后的学习中加以改进的地方，同时也要督促自己在学习的过程中不断的完善自我。另外一点，也是在实训中必不可少的部分，就是同学之间的互相帮助。所谓”当局者迷，旁观者清”，有些东西感觉自己做的是时候明明没什么错误，偏偏程序运行时就是有错误，让其他同学帮忙看了一下，发现其实是个很小的错误。所以说，相互帮助是很重要的一点，这在以后的工作或生活中也是很关键的。

俗话说：“要想为事业多添一把火，自己就得多添一捆材”。此次实训，我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。

这次实训，我们更多学到的是不懂就要问和自己应该尽自己的全力去尝试，哪怕失败，也要尽自己的全力，和身边的同学一起探讨而不是抄袭，团队合作和发挥团队意识，最后在自己的努力下终于运行成功，这种感觉美不可言，心情愉悦至极，有很强的成就感。

最后，我自己感觉这次实训的收获还是很大的，我相信在不久的将来我们会有自己的一片天空。

项目总结心得篇5

再回首，思考亦多，感慨亦多，收获亦多。“困并收获着，累并 快乐着”成了心曲的旋律， 常鸣耳盼。 对我而言， 四天的学习是难忘、 印记最深的四天。对工作思考方式的转换，心态上的调整、一系列的 适应，压力带来了累的感觉，累中也融进了收获的快乐，在酸甜苦乐 的培训生活中， 让我感受到一种团队精神和力量， 第一节课团队组建， 学员思考互动训练，当所有学员积极参与不顾往日的斯文，将人的本 性、热情、积极的一面显露时，我突然明白什么是真正的团结友谊， 成了我心中永远的记忆，一朵孤芳自赏的花只是美丽，一片互相依偎 着而怒放的锦绣才灿烂。我们生活在一个集体里，唯有团队，才能为 团队增光，为自己添彩，才能促成灿烂的锦绣，团队组建时，我们小 组，设计队名团队旗子及口号时我心里想我们组这么多人呢，再说我 是做技术不擅长这个，让他们做吧，结果我们团队最后一名，第一次 输了，看到我们整个团队落后，我很内疚，惭愧，决定下一次一定要 努力，为团队尽一份力。第二天一早去寻宝，我们队分工明确，有人 去抓会飞的动物， 有去找相思豆， 找相思豆由于太早天黑地方又不熟， 大家都聚到一棵树下，寻找相思豆，找了半天也没找到几个，我当即 改变策略， 找到一个附近的值班保安， 问了他附近哪里还有相思豆树， 经他指路，我们很快就找到一颗，不一会相思豆就收集够数量了，我 们队获得第一名，那一刻我们队爆发出无尽的能量! 在这段学习培训的过程中，不许带电脑，对于一个过分依赖电脑 的我，莫非是一个致命打击!从一个技术方面的人员到项目经理，忽 然转变，完全一个陌生的领域有种老虎吃天的感觉，对我来说是一次 严峻的考验，由于第一轮失误，后来不管是课堂回答问题还是团队游 戏，我们猛虎队都一路领先，最后比第一名仅差两分的成绩，排在了 第二名，曾经我认为没有电脑我什么事也做不了，但现在不一样了， 有了这段精彩生活，将来的路上要面临更多的挑战，我相信只要坚持 到底，决不放弃!没有什么事做不到! 其次，朱总讲的《项目经理素质修养》，让我体会很深、感触很 深，我的内心发生了变化，人没有高低贵贱，只有转变观念，端正心 态，以专业获得肯定，用实力赢得尊重，学历不等于学习力，没有低 素质的员工，只有高标准的管理做我所学，学我所做，树立正确的人 生观，价值观是立身的本质，成才的导向，对未来一切具有强烈的责 任感，以各种方式进行学习，提高自身修养，在人生的这个重要时期 利用我生命的本钱塑造好真、善、责、爱让人生变得更有价值。人生 如流水，我懂得珍惜时间、珍惜生命、珍爱亲情、友情，我会珍惜和 他们相处的每分每秒，用心去关心、了解他们，勇敢面对人生，人生 最大的敌人是自己， 只要突破自我， 我坚信， 只要努力去做， 去奋斗， 目标是一定能实现! 在以后工作中我会全心投入工作，带领团队，尽职尽责，勤奋塌 实，兢兢业业，把所学到的知识，充分融入日常工作中，把工作做到 最好，以此来回报公司领导多年来对我的栽培，我相信会有一个美好 的明天，我会继续努力!

项目总结心得篇6

项目管理的优势是工作目标集中、组织架构灵活高效，劣势是因为项目临时性的特点，成员缺少归属感和安全感，一个项目组织内包括了各个技术领域的人员，成员的职业发展不容易做得好。

近些年逐渐流行起来的矩阵式项目管理，似乎最有希望克服单纯的项目管理或单纯的部门管理的缺点，让项目管理扬长避短，再跨上一个新台阶。在技术风险较高的it项目管理中，更是成了一个时髦的名词。

那么矩阵式管理到底是怎么做的呢?请看下面这张示意表：

我们把部门竖着排成三列，横着切出三个项目，也就是三行，这样的组织结构就像有行有列的矩阵，这就是矩阵管理的最基本含义。这样的组织中，每个成员都有两个领导—项目经理(组长)和部门经理(组长)。根据项目经理和部门经理发挥的管理职能的比例不同，一般又可划分为弱矩阵、平衡矩阵和强矩阵管理，按照项目经理在项目中作用由小到大排列如下：

弱矩阵管理的项目经理一般是由职能部门指派，归部门经理领导，对项目的控制作用很有限，主要依靠部门经理控制项目，项目成员和项目经理都由部门经理进行考核，这种模式适合项目规模较小，基本不跨部门或者某一部门在项目中站绝对主导的情况。平衡矩阵的项目经理是独立于职能部门的，一般是由各部门经理的上一级领导指派，项目经理和部门经理都对项目有一定的控制权，项目经理的主要负责项目的进度、质量、成本，部门经理则负责组织技术攻关、技术培训和成员技术能力提升，项目经理和部门经理共同负责对成员的考核，这种模式适合项目规模较大、技术复杂度较高的情况，很适合it项目的特点。强矩阵类型自然就是以项目经理为主了，部门经理辅助项目经理，这种模式适合项目规模较大、但技术相对简单的情况。

矩阵式管理虽然有诸多好处，但是操作复杂是它最大缺点。矩阵式管理模式下每个成员都有两个领导，这是有悖于传统管理的“常理”的，需要充分宣传引导，谨慎协调。平衡矩阵操作难度最高，就像推独轮车，要不断的关注员工对项目的忠诚度和对部门的忠诚度的变化，要不断的调整，以保持平衡。弱矩阵和强矩阵操作难度也不低，一不小心就会滑到纯项目管理或纯部门管理模式，所谓的矩阵会名存实亡，画蛇添足。

矩阵式管理的另一个缺点就是沟通量大，需要有较强的“沟通管理”能力，否则就会掉入会议的漩涡中。

如果能比较好的处理矩阵式管理的平衡和沟通问题，矩阵式项目管理是非常好的管理模式，对it项目管理必定会有很大好处。

项目总结心得篇7

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

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

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

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

自己做过的一个项目，开始为了占领市场和尽快拿下合同，在用户需求还没有详细提供的条件下，就与用户签定了合同，后来不仅费用受到限制，就连时间不够，在项目过程中，用户方还总是变更软件的功能和要求。因为没有一个基点，我们认为是变更需求和新增功能，而用户方认为是合同范围，不能因此增加费用和时间。这个项目在开始好象签定了合同我们争取了主动，其实需求不明确，使我们在后来的项目进程中一直处于被动。

所以项目从一开始就要做好计划，搞清目标。只有项目的目标明确，合理安排时间、费用、人力和其他资源，控制好项目的变更，这些是保证项目能够顺利完成的基本条件。

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

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

什么需求?需求是指“分配给软件的系统需求”，或者更简洁地说，“分配需求”。这些需求有可能是技术方面的(比如：功能和性能需求)，也有可能是非技术方面的(比如：发布日期，开支限度)。

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

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

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

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

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

以前进行项目管理时，是根据经验和每个人的工作特点，进行项目的分工的，软件项目基本是按照需求分析，概要设计，详细设计，代码编程，调试和测试，用户验收等几个主要过程来进行的。但将项目分工更加细化，每个小过程的时间估算是多少，整个项目可以最短用多少时间来完成，怎样合理安排人员，怎样抓项目中的关键环节等等，这些都没有进行过量化的分析和管理。

项目管理的实施最为直观的就是缩短项目时间。利用项目管理理论、方法，有许多缩短时间的例子。美国路易斯维化

化工厂检修时把检修流程精细分解，按导向图建立起控制关系。他们惊奇地发现，检修过程选择不同路径总时间是有差别的。通过反复压缩最长路径上的任务，将工期反复优化，最后只用78个小时就完成了通常需125小时完成的检修，节省时间38%。这就是至今项目管理工作者还在应用的著名的时间管理技术cpm，即“关键路径法”。

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

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

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

但通过此次培训后，感觉到我们的测试工作与质量管理的要求还差的远，有距离。质量控制要深入到每个与项目相关的人，要深入到项目的每个过程中，从一开始，就要树立质量第一的理念，每个过程都要进行质量的控制，而不是到最好测试时，才想到质量，才去衡量是否符合标准。

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

本人以前参加过为日本软件进行部分功能的设计和编程工作。日本的软件企业对一个项目的质量控制就做的比较细致，用我们的观念衡量简直是不可容忍。做一个模块的详细设计，要用他们提供的标准的图形语言进行描述，用标准的设计摸版进行说明;并在设计完成后组织相关人员对这个设计进行评价，有问题需要修改设计，然后在评价直到通过才能开时以此为设计文件，进行代码。代码写完后，不是见到结果就完事了，要将代码打印出来，相关人员对代码的整个实现过程进行评价，提出修改建议，代码修改后，需要再审，也是通过以后才能提交入代码库，进行代码的组装。

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

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

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

体会还有很多，总之通过这次学习自己对项目的管理又有了新的认识，我会将这些理论知识运用到实际工作中去的。以提高项目的管理水平，提高项目的质量，降低项目的成本，降低项目的风险，最终提高企业的效益。