会员登录
会员注册当了一段时间IT项目经理，把一个软件开发项目的项目管理的实际过程写一下供大家讨论和参考。IT项目管理跟其它工程项目管理最大的一个不同就是人的管理，项目成员不是简单的机器，人员的知识技能，团队建设，项目沟通等内容往往是项目管理的一个很关键内容。这个方面可以参考《人有神话》，《软件工艺》，《最后期限》书籍，我的Blog上也有相关的读书笔记可以参考。
首先我们用思维导图把计划阶段的相关活动归纳一下再进行具体的分析：
1.项目目标和范围
开始一个新项目或版本时候，首先是和用户一起确认需求，进行项目的范围规划。项目是范围，进度，质量和资源四要素的平衡，用户对项目进度要求和优先级高的时候，我们往往要缩小项目范围，对用户需求进行优先级排序，排除优先级低的需求。另外我们做项目范围规划的一个重要依据就是我们的历史经验数据，对项目特征的清楚认识，项目范围规划初期需求你进行一个较宏观的估算，否则你很难判断清楚或给用户承诺在现有资源情况下，你3个月时间里面是否可以完成20个或更多用户功能。
正规过程好像是先确认项目范围，然后根据WBS->进度计划确认实际的项目周期，但实际情况往往很难如此，用户往往对进度的关注度大于对范围的关注度，一个项目半年或一年都看不到具体的产品出来用户肯定是无法接受的，所以我们的软件项目一般也是按版本增量迭代进行开发。
另外这里需要强调下项目目标的确定，项目的目标不能简单理解为在某个时间点完成所有功能。项目另外一个重要目标就是项目的质量目标，你完成的这个项目需要达到那个等级的质量标准，交出的产品BUG泄漏率要控制在什么范围内等内容。项目的质量目标不会影响到我们的范围，但会影响到我们后续评审，测试等时间的安排，直接影响到项目的进度。
PMBOK里已经明确提到项目范围定义的另一个重要目的就是项目的绩效测量和验收准则，你交付项目的时候用户会根据用户需求说明书内容对项目进行验收，所有我们项目的范围的定义必须是明确，量化，可验证和可测试的，这样才能够避免后期无谓的纠纷。
另外在概述阶段需要分析项目的假设和约束，假设和约束又分为技术方面和非技术方面，在这里我们分析的所有假设都可能成为项目的风险。
2.项目进度的确定
项目的目标和范围确定后，需要开始确定项目的过程，项目整个过程中采用何种生命周期模型?项目过程是否需要对组织级定义的标准过程进行裁剪等相关内容。项目过程定义是进行WBS分解前必须确定的一个环节，你采用瀑布模型和增量迭代模型对WBS分解和进度计划安排显然是完全不同的。