《it项目管理心得》由会员分享，可在线阅读，更多相关《it项目管理心得（29页珍藏版）》请在金锄头文库上搜索。
1、it工程管理心得工程开发方面工程应以需求为核心。一个工程是否可以成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，假设需求出现偏向，仍然是南辕北辙。由于eas工程的特殊性，工程开发过程中可以与客户建立有效快速的沟通渠道，是工程成功的关键。需求必须获得客户确实认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括工程的目的、范围以及工程需求功能点用例。eas工程在前期对需求不够重视，导致在需求理解上出现了一些偏向，从而影响了工程的进度。幸而得到了及时的纠正，在工程管理部的协助下，所有需求都得了客户
2、或客户代表的签字确认。从而使得工程在客户验收时，有了充分的保证。工程应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员装备上的一大弊端。软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师从eas工程的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经历的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏向或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给工程带来隐患。工程应指定各个模块的需求接口人。只有这样，才能有效地保证工程组与客户的及
3、时沟通，快速响应客户的恳求与反响。eas工程在开发早期及时地确立了需求接口人，在一定程度上躲避了需求变更给工程带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而工程经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何工程的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏向。注意维护需求矩阵。工程经理对这一内容缺乏
4、足够的重视与理解，工程开发过程体系中也缺乏好的需求矩阵文档模板。但是在工程中后期，工程及时撰写了eas工程需求功能列表，并结合交付版本与客户进展了沟通和协商，从而躲避了需求偏向的风险。(需求追踪，任何原始需求来有头就有尾。原始需求-用户需求-产品需求-软件需求-设计-测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用)控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas工程组对于需求变更的响应还不够及时，这一点工程经理与工程管理小组要担负一定的责任。范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必需要受到控
5、制，否那么容易引起方案的频繁调整而发生混乱)设计重视架构设计。eas工程的成功，一定程度是源于我们有个优秀的框架开发小组，我们在工程立项之初就根本确定了整个系统的架构。其中虽然发生了一些变化，但核心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地进步开发效率，躲避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完好性和设计统一)擅长对设计作出取舍。工程开发的三要素是本钱、质量与进度。在保证质量的前提下，为了工程进度不出现大的偏向，eas工程组并没有过分强调技术，特别是在考虑进度的情况下
6、，牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患，但却可以有效地保证工程的进度。从eas最初的架构设计来看，我们引入了castle与aop，试图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时，希望采用wcf，利用soa思想建立松散耦合的面向效劳应用程序。但随着客户需求的变化，我们果断地放弃了采用wcf的设想，同时又抑制了技术困难，坚持了对castle与aop的使用，并为此成立了框架开发小组。事实证明，在技术的抉择上我们作出了正确的决定。重视ui原型设计。系统的原型设计与需求分析相辅相成。假设有好的原型版本交付给客户，那么客户更可以理解系统的实现，促进沟通的有
7、效性与准确性。在eas工程中，我们从一开场就确立了原型设计小组，并在分析需求阶段，就开场了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是，我们在这一点上，由于缺乏专门的ui设计人员，因此，这一工作还存在很大的缺陷，甚至于ui的设计为迭代版本的交付带来了很大的障碍。在工程后期，关于ui的bug是最多。因此，我们认为在开发类似的web应用程序时，应尽早确立ui设计标准，以约束所有的ui设计。同时，必须培养专门的ui设计师，在开场原型设计时，就尽快完成ui交互的设计。并且，必须成立专门的ui设计小组，在需求阶段与需求分析师合作，在编码阶段与开发人员合作。(原型设计
8、是加强前期用户需求挖掘和减少后期需求变更的重要手段，不一定需要专门的ui设计人员，原型设计可以由需求分析师来完成)测试测试成员应理解需求。假设不理解需求，测试人员无法编写正确的测试用例，同时在测试过程中，也可能因为错误地理解需求，从而导致报告错误的bug，影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别，测试人员不用想需求分析人员一样分析和开发业务，但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉)测试之初必须确定测试原那么，对bug的严重程度进
9、展分级。同时，必须确定修复bug的优先级别。进度管理保证工程进度不出现大的偏向的前提是制定一个好的工程方案。必须根据工程规模，成员情况，技术难度等多方面考虑整个工程方案。假设工程的deadline已经确定，那么必须采用一些方法来保障工程方案的完成。首先是选择符合工程的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最正确的方法，应该是rup或者敏捷开发，然后结合原型法制订工程方案。这样可以躲避因为需求变更产生的风险。其次，要每日跟踪工程的进展情况。可以通过晨会、周会以及工程日报、工程周报理解工程进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与方案
10、出现偏向。要制定工程进度偏向的应对方法。一旦工程进度出现了偏向，必须采取相应错误解决问题。或者通过加班、增加人手、申请工程进度等方法及时作出响应。及时向工程成员汇报工程进度情况。只有让各个工程成员理解到工程现状，才可以给每个成员增加压力，不至于松懈。同时，也可以使得每个成员能有一个目的，而不至于茫然失措。制定工程方案时，必须考虑阶段评审与同行评审的时间。这一点在eas工程中做得不够好。其中原因也是由于工程进度本身较紧的缘故。注意维护工程进度跟踪表与工程进度偏向跟踪表。让工程管理部以及qa及时掌握工程进度，有利于对工程进度的管理。变更管理变更包括需求变更、人员变更。假设不控制好，两者对工程的进展
11、都会带来灾难性的后果。需求变更在前面已经表达，而eas工程中发现人员变更的情况也非常严重，因此这里重点介绍关于人员变更的管理。假设发生人员进入的情况，那么对工程带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲，假设需要新成员参加，发生变更的最正确时机是工程前期。假设在工程中后期参加新成员，无疑那么意味着工程出现了灾难性的后果。而新增加的成员，由于不熟悉工程，所能带来好的影响也是有限的。假设不处理好新成员与老成员之间的合作关系，反而会带来负面影响。人员的退出很多时候是不可控的，同时对工程带来的影响也是不可估计的。为了将这些影响降到最低，就必须在工程开场之初就要确立编
12、码标准。同时，还应该重视对文档的维护与更新。而在人员退出时，必须做好交接工作。同时，还应对这种变更进展合理的评估，并及时报告工程管理部，并与客户及时沟通。假设对工程进度有严重影响，应争取最大的努力获得客户的理解，提出工程延期的申请。风险管理要在工程开场之初就考虑到工程过程中可能出现的所有风险，是不现实的。但是，我们必须考虑对风险的管理，尤其是在制订工程方案以及创立团队的时候，考虑这一因素。风险有很多，包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完好的风险管理方案，而一旦发生了风险，那么必须及时响应，组织相关人员解决风险。不能忽略任何一个小的风险，否那么一个小的风险到最后会
13、造成大的灾难。风险的把握必需要有工程经理与系统架构师把关。成员管理不团结的工程组是无法保证工程的成功地。工程经理与工程组长在管理团队成员时，必须时刻注意成员状况，即使处理工作出现的矛盾与摩擦，随时保证团队合作精神得到最大程度的执行。持续地保证工程成员的士气非常重要。工程每获得一个阶段性的进展，必须告知全体成员，如此才能收获成功的信心。工程开发过程需要注意劳逸结合。一味地强迫性加班，只能降低工程成员的工作效率。工程过程中，如能适当地开展一些活动，无疑可以让团队成员感受到工程组的集体气氛。在阶段实现的重要时刻，工程经理必须注意通过文字、语言等鼓励工程组成员。而工程经理的自信也是保证成员士气的一个关
14、键。必须注意理解团队成员的心理状态与工作状态。工程成员的战斗力除了是个人的才能发挥之外，一个好的指导也是至关重要的。因此，必须选择适宜的工程组长，通过他们掌握整个工程团队成员的工作进展。同时，还要理解每个成员的才能，以安排适宜的角色与岗位。重视开发组与测试组以及工程管理小组的合作。工程组是一个整体，每个成员的角色不同，但大家都是团队的重要一员。作者:张逸具有多年的软件开发与设计经历，他是两届微软最有价值专家mvp，著作/译作包括?软件设计精要与形式?、?wcf效劳编程?。张逸熟悉c#，asp，wcf等技术，同时深谙面向对象领域的相关技术。目前，他主要从事soa企业信息解决方案的设计与研究，以及
15、敏捷方法的推广与理论。张逸是捷道敏捷堂的创始人。 .cOm更多心得体会扩展阅读工程管理心得体会时间过得真快，一眨眼的功夫，这门课已经完毕了，总的来说这段时间过的繁忙，充实而快乐。这门课主要教我们的是管理，张总在课上时不时地改正我们的思维方式，说话的技巧，在工程中怎么与甲方沟通，我从总获益匪浅。而且这门课要求我们把工程当成是真实的工程来做，为了让我们有真实的感受，张总还让一些在职的人员作为甲方，来跟我们模拟工程的过程。从整个工程的提出到验收中我学到了很多东西，不管在技术上还是团队合作上我都有颇大的收获。如今回想当初刚听到要45天完成这个工程时的心情，真是有点感慨。记得刚上课的时候蒋院长就进来说，
16、张总的课是严格的训练，叫我们一定要挺过去，当时觉得有那么夸大吗，不就是一门课，这么多年多难的课都过来了。但是当崔总提出工程时，确实有点让人惊讶，要在45天完成他指定的工程，而且是用c#，当时我们组没人会c#，真的觉得这个有点太紧了，而且因为中间还有别的课要上，又不能把所有的时间精力都放在这个上面。即使我们能在这么短的是时间看c#方面书，把工程赶出来，那质量肯定也不会好到哪去。尽管这样想，我们还是准备做这个工程。前一阵子终于工程通过了验收，虽然搜索的效果不是特别棒，但是我们和甲方的人员还是比较满意的验收时的结果的，这让我们感觉三四十天的努力没有白费，心情当然很爽快啊。纵观整个工程从给公司起名字，到获取需求，到最后验收的过程，还是有点心得体会的：第一，要认清形势。
