it项目管理心得.docx

本文格式为Word版，下载可任意编辑
— 2 —
it项目管理心得
工程开发方面
工程应以需求为核心。一个工程是否能够告成，对需求的切实把握在告成因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的相成。假设有好的原型版本交付给客户，那么客户更能够理解系统的实现，促进沟通的有效性与切实性。在eas工程中，我们从一开头就确立了原型设计小组，并在分析需求阶段，就开头了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是，我们在这一点上，由于缺乏特意的ui设计人员，因此，这一工作还存在很大的缺陷，甚至于ui的设计为迭代版本的交付带来了很大的障碍。在工程后期，关于ui的bug是最多。因此，我们认为在开发类似的web应用程序时，应尽早确立ui设计模范，以约束全体的ui设计。同时，务必培养特意的ui设计师，在开头原型设计时，就尽快完成ui交互的设计。并且，务必成立特意的ui 设计小组，在需求阶段与需求分析师合作，在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和裁减后期需求变更的重要手段，不确定需要特意的ui设计人员，原型设计可以由需求分析师来完成)
本文格式为Word版，下载可任意编辑
— 5 —
测试
测试成员应了解需求。假设不了解需求，测试人员无法编写正确的测试用例，同时在测试过程中，也可能由于错误地理解需求，从而导致报告错误的bug，影响开发人员效率。加强开发人员与测试人员的合作。开发人员务必实时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复处境。(测试人员理应要意识到自己和需求分析人员的识别，测试人员不用想需求分析人员一样分析和开发业务，但是他们务必和需求分析人员一样对已经分析出来的需求和业务高度熟谙)
测试之初务必确定测试原那么，对bug的严重程度举行分级。同时，务必确定修复bug的优先级别。
进度管理
保证工程进度不展现大的偏差的前提是制定一个好的工程筹划。务必根据工程规模，成员处境，技术难度等多方面考虑整个工程筹划。假设工程的deadline已经确定，那么务必采用一些方法来保障工程筹划的完成。首先是选择符合工程的软件开发生命周期。通常处境下，并不建议采用瀑布开发方式。最正确的手段，理应是 rup或者灵巧开发，然后结合原型法制订工程筹划。这样可以回避由于需求变更产生的风险。
本文格式为Word版，下载可任意编辑
— 7 —
其次，要每日跟踪工程的进展处境。可以通过晨会、周会以及工程日报、工程周报了解工程进展处境。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与筹划展现偏差。
要制定工程进度偏差的应对方法。一旦工程进度展现了偏差，务必采取相应错曲解决问题。或者通过加班、增加人手、申请工程进度等方法实时作出响应。

实时向工程成员汇报工程进度处境。只有让各个工程成员了解到工程现状，才能够给每个成员增加压力，不至于松懈。同时，也能够使得每个成员能有一个目标，而不至于茫然失措。
制定工程筹划时，务必考虑阶段评审与同行评审的时间。这一点在eas工程中做得不够好。其中理由也是由于工程进度本身较紧的起因。留神维护工程进度跟踪表与工程进度偏差跟踪表。让工程管理部以及qa实时掌管工程进度，有利于对工程进度的管理。
变更管理
变更包括需求变更、人员变更。假设不操纵好，两者对工程的进展都会带来灾难性的后果。需求变更在前面已经表达，而eas工程中察觉人员变更的处境也分外严重，因此这里重点介绍关于人员变更的管理。
本文格式为Word版，下载可任意编辑
— 8 —
假设发生人员进入的处境，那么对工程带来的通常都会是好的影响。但我们也务必留神如何让新成员更快地融入团队。整体上讲，假设需要新成员参与，发生变更的最正确时机是工程前期。假设在工程中后期参与新成员，无疑那么意味着工程展现了灾难性的后果。而新增加的成员，由于不熟谙工程，所能带来好的影响也是有限的。假设不处理好新成员与老成员之间的合作关系，反而会带来负面影响。
人员的退出好多时候是不成控的，同时对工程带来的影响也是不成估计的。为了将这些影响降到最低，就务必在工程开头之初就要确立编码模范。同时，还理应重视对文档的维护与更新。而在人员退出时，务必做好交接工作。同时，还应对这种变更举行合理的评估，并实时报告工程管理部，并与客户实时沟通。假设对工程进度有严重影响，应争取最大的努力取得客户的理解，提出工程延期的申请。
风险管理