监理工程师：项目范围和进度如何制定？

1.项目目标和范围

当开始一个新的项目或版本时，第一步是与用户确认需求，并计划项目的范围。它是项目范围、进度、质量和资源这四个要素的平衡。当用户对项目进度有很高的要求和优先级时，我们往往要缩小项目范围，对用户的需求进行优先级排序，排除优先级低的。另外，我们进行项目范围规划的一个重要依据是我们的历史经验数据，对项目特点的清晰了解，在项目范围规划的初期就需要有一个宏观的预估，否则你很难判断清楚，也很难给用户，你能否用现有的资源在3个月内完成20个或更多的用户功能。

正规的流程似乎是先确认项目范围，再根据WBS->进度计划确认实际项目周期，但实际情况往往很难。用户往往更关注进度而不是范围，一个项目半年或者一年看不到具体的产品，用户肯定是不能接受的。所以我们的软件项目一般都是增量迭代开发的。

另外，我们需要强调项目目标的确定，不能简单理解为在某个时间点完成所有功能。项目的另一个重要目标是项目的质量目标。你完成的项目质量标准需要达到那个水平，产品BUG泄漏率要控制的范围。项目的质量目标不会影响我们的范围，但会影响我们后续评审、测试等时间的安排，直接影响项目的进度。

PMBOK已经明确提到项目范围定义的另一个重要目的是项目的性能度量和验收标准。当您交付项目时，用户将根据用户需求规格说明书的内容接受项目。我们项目范围的所有定义都必须清晰、量化、可验证、可测试，避免后期不必要的争议。

此外，项目的假设和约束需要在概述阶段进行分析。假设和约束分为技术方面和非技术方面。我们这里分析的所有假设都可能成为项目的风险。

2.项目进度的确定

项目的目标和范围确定后，就要开始确定项目的过程。项目全过程采用什么生命周期模型？项目是否需要削减组织层面定义的标准流程等。项目定义是WBS分解前必须确定的一个环节。采用瀑布模型和增量迭代模型时，WBS分解和进度安排显然是完全不同的。

过程确认清楚后，项目的WBS分解就开始了。WBS分解一般由项目组的核心成员参加，但项目经理应起主导和协调作用。通常，WBS分解方法是基于过程和基于成功的，但是这两种方法可以混合使用。比如在顶层，先分解子系统和工作包，在底层，分解需求、设计、编码、测试各个流程。WBS的最低工作单元需要是可以独立验证的产品，需要下达计划和任务，工作单元需要有明确的负责人。因此，如果没有仔细的估算，我们有时很难使工作单元满足这些要求，因此在估算过程中不可避免地要对WBS进行优化和调整。

WBS分解完成后，就可以开始估算工作单元了。一般有专家法、三点法、功能点法。由于我们的项目采用专家方式，所以更需要项目的核心成员和有经验的成员参与。一般会估算出工作单元的单位和复杂程度，最后估算出项目的总规模，再除以项目的生产率后得到项目的工作量数据。一般会进行多轮专家估算，直到所有指标收敛(收敛标准是事先明确确定组织或项目，如偏差人员的责任矩阵。对于关键路径，ES、EF、LE和LF可以直接用运筹学中的关键路径分析法确定。

项目进度基本安排好之后，就可以计划和确定项目的里程碑和基线了。项目的里程碑和基线是项目重要的跟踪控制检查点，里程碑项目会做一个专门的里程碑报告，分析项目当前状态、进度、工作量、规模、缺陷等指标的偏差。

整个项目进度基本出来后，需要和项目组的所有项目成员确认，才能得到项目的内幕，项目成员要对整个进度安排基本达成一致。该项目仍有计划要得到支持。项目进度出来后，可以通知QA和配置管理员分别制定质量保证计划和配置管理计划。项目经理协助测试负责人制定项目的系统测试计划。