软件项目管理的矛盾平衡[2]

发表于:2009-12-02来源:作者:点击数: 标签:项目管理矛盾软件
软件项目管理的矛盾平衡[2] 软件项目管理 关键字:项目管理 矛盾平衡 工作分解咋控制? “计划赶不上变化!”一个项目经理感叹道。 的确,项目中有相当多的不确定因素,项目经理辛辛苦苦做的WBS(工作分解结构),可能因为客户的改变,甚至领导的一句话,就分崩

       软件项目管理的矛盾平衡[2]  软件项目管理

  关键字:项目管理 矛盾平衡

  工作分解咋控制?

  “计划赶不上变化!”一个项目经理感叹道。

  的确,项目中有相当多的不确定因素,项目经理辛辛苦苦做的WBS(工作分解结构),可能因为客户的改变,甚至领导的一句话,就分崩离析了。一些公司高层没有经过仔细考虑,也没有充分征求各个方面的意见,在制定总体计划时比较随意,修改起来更是“信手拈来”。项目经理也常常借口工作忙等理由,拖延制定详细的WBS,甚至有项目经理认为,不应该制定详细的WBS. 而没有详细WBS的危害也是明显的:造成计划与控制管理脱节,无法进行有效的进度控制管理,最终导致项目延期或成本上升。可以说,没有WBS或者是随意的不负责任的WBS的项目是一种无法控制的项目。面对各种潜在的变化,项目经理应该怎样制定WBS呢?

  首先项目经理应该对WBS有正确的认识,制定WBS就是一个对项目逐渐了解掌握的过程,通过这个过程,项目经理可以知道哪些要素是明确的,哪些是要逐渐明确的,通过渐近明细不断完善。渐近明细也是项目的一个特点,因此WBS的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。

  再者,制定WBS需要有一个现实的方法。一个大型的软件开发项目,通常是采用二次WBS方法。即根据总体WBS,在需求调研阶段结束、概要设计完成后,再专门针对详细设计或编码阶段制定二次WBS .

  一个方面,需求的颗粒度在一开始往往是比较粗的,因此根据功能点对于整体项目规模的估计误差范围也是比较大的,只能据此制定总体的WBS.另一个方面,需求和编码工作分解不是一一对应的,一个需求的功能点可能对应多个代码模块,而多个需求的功能点也可能只对应一个或少数代码模块。只有在概要设计完成以后才能准确地得到详细设计或编码阶段的 二次WBS.

  例如,汉中市龙岗中学数字化校园建设项目中。合同规定8月28日之前系统必须投入试运行。由于但是项目准备时间十分的短,公司要求在2天时间内预算材料和联系组织人员开工,项目经理组织大家制定了简单的项目的WBS,并制订了本项目的进度计划,简单描述如下

  1. 应用子系统:7月1日~7月5日需求分析,7月6日~7月26日现场布线工作完成,7月20日~7月26日公司技术人员在公司对系统软件进行调试,7月27日~8月18日所有设备安装并进行系统现场测试;

  2.系统整体调试:8月18日~8月25日完成完成网络和系统功能的集成工作;

  3.网络子系统:8月25日~8月26日设备所有功能进行联调;

  4.系统整体调试、验收:8月26日~8月27日试运行,8月27日系统验收

  在工程进行到8月15日的时候由于校方施工环境和原合同中的描述不一致,导致工程需要延时。但由于工程在开始阶段时间过紧,编制的这个WBS比较粗糙,不适合作为编织项目计划的基石。只有一个项目的大概框架和子系统各部分的期望完成时间。从该WBS上面可以看出最底层任务的工期至少也在半个月左右。如果任何一个任务出现了问题,就必然会出现这样的问题,即延期和延期发生了较长时间才知道。

原文转自:http://www.ltesting.net