it项目管理心得.pdfVIP

it工程管理心得

工程开发方面

工程应以需求为核心。一个工程是否能够成功，对需求的准确把握在成功因素中

要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，

仍然是南辕北辙。由于eas工程的特殊性，工程开发过程中能够与客户建立有效快速的沟

通渠道，是工程成功的关键。

需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及

软件需求规格说明书都必须得到客户的签字确认。确认的内容包括工程的目标、范围以及

工程需求功能点（用例）。eas工程在前期对需求不够重视，导致在需求理解上出现了一

些偏差，从而影响了工程的进度。幸而得到了及时的纠正，在工程管理部的协助下，所有

需求都得了客户或客户代表的签字确认。从而使得工程在客户验收时，有了充分的保证。

工程应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配

备上的一大弊端。（软件开放工作细分的第一步就是要有专门的系统分析员或需求分析

师）从eas工程的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更

改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普

通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。

软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给工程

带来隐患。

工程应指定各个模块的需求接口人。只有这样，才能有效地保证工程组与客户的

及时沟通，快速响应客户的请求与反馈。eas工程在开发早期及时地确立了需求接口人，

在一定程度上规避了需求变更给工程带来的风险。但是，确立的需求接口人未经过系统培

训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。

注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人

不够专业，而工程经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的

工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也

非常重要，毕竟，任何工程的需求都不是固定不变的，需求随时会发生变更，而开发人员

实现的需求也可能会与客户的要求偏差。

注意维护需求矩阵。工程经理对这一内容缺乏足够的重视与理解，工程开发过程

体系中也缺乏好的需求矩阵文档模板。但是在工程中后期，工程及时撰写了eas工程需求

功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求

追踪，任何原始需求来有头就有尾。原始需求-用户需求-产品需求-软件需求-设计-

测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多

的是为了做变更影响分析使用)

控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas工程组

对于需求变更的响应还不够及时，这一点工程经理与工程管理小组要担负一定的责任。

（范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控

制，否则容易引起计划的频繁调整而发生混乱)

设计

重视架构设计。eas工程的成功，一定程度是源于我们有个优秀的框架开发小

组，我们在工程立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化，但核

心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地提

高开发效率，规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架

构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完整性和设计

统一)

善于对设计作出取舍。工程开发的三要素是成本、质量与进度。在保证质量的前

提下，为了工程进度不出现大的偏差，eas工程组并没有过分强调技术，特别是在考虑进

度的情况下，牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患，但却

能够有效地保证工程的进度。从eas最初的架构设计来看，我们引入了castle与aop，试

图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时，希望采用

wcf，利用soa思想建立松散耦合的面向服务应用程序。但随着客户需求的变化，我们果断

地放弃了采用wcf的构想，同时又克服了技术困难，坚持了对castle与aop的使用，并为

此成立了框架开发小组。事实证明，在技术的抉择上我们作出了正确的决定。