it项目管理心得体会心得体会.doc

it项目管理心得(心得)

项目开发方面

项目应以需求为关键。一种项目与否可以成功，对需求的精确把握在成功原因中要占上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是最多。因此，我们认为在开发类似的w