项目心得（共5篇）由网友“chinatk”投稿提供，下面是小编为大家准备的项目心得，欢迎阅读借鉴。
篇1：项目管理心得
项目开发方面
项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于eas项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。
需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点(用例)。eas项目在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时，有了充分的保证。
项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。(软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师)从eas项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。
项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。
注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。
注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了eas项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求追踪，任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用)
控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时，这一点项目经理与项目管理小组要担负一定的责任。(范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否则容易引起计划的频繁调整而发生混乱)
设计
重视架构设计。eas项目的成功，一定程度是源于我们有个优秀的框架开发小组，我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化，但核心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地提高开发效率，规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完整性和设计统一)
善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下，为了项目进度不出现大的偏差，eas项目组并没有过分强调技术，特别是在考虑进度的情况下，牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患，但却能够有效地保证项目的进度。从eas最初的架构设计来看，我们引入了 castle与aop，试图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时，希望采用wcf，利用soa思想建立松散耦合的面向服务应用程序。但随着客户需求的变化，我们果断地放弃了采用wcf的构想，同时又克服了技术困难，坚持了对castle与aop的使用，并为此成立了框架开发小组。事实证明，在技术的抉择上我们作出了正确的决定。
重视ui原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户，则客户更能够理解系统的实现，促进沟通的有效性与准确性。在eas项目中，我们从一开始就确立了原型设计小组，并在分析需求阶段，就开始了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是，我们在这一点上，由于缺乏专门的ui设计人员，因此，这一工作还存在很大的缺陷，甚至于ui的设计为迭代版本的交付带来了很大的障碍。在项目后期，关于ui的bug是最多。因此，我们认为在开发类似的web应用程序时，应尽早确立ui设计规范，以约束所有的ui设计。同时，必须培养专门的ui设计师，在开始原型设计时，就尽快完成ui交互的设计。并且，必须成立专门的ui 设计小组，在需求阶段与需求分析师合作，在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和减少后期需求变更的重要手段，不一定需要专门的ui设计人员，原型设计可以由需求分析师来完成)
测试
测试成员应了解需求。如果不了解需求，测试人员无法编写正确的测试用例，同时在测试过程中，也可能因为错误地理解需求，从而导致报告错误的bug，影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别，测试人员不用想需求分析人员一样分析和开发业务，但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉)
测试之初必须确定测试原则，对bug的严重程度进行分级。同时，必须确定修复bug的优先级别。
进度管理
保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模，成员情况，技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定，则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最佳的办法，应该是 rup或者敏捷开发，然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。
其次，要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与计划出现偏差。
要制定项目进度偏差的应对方法。一旦项目进度出现了偏差，必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。
作者:张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家(mvp)，著作/译作包括《软件设计精要与模式》、《wcf服务编程》。张逸熟悉c#，asp，wcf等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 soa企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。
篇2：项目管理心得
经过一系列的《it项目管理》课程学习，我觉得这是一门很好的课程，能给我的工作特别是项目的开展和管理方面有很大的帮助，使我获益非浅!在此，我想将学习此门课程的心得总结为一下几点：
一、项目管理就在我们的身边
刚刚开始的时候，觉得项目管理就是一个项目的项目管理者对项目所要涉及到的全部工作、资源等进行有效地管理。然而在学习的过程中渐渐的发现我对项目管理只是表面的认识，正确理解应该是以it项目为对象的系统管理方法，是通过一个临时性的、专门的柔性组织，对项目进行高效率的计划、组织、指导和控制，以实现项目全过程的动态管理和项目目标的综合协调与优化。随着互动案例和学习的深入，我发现项目管理其实就在我们身边，就在我们生活工作的每一个角落，完成任何一项学习或生活任务都可以看做是一个项目的完成。
二、团队是项目管理成功与否的大环境
好的项目团队，应该有一个共同认可的明确的目标、合理的分工协作、良好的信息沟通、队员之间相互信任并且能积极的参与到自己的队伍中。在我们平时的工作中，我们所在的公司是一个大的项目团队，每个部门和每个作业小组就是一个小项目团队。假如项目缺乏积极进取团结向上的团队氛围，项目成员的力量就很难整合在一起，项目成员之间就容易出现相互扯皮推诿指责的情况，项目也就不可能成功。项目经理需要多多关心和照顾项目组成员，让大家都感受到团队的温暖。这样一来项目团队内的气氛浓烈，有利于项目的顺利完成。
三、项目经理是项目管理的灵魂
项目经理是项目管理的角色，是实现项目目标的责任人，同时是一个团队的灵魂人物。项目经理不一定是这个团队中能力最强的人，却是责任最重大的那个。他应该是有较强的意志力、凝聚力，有抗压能力的人，不会轻易被外界和他人影响。当然一个好的项目经理不需要事必躬亲，只要他懂得用贤才，懂信任，懂放权，懂珍惜，这样一来他的团队会凝结出更强的力量，他就是一个优秀的领导。面对的管理点的分散，工作深度的需求，安全责任的落实，作为一个项目经理身上的担子是艰巨的。所以一名好的项目经理是队伍中带头人，项目工作的领路人。
四、沟通是项目管理的桥梁
沟通是项目成功必不可少的桥梁。要做好项目每个阶段的工作，达到预期的效果，就必须在项目组内部以及项目组与外部环境之间建立沟通渠道，快速准确的传递信息从而达到各成员的协调一致;使项目成员明确各自的职责，了解他们的工作对实现项目目标所做的贡献。同时，通过广泛和深入的沟通，找出项目管理的问题，预估项目过程当中的风险，制定相应对策和解决方案，并跟踪控制问题的解决情况。因此，良好的沟通时做好项目管理工作，更好的实现项目目标的重要前提。只有进行有效的沟通才能进行项目研发过程中的决策和实施，以促进项目的顺利和及时完成。
总之，项目管理涉及生活方方面面，是一个非常好的工具。随着经济全球化和市场竞争的日益加剧以及企业业务的复杂化，信息化管理已经成为企业实现战略目标的迫切需要和必要保证。更多的企业认识到必须通过信息化建设才能够实现企业体制创新、技术创新、管理创新，增强企业的核心竞争力。因此，it项目管理的思想已经被越来越多的企业所接受，企业把越来越多精力和资源投入到it项目管理的建设中。在这样的背景下，我们it人需要学习这门课程，了解软件行业的开发流程，抓住软件行业动态从而预测我们将来的努力方向。 这就是我在it项目管理当中的学习心得，希望在接下来的生活、工作和学习中能更好的领悟和运用学习所得。
篇3：程序项目心得
“张小龙在28号谈完小程序当天，我们公司的估值至少了涨了十倍。为什么，因为三天里接了三十多家投资机构的电话，开口第一句话都是说，原来你们做了两年的事情，就是微信小程序要引导这个行业未来开发的事。”
最后一天，从广州的微信公开课现场回到杭州后，我被王德翰和杨万新两个创业者拉去谈了4个小时，听了一个号称价值一千万的实战分享。
原来，阴差阳错下，他俩两年前开始的项目和微信小程序九成相似，除了开发语言没用小程序那套，产品和业务逻辑一模一样.两年时间内，如何推广、如何设计产品、如何规避问题等心得，值得一读。可反推如何运作小程序。
下文，由他两口述，我整理。
01
为什么说我们做了两年的事情，和小程序引导的九成相似?看产品逻辑就知道了。
食在有趣的产品框架结构是，用户扫码，直接跳出h5生成的页面(切换成微信小程序，大概只要三天的开发)，点餐付款，点餐信息在厨房打印出来，商家烧完菜后配送，用户完成一次完整的消费。
这个过程中，不用先关注再打开，不用先下载再打开，不用点完再付现金，不需要服务员介入，不用占一个桌面位置，不用担心在被骚扰。熟悉的用户，可能十秒就完成整个点单操作了。
靠这套产品，我们已经铺设了三千家餐饮店，服务了近100万用户，产生了20万左右的日流水。在长三角地区是排名前三的服务商。
02
依赖二维码入口，打开就用，用完就走，不随意推送……和小程序的思路撞车，不是我们太天才，而是踩着自己挖的坑逼出来的。
两年前，我们自己就开了家互联网主题的咖啡馆，运营过程中就觉得点单这事完全可以用互联网的方式优化。
最早使用蓝牙方案。在餐厅的各个角落放蓝牙设备，只要打开手机的蓝牙功能，使用微信摇一摇，就能跳出店铺，进入后在线点餐，数据直接对接给收银系统，用完餐再去收银台结账。这个流程顾客嫌麻烦，服务员也嫌麻烦，最终放弃。
后来做wifi点餐。用户接入商家wifi后，跳出点餐系统。这事也没走通，现在用户已经没那么在意小流量了，进店问一嘴老板wifi密码都嫌麻烦。也放弃了。
再往后，做app点餐。用户必须下个几兆的app才能享受八折优惠。还是没人用，现在大家的手机都已经被洗得差不多了，常用的就那些。就算贪小便宜装了你的app，拿完优惠也就删。泡沫不持久，还是得放弃。
我们复盘这些教训，发现
1:想用简单服务强制占个app入口的红利早就过去，做不成综合性平台，那就认真做好服务
2:做自然的渠道，而不是试图用截断渠道(wifi)或者创造渠道(蓝牙)
3:形成服务闭环，不要做半吊子的互联网化。都在你这点完餐了，还要去收银系统买单，这个环节就是多此一举的。
4:别拿服务绑架用户。用户用你的场景是在他需要的时候，当用不到你，你却拿着广告味道浓郁的资讯去骚扰他，代价是几千几千的往下掉用户数，看一次就肉疼看两次就不敢再来了。
经由这些教训，我们选择了用贴在餐桌上的二维码作为服务入口，把整个流程简化到不能再轻(用户只需点餐和支付，商家只需收单和烧菜)，不再企图吸用户。
换了二维码方案后，原本要对商家花一小时才能讲清的业务逻辑(什么是蓝牙、什么是wifi入口，为什么推app)，变成了就一句话“用户二维码买单，你们烧菜，其他都不用”，商家一下子就接受了。用户数井喷式增长。
03
实战中，二维码点餐这样的典型小程序应用能够被快速推起来，我们的商务团队一般是这样说服商家的：
1:用户体验。在用餐高峰期，用户平均等待10分钟，用餐8分钟，换成二维码方案后，平均单个用户点两个餐的时间缩短为29秒，只要厨房烧得过来就好。
2:服务员成本。中小餐饮店，一般都会请全职和兼职的服务员，用来应对高峰期。换成二维码方案后，可以节省2个兼职人员，按12元/小时，每天工作3小时计算，每年节省2万多元开支。
3:硬件成本。一套传统的餐饮解决方案，包括打印机、扫码枪、钱箱等，平均在3000-8000一套，二维码方案只需要一个600元的打印机和不超过50元的二维码贴桌成本。
4:防止逃单。由于微信支付已经成熟，我们使用了预付费模式，就是用户点了餐就直接付钱，厨房接到的单子都是支付过的。不会再出现逃单、假币等问题。就算要退单这种低概率的事情，业务流程也只需要商家确认就把钱退回来。如果使用后付费模式，那么二维码一旦被人偷走，他就故意乱点餐(反正不用付钱)，把服务员忙的团团转还找不到谁点的，来个一两次，这个餐馆就不会再里你了。
5:数据沉淀。既然是二维码方案，用户的id、支付记录等自然而然进了商家管理app里，想设置老用户优惠、发微信会员卡、经营分析等都很顺畅。
04
小程序应用能够真正起来，是必须理解线下的业务。纯互联网玩法是推进不了的，必须是又懂互联网又懂线下的复合型人才，例如我们这样花过上千万学费的。
这里有5个小经验：
1：二维码材质。二维码的材料选择，在不同的场景下，材料也不相同。快餐厅，只需要pvc材质即可，表面光滑易擦干净;烧烤店等需要特别的塑料材料，防烫坏;酒吧里面灯光较暗，需要使用荧光材质二维码或者镂空的里面放个灯的装饰二维码。商家也会根据自己的餐厅风格，需要定制或者选择与自己餐厅的格调能够配搭的二维码样式风格，有一些可能还会在二维码下方写一些slogan。
2：二维码设置。如果店铺只有一个二维码，是解决不了顾客在哪个餐桌上点餐的问题。一桌一码又解决不了拼桌、二维码材质破损的问题，最后是二维码与餐桌之间只是一个连接的关系，二维码破损了可以换，有拼桌的需求，可以多贴几个二维码，完全由餐厅老板自己控制。
3：小程序只能也必须做轻量级交互。一旦碰线下市场，不同店铺就有不同个性化需求，什么加辣加葱、什么活鱼要按几斤几两再去算账，什么同样一壶咖啡一人喝半价中途来了人就得算全价，什么不管要不要都收茶位费……如果试图做个性化方案，你有再多的程序员也会被累死，产品的交互也会越来越臃肿。你必须坚定“小程序就得小”，只做标准化的事情，做不了的市场宁可放弃。线下几万亿的市场，做好一块就够你吃香喝辣的了。
4：别抵触硬件。身边做互联网的人，经常喜欢跳过硬件，做无机具的场景。至少在餐饮业，这个走不通。我们测试过不用打印机打菜单，而是把菜单信息发送到厨师手机上，结果厨师要么手太油弄脏手机、要么只有厨师看到配菜师没看到而降低了上菜效率，要么无法确认漏单没等。一般来说，做互联网化餐饮解决方案，要么用电视级大屏幕显示点单信息，要么用打印机。我们选的是成本最低的打印机方案。
5:刺激商家。和纯互联网的流量推广方式不同，线下市场不能用aso、广告展示、弹窗、绑定安装这些方式了，产品能不能活跃起来，依赖的唯一渠道是商家。做好产品体验，帮商家提高效率这是肯定要做透的，但这个不够，这叫隐性提高，感知不强，只有部分年轻而又新进的老板才理解。能刺激到普通商家的，还是要做一些显性服务，例如补贴、例如异业合作、例如帮忙推广等。也就是说，线下业务不能只盯着用户，要把商家那头的利益一起兼顾到，才能真正快速铺开。
微信小程序正式公布后，我才发现这事我们居然干了两年了。又爱又恨，爱的是腾讯背书，让我们这个做法被认同了，恨的是这么晚才说，之前很多人看不懂，损失了好多笔融资机会。
05
小程序出来当天，我们就着手开始开发了，做了这么久相似度这么高的事情，肯定不能落下这个新风口。
但小程序的兴起，也伴随着巨大风险。各位同行一定要注意：
1:巨头之间会不会做“艰难的选择”。既然张小龙说了，希望二维码作为入口，其他巨头肯定也抢，最明显的对头就是支付宝。万一大家打红眼了，做了屏蔽限制，就像微信不能跳淘宝、百度不能搜微博那样，一个二维码只能做一个入口，那么对于用户来说是很难受的事情，我们这些依赖平台的第三方也会被牵连，市场的普及速度也会变慢。希望巨头们不要做得太low。
2:二维码的安全问题。不法分子拿着带病毒的二维码信息到处推，用户们习惯了二维码启动服务后无意中就容易中招。偷钱、盗密码等，都很可能发生。我们第三方很难做这一块的预防，需要平台自己能做安全验证。
3:平台的开放度够不够。做了小程序后，我们相当于把公司几十号人的未来都寄托在平台上了，我们积累的是用户数据，而不是用户，我们做的是服务，做不好广告。那么平台在接口管理上有没有搞特权、政策不清晰(定义诱导分享的边界)、接口临时升级搞坏了我们的服务、服务器故障导致我们挨骂等，都会分分钟把我们搞死。
06
我们暂时能分享的就这些，里面的经验适合ktv点服务、酒吧点酒、商品售后服务和分享购买等实体类场景，不适合修图、日历、电商类的线上场景。
线下实体类场景通用的小程序市场逻辑是：
1:别把小程序当h5营销用，那太浪费。线下有足够需要服务的场景，都适合小程序，做服务就自然有现金流水。
2:只要是现有方案成本太高、操作不便、实现服务时间需要等候的，都可以用小程序提高效率。
3:小前端大后台。别看着二维码入口轻巧，c端的整个交互也不会复杂，但是和线下业务的深度结合才是重点。虽然在c端我们没有了app，但是b端我们还是做了个叫做老板助手的app，以满足商家们的深度服务需求。
4:盈利模式不能再设计依赖用户积累的老套路了。流量红利已经吃完，线下流量更是不可能产生日增百万的覆盖能力，要赚钱是得依靠深入产业链做面向商家的服务。
07
这条正确的新路子，我们终于不是孤孤单单的了。
对于巨头们要说的是，别薅了羊毛就走。前几天支付宝的人过来聊天，说在北京看了三四家做类似二维码业务的，由于没有盈利模式，光顾着给平台打工，结果就挂了。除了佣金、补贴等，希望平台给出更有效的商业模式指导，来激活整个线下市场。
对于同行们要说的是，资本寒冬，盈利不易，大家一起寻找适合小程序模式下的新商业模式，才能把市场做大，共分蛋糕。
篇4：it项目管理心得
为期两天的工程项目管理培训，使我对工程项目管理的内容和概念有一个初步的认识。在一期我虽然参与了主体管网的安装和热能利用项目的建设，但我所做的工作主要是现场施工管理，只是工程项目管理内容的一个小小部分，没有具体的实践经验。这次培训对于一个参与即将开工的二期项目人员来说非常及时、重要的。确切的说，两天的培训时间是不够的，尤其是对没有做过工程项目的人，对老师所讲的内容很难理解。
这次培训的内容大致有以下几个部分：
1、职能管理与项目管理的区别。所谓职能管理是指针对存在有组织、有固定工作内容和部门进行标准化可重复使用的过程控制程序；项目管理是指对没有做过或没有经历的事情在规定的时间和预算约束下，一次性按要求完成的任务。从定义上职能管理和项目管理就是有本质的区别。职能管理和项目管理是两个不同的概念，在二期的建设中需灵活运用。
2、新建与技改项目经济分析、项目综合管理。这一节的内容我听后似懂非懂，很模糊，我理解为是对项目建设的前期准备工作的方式和方法。主要是项目的可行性报告的审批、研究具体方案、投资估算、市场预测和项目建设组织机构等内容。这跟我们建设者关系不大，我想这些事情是由老板和董事会研究决定的。只需要了解就可以了。
3、项目范围管理和项目管理时间。这一节的内溶对我们很有用，教我们怎样对项目工作分解，掌握正确的工作方法和过程控制。项目工作内容的分解（WBS）是很关键的，WBS是日程计划、资金计划、资源计划和其他工作计划的基础，要明确范围的细节内容。项目管理时间的控制主要是教我们了解时间与作业的关系、掌握日程计划编写、进度跟踪的具体方法。对大项目的工作分解必须由有经验的和专门的人员制定。就好比装修房子一样，要周密详细，合理分工，统筹安排。在课堂上我们对工作分解进行了简单演练。
4、项目费用、质量、风险管理。费用的估算有三种方法，即概念估算法、参数估算法、详细估算法。质量管理分为广义的和狭义的理解，包括产品质量、工作质量、工作质量、过程质量、人员质量、体系质量。风险管理包括风险发生的概率与影响程度、风险对应的策略。我们在项目建设中，肯定包含各种风险，这些风险都具有不确定性因素，我们在具体工作中怎样克服这些风险很重要。风险的策略是避免、减缓、转移、接受。
5、项目团队与人员管理。在制造业的职能运作中，人员的岗位职责、部门的工作程序、岗位的工作要求、业务的工作方法是相应固定的。而项目是目标和任务、人员和物资在时间和空间的临时组合，是一次性过程，项目人员的工作职责、工作程序和工作关系相对模糊松弛，由此带来的问题是项目对项目负责人的要求和评价问题。项目建设的成功与失败重要因素取决于人或者是一个由人组成的团队。团队建设的要点：
一、要有共同的目标，为同一个目标而奋斗。
二、公平的利益关系和统一的思想意识。
三、言行一致，宽容和谐，在同心同德的基础上和共同利益的环境下相互包容。通过对老师的讲解，我对团队建设和人员管理的观念有了深刻的认识，正如中期会议老板所讲的话：先做人后做事。
两天的培训时间很短，学的内容和多。好多东西要在实际中去运用。随着时间的推近，一个投资36多亿的项目工程即将开工，对于我来说，要学的，要做的实在是太多太多。当然，学有所用，作为二期项目的建设者，我有信心、有责任、有义务奉献我的一份力量，把南玻二期多晶硅项目建设美好。
篇5：it项目管理心得
项目开发方面
项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于eas项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。
需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点（用例）。eas项目在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时，有了充分的保证。
项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。（软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师）从eas项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。
项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。
注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。
注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了eas项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求追踪，任何原始需求来有头就有尾。原始需求-用户需求-产品需求-软件需求-设计-测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用)
控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时，这一点项目经理与项目管理小组要担负一定的责任。（范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否则容易引起计划的频繁调整而发生混乱)
设计
重视架构设计。eas项目的成功，一定程度是源于我们有个优秀的框架开发小组，我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化，但核心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地提高开发效率，规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完整性和设计统一)
★ 项目经理心得体会
★ 软件测试心得体会
★ 拓展培训心得体会
★ 拓展心得体会
【项目心得（共5篇）】相关文章：
团队的力量拓展心得体会2022-05-13
建筑工程的心得体会2022-07-27
大学生销售培训心得总结优秀2024-01-15
军训拓展训练心得体会2024-05-07
拓展培训心得体会-培训心得2023-11-04
团队拓展训练心得2023-07-08
公司素质拓展训练心得体会－感恩、奋进2022-12-09
我的拓展训练户外拓展训练心得2023-02-03
创新心得体会总结2023-07-07
项目管理培训心得体会2022-05-06