项目管理应以需求管理为核心.docxVIP

项目管理应以需求管理为核心 这段时间，一直在负责一个项目的管理与开发。在时间短、任务紧，而团队 人员又大多数是没有经验的菜鸟的恶劣情况下，我率领靠近40人的团队，终于 在客户规定的时间范围内按期交托产品。这其中，经历了需求更改、人员改动(因 为其余任务，先后有近10人走开团队)等诸多问题，项目仍旧取得成功了，不能 不说有几分侥幸，但别的也有一些经验与教训能够与大家分享。 项目开发方面 需求 项目应以需求为核心。一个项目是否能够成功，对需求的正确把握在成功因 素中要占上60%的比率。不论系统的架构设计、团队管理有多么的成功，如果需 求出现偏差，仍旧是背道而驰。由于EAS项目的特殊性，项目开发过程中能够与 客户成立有效迅速的交流渠道，是项目成功的重点。 需求必须获得客户确实认。经过需求调研与剖析后获得的用户需求说明书， 以及软件需求规格说明书都必须获得客户的署名确认。确认的内容包括项目的目 标、范围以及项目需求功能点(用例)。EAS项目在前期对需求不够重视，致使在 需求理解上出现了一些偏差，进而影响了项目的进度。幸亏获得了实时的纠正， 在项目管理部的辅助下，所有需求都得了客户或客户代表的署名确认。进而使得 项目在客户查收时，有了充分的保证。 项目应确立特意的需求剖析师。企业没有特意的需求剖析师，不能不说是人 员配备上的一大缺点。从EAS项目的开发过程中，我们就充分地认识到这一问题 的严重性。需求的不断更改，客户迟迟未署名确认，原因正是在于我们没有特意 的拥有丰富经验的需求剖析师。普通开发人员在调研需求以及撰写需求规格说明 书时，老是会出现偏差或理解错误的地方。软件需求剖析是一项重要且负责的技 术，没有经过特意训练的需求剖析师，往常会给项目带来隐患。 项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客 户的实时交流，迅速响应客户的恳求与反应。EAS项目在开发早期实时地确立了 需求接口人，在一定程度上躲避了需求更改给项目带来的风险。可是，确立的需 求接口人未经过系统培训，在需求调研以及与客户交流的过程中，工作表现只能 说是差强人意。 注意维护需求调研记录以及需求追踪表。这一工作做得不够好。由于需求调 研人不够专业，而项目经理以及需求剖析负责人对这一过程还短缺足够的重视， 同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作 用。别的，需求追踪也特别重要，毕竟，任何项目的需求都不是固定不变的，需 求随时会发生更改，而开发人员实现的需求也可能会与客户的要求偏差。 注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发 过程体系中也缺乏好的需求矩阵文档模板。可是在项目中后期，项目实时撰写了 EAS项目需求功能列表，并联合交托版本与客户进行了交流和磋商，进而躲避了 需求偏差的风险。 控制需求更改。重视CCB的作用，同时应成立需求更改的响应体制。EAS项 目组对于需求更改的响应还不够实时，这一点项目经理与项目管理小组要担负一 定的责任。 设计 重视架构设计。EAS项目的成功，一定程度是源于我们有个优异的框架开发 小组，我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些 变化，但核心架构仍旧没有发生大的变化。由于，我们成立了稳定、简单的系统 框架，能够极大地提高开发效率，躲避了对框架的重复编码。 善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量 的前提下，为了项目进度不出现大的偏差，EAS项目组并没有过分强调技术，特 别是在考虑进度的情况下，牺牲了系统的部分可扩展性。虽然这为系统的后期维 护带来一定隐患，但却能够有效地保证项目的进度。从EAS最初的架构设计来看， 我们引入了Castle与AOP，试图简化ORM以及横切关注点比如日志、异样、权 限、事务等功能的实现。同时，希望采用WCF，利用SOA思想成立松散耦合的面 向服务应用程序。但随着客户需求的变化，我们坚决地放弃了采用WCF的构思， 同时又战胜了技术困难，坚持了对Castle与AOP的使用，并为此成立了框架开 发小组。事实证明，在技术的决断上我们作出了正确的决定。 重视UI原型设计。系统的原型设计与需求剖析相辅相成。如果有好的原型 版本交托给客户，则客户更能够理解系统的实现，促使交流的有效性与正确性。 在EAS项目中，我们从一开始就确立了原型设计小组，并在剖析需求阶段，就开 始了原型设计。这一做法无疑在客户交流、需求确认、UI设计等方面都发挥了 很大的作用。可是，我们在这一点上，由于缺乏特意的UI设计人员，因此，这 一工作还存在很大的缺陷，甚至于UI的设计为迭代版本的交托带来了很大的障 碍。在项目后期，对于UI的bug是最多。因此，我们认为在开发近似的WEB应 用程序时，应尽早确立UI设计规范，以拘束所有的UI设