项目（Explore）总结之项目时间管理

§1.4  项目时间管理

项目时间管理包括按时完成必须进行的各项过程。

§1.4.1                  活动定义

活动定义识别处于WBS最下层（称为工作组合）的可交付成果。项目工作组合有计划地分解为粒度更小的计划活动，为估算、安排进度、执行，以及监控项目工作奠定基础。该过程的产出是活动清单、活动属性、里程碑清单和可能的变更。

项目启动时，由于没有详细的需求，无法确定细粒度具体的计划活动，只制定了大体的里程碑清单，同时以粗粒度的模块开发清单作为活动清单。里程碑的制定主要是以系统架构稳定、X1-X6子系统上线等事件作为主要标志，在实际操作中，由于粒度过粗，时间跨度过长，在项目过程中出现技术风险、需求风险等因素时由于无法在里程碑时点及早发现和解决，导致子系统的进度亦无从监控；活动清单的制定主要是依据之前的开发经验，如子系统X1，有M1-M66共66个模块，每个模块的开发则视为一个计划活动，实际上该计划活动已经包括了需求分析、系统设计、编码等一系列的活动。

活动属性中的资源要求、强制性日期要求、制约因素和假设等在整个开发过程中均没有深入分析。活动之间的逻辑关系则根据之前的经验在子系统级作了较为粗线条的确认。

计划活动规范方面，在每个子系统的开发过程中，以周为周期对下周细粒度的活动进行计划，采用滚动式的规划方法。

在此项目中，活动定义和制定进度计划两个过程没有明显的划分，因而里程碑清单和活动清单集成在MS Project制定的进度计划中。

§1.4.2                  活动排序

活动排序是指识别与记载计划活动之间的逻辑关系。活动排序过程主要的新增产出是项目进度网络图。

在活动定义章节已提过，活动定义、活动排序和制定进度计划上没有明显的划分，项目整体活动排序依据的是之前的开发经验以及项目内部和客户的评审意见。

对于每一个子系统，开发时制定子系统开发计划，同样的，这时候同时完成活动定义和活动排序，使用MS Project制定。

§1.4.3                  活动资源估算

活动资源估算确定在实施项目活动时需要何种资源（人员、设备、物资等）资源的数量以及何时使用资源。

Explorer没有对每一活动清单进行资源估算，可以说，没有对活动资源的规划，基本上是在每一子系统进入开发时才确定参与具体的参与人员，开发过程中如有变化则根据实际情况追加或释放资源，缺乏计划，典型的做到那算那。

§1.4.4                  活动持续时间估算

活动持续时间估算依据计划活动的工作范围、资源类型、活动资源要求以及资源日历等信息对活动的持续时间进行估算的过程。

在项目中，分两个层次对活动持续时间进行估算：首先，子系统的持续时间在不考虑资源的情况根据客户的要求等制约因素作一个大概的估算；其次，对于子系统的每一个系统模块，在列入开发计划时才予以估算。其中，模块开发的估算拆分为需求调研、需求分析、系统设计、编码、测试、编码返工等几个阶段分别估算，目的在于提高估算的准确度以及利于后续的任务安排。估算所采用的方式通常是专家判断和类别估算，即由系统分析员确定大体的估算时间。执行过程中，由于系统设计文档没有经过同行评审，往往会出现设计不合理而导致长时间耗费资源在某个计划活动上的情况，PM对此种情况上的沟通和控制力度不够。

§1.4.5                  制定进度表

制定进度表过程确定项目活动的开始和结束时间，是一个反复多次的过程。

如前所述，项目开始时，根据招标文件中的范围描述，制定了一份项目的总体进度表，在制定进度表的时候大体进行了活动定义、活动持续时间估算等工作。在子系统计划阶段时，每一子系统均会制定相应的进度表。

制定项目进度表使用的工具是MS Project，没有作关键路径分析，资源分配上面，根据系统的开发情况，在做详细周计划时才确定，基本上每一个子系统的开发团队是相对固定的。项目进度表制定报批后，就给束之高阁了，出现变更或其他政策调整导致计划变动时均没有反映到项目进度表上，整体变更控制和进度控制没有做好，变更没有反映到计划上面。

§1.4.6                  进度控制

进度控制过程判断项目进度的当前状态、对造成进度变化的因素施加影响、查明进度是否已经改变以及在实际变化出现时对其管理。

项目没有使用挣值法对项目进度绩效数据进行测量，项目进度的当前状态判断基本依赖于项目组系统分析员和TeamLeader的经验，所以经常在例会上客户问到目前进度多少，什么时候能不能完成之类的问题时，只能是拍脑袋去回答，经验很重要但毕竟是定性分析，偏差很大。对于造成进度变化的因素，引致变化的主要因素包括政策变动引起的需求变更、人员离职等，对于这类因素，特别是因为政策引起的变更，是必须满足客户要求的，这种情况下，应从技术上着手，以“可适应需求变更”作为软件开发的一个需求，不过，在项目中出于赶工的原因，在代码一级基本没有做好控制，所谓重用、适应变化也就无从谈起了。

       至于进度基准，自从审批过后，就没有更新过，在最后项目验收比原基准整整延迟了七个月以上，还是那句话：整体变更没有控制好，相关的信息没有得到及时的更新。当然，话说回来，按照PMBOK的理论，如果事无巨细的去执行，一旦出现变更更新相关的文档也是一件费时费力的事情。

-------------------------- 本文可任意转载，但请注明作者和出处 ----------------------------

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/6906/viewspace-630828/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/6906/viewspace-630828/