2023年项目管理的心得体会.docx

工程管理的心得体会 工程管理的心得体会篇1工程经理是为工程的成功筹划和执行负总责的人。为此工程经理必须在一系列的工程方案、组织和控制活动中做好领导工作，从而实现工程目标。从职业角度，工程经理是指企业建立以工程经理责任制为核心，对工程实行质量、平安、进度、本钱管理的责任保证体系和全面提高工程管理水平设立的重要管理岗位。工程经理是工程团队的领导者，工程经理首要职责是在预算范围内按时优质地领导工程小组完成全部工程工作内容，并使客户满意。本文分享笔者的工程管理心得。 1、工程要进行整体管理，善始善终 整个工程开始要做好工程整体方案，在工程的整个过程中，始终要按照工程方案执行，如假设遇到工程发生变更，要进行影响分析，得到批准后制定变更方案，并按变更方案执行。变更的影响情况，如：费用，时间进度等要通知相关的工程利益干系人，说明变更的原因和产生的影响。 工程首尾工作也是工程管理中，一项重要的工作。需要将工程过程中产生的文件资料进行整理，归档;对工程的费用和进度进行审计和审核，对工程的质量进行检验和验收;对工程的整个过程的利弊得失进行总结和交流。 变更方案在软件工程中经常遇到。控制好软件工程的变更，首先需要做好工程的开始目标基准确实定，基准的用户需求明确，才能衡量出哪些是需要变更的。否那么变更的东西和开始要求的东西混在一起，变更方案就无从制定，变更的界限也无从划清。 自己做过的一个工程，开始为了占领市场和尽快拿下合同，在用户需求还没有详细提供的条件下，就与用户签定了合同，后来不仅费用受到限制，就连时间不够，在工程过程中，用户方还总是变更软件的功能和要求。因为没有一个基点，我们认为是变更需求和新增功能，而用户方认为是合同范围，不能因此增加费用和时间。这个工程在开始好象签定了合同我们争取了主动，其实需求不明确，使我们在后来的工程进程中一直处于被动。 所以工程从一开始就要做好方案，搞清目标。只有工程的目标明确，合理安排时间、费用、人力和其他资源，控制好工程的变更，这些是保证工程能够顺利完成的根本条件。 2、质量管理是工程成败的关键 我们在进行软件工程过程中，对软件的功能测试一直认为还是比较认真和严格的，每次测试都要有测试方案和用例的编写，然后才能进行测试;测试要有记录，并将记录整理成测试报告。 但通过此次培训后，感觉到我们的测试工作与质量管理的要求还差的远，有距离。质量控制要深入到每个与工程相关的人，要深入到工程的每个过程中，从一开始，就要树立质量第一的理念，每个过程都要进行质量的控制，而不是到最好测试时，才想到质量，才去衡量是否符合标准。 标准化设计，标准化管理是工程质量的保证。参加质量体系认证有助于企业提高工程的管理水平，有利于提高工程工程质量。cmm模型已得到广泛的认可和接受，cmmi沿用其模型的组织方式，有5个等级和18个要素。通过5个等级的认证和加强管理，企业对工程的管理将经过5个境界的提高：从混乱，到里程碑的检查，到定义清楚的管理体系和标准，到进行统计过程控制量化管理，到最后的优化过程、评价工作流程、进行工作过程的改进。 工程管理的心得体会篇2前段时间，我负责了一个工程的管理与开发。在时间短、任务紧，而团队人员又大局部是没有经验的菜鸟的恶劣情况下，我带着接近40人的团队，终于在客户规定的时间范围内如期交付产品。这其中，经历了需求变更、人员变动（因为其它任务，先后有近2023人离开团队）等诸多问题，工程仍然取得了成功，不能不说有几分侥幸，但此外也有一些经验与教训可以与大家分享。 工程开发方面 工程应以需求为核心。一个工程是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于eas工程的特殊性，工程开发过程中能够与客户建立有效快速的沟通渠道，是工程成功的关键。 需求必须获得客户确实认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括工程的目标、范围以及工程需求功能点（用例）。eas工程在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了工程的进度。幸而得到了及时的纠正，在工程管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得工程在客户验收时，有了充分的保证。 工程应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。（软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师）从eas工程的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给工程带来隐患。 工程应指定各个模块的需求接口人。只有这样，才能有效地保证工程组与客户的及时沟通，快速响应客户的请求与反响。eas工程在开发早期及时地确立了需求接口人，在一定程度上躲避了需求变更给工程带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。 注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而工程经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何工程的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。 注意维护需求矩阵。工程经理对这一内容缺乏足够的重视与理解，工程开发过程体系中也缺乏好的需求矩阵文档模板。但是在工程中后期，工程及时撰写了eas工程需求功能列表，并结合交付版本与客户进行了沟通和协商，从而躲避了需求偏差的风险。（需求追踪，任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用） 控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas工程组对于需求变更的响应还不够及时，这一点工程经理与工程管理小组要担负一定的责任。（范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否那么容易引起方案的频繁调整而发生混乱） 第5页 共5页