组织级战略项目管理
一个程序员在海滩上发现了一盏神灯。他在灯上擦了几下，一个妖怪就从灯里跳出来说：“我是世界上法术最强的妖怪。我可以实现你的任何梦想，但现在，我只能 满足你一个愿望。”程序员摊开了一幅中东地图说：“我想让中东得到永久的和平。”妖怪答道：“哦，我没办法。自打创世纪以来，那里的战火就没有停息过。这 世上几乎没有我办不到的事，但这件事除外。”程序员于是说：“好吧，我是一个程序员，为许多用户编写过程序。你能让他们把需求表诉的更清楚些，并且让我们 的软件项目有那么一两次按进度按成本完成吗？”妖怪说：“唔，我们还是来看中东地图吧。”这段让人一笑了之的幽默从很大程度上反映了国内软件企业中普遍存 在的现象，由于客户需求和内部管理等原因软件项目总是难以在预定的范围、成本和时间内完成。那么究竟是什么因素导致了该现象的延续呢？
1软件企业项目管理中存在的主要问题
1.1 低劣的需求分析
需求分析阶段没能很好地掌握客户需求，形成高质量的软件需求说明书，并交付客户方关键项目干系人正式书面确认，就跨越式地进入系统设计阶段，这必然导致项 目执行过程中项目范围的频繁变更。软件产品范围是指软件产品所包含的特征或功能，而软件需求说明书正是对软件产品范围正式书面的界定，是软件项目管理过程 必须的基础性文档。从项目管理的角度讲，产品范围和项目范围的变更都是允许的，一般来说也是不可避免的。但对于软件项目，产品范围与项目范围的制约关系变 的非常严密，产品范围的频繁变更触发的必然是项目控制过程的混乱，对于规模较大的项目最终的必然后果是项目的失控乃至失败。
实践表明，高质量的需求分析是软件项目成功的关键因素。需求分析是优化企业软件开发过程的起点，这在CMM2级把需求管理作为首要关键过程领域(KPA) 中得到了最好的反映。软件项目的范围控制应该是在需求分析阶段就开始的，就是说软件需求说明书应该是最大可能最大程度地理解了客户实际业务需求的文档，采 用文字或图形化的方式清晰正确地描述了至少90%的实际需求，并在完成系统设计完成或编码阶段开始前明确剩余需求。特别对于复杂的业务流程型项目，涉及多 客户方干系人需求的项目和涉及引发客户方机构变革的项目，一般应委托客户方关键性干系人内部协调达成一致意见后确定需求，切不可凭经验自作主张想当然。在 编码阶段开始后，应做好产品范围的变更控制，尽可能地对客户施加影响，避免需求变更的发生，实在无法避免的变更一定要采用正式书面的形式。
1.2 缺乏项目管理理论知识&n此文章共有6页 1 2 3 4 5 6 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 