转贴：“防止软件工程项目范围蔓延的七个步骤 ” [发表于 2004/8/11] 状态 开放帖 浏览量 1117 |
|
|
软件项目超出计划的目标，通常被称为范围蔓延，是IT开发过程固有的矛盾。范围蔓延由几个原因引起而且如果处理不当将成为项目失败的主要原因。你必须采取一些步骤来控制对项目的改进并确保你和你的开发团队不会受到这些改进所造成的负面影响的损害--完工时间的拖延和工程预算的超支。
幸运的是，你可以遵循一些规则来防止项目范围蔓延造成出轨。我们马上就会学习这些方法。但是首先，让我们先来看一个警示性的例子，它能够帮助我们明白如果没有合适的计划和控制，事情会变得多么坏。
可怕的故事
当我在一家顾问公司工作的时候，我亲眼见证了我们的姐妹公司在一次公司内部为用户开发以Web中心的桌面环境的时候在项目范围上所做的挣扎。这个项目在五年前迫不及待的展开，没有项目计划而且只有一个主要开发者指导它的进度。开始的时候这个项目有许多很有天赋的Java 程序员而他们所有的指导来自于他们的并非技术专家的上司。
这听起来象是一场恶梦，它确实是一场恶梦而且现在还是这样。今天这家公司有了一个不值得的客户和一个其竞争对手在两年以前就已经超越的产品。随着这个项目继续进行，这家公司自身已经无法为它的员工发工资了，这对投资者看起来象一个无底洞，而且在它的管理层看来还只是刚刚开始。由于在开始工作的时候没有签定正式的项目意向书，这个项目的范围不断的改变，甚至每天都在改变，而所有的工作，从开发到销售和质量保证都因为不断改变的项目范围所带来的繁重工作而停滞。
好的一面
项目范围改变的效果并不一定是负面的，这得看你的实际情况。如果你是担当顾问或者是为一家顾问公司工作，那么软件功能改进对于你的业务来说是非常好的--只要能够很专业的处理这个问题。对于公司内部的软件开发过程，额外的功能能够让你的产品比你的竞争对手更胜一筹。但是，如果你发布软件的时间推迟一两个月，那么这个优势就会被丢失。通过控制你开发过程的费用并按时发布软件，你的项目就会取得成功，而不需要损失在软件制作过程中的灵活性。
从第一天开始就进行软件项目范围控制
控制项目范围在编写第一行代码以前就已经开始了。不论实际情况如何，每一次开发工作都应该有相应的项目计划或者项目协议书。即使你只是一个希望让老板高兴的程序员，你也能够因为在开始工作以前制定计划书而得到很多的好处。你可以使用下面的步骤来使自己成功的控制项目的范围：
1. 确保自己明白项目的范围。与项目主管会谈并发布整个项目的概览交与他们查看和评论。
2. 了解你自己认为重要的东西和项目主管认为重要的东西。在项目进行的整个过程里把你得到的信息按顺序列成一张表。这些信息应该包括预算，项目截止时间，功能发布，客户满意度，以及员工的满意度。一旦项目开始，你将使用这个表来调整你的时间安排。
3. 定义你的项目发布目标并让项目主管同意它们。项目发布目标应该是在项目过程中应该完成的功能的大概描述。
4. 把经过同意的项目发布目标细化成具体的工作要求。这些要求应该尽可能的详细并使用一个简单的电子表格来完成它。你的项目越大，那么你就应该包括更多的细节。如果你的项目持续的时间不止一两个月的话，不要忘记包括开发过程中软件升级的时间，你还应该总是为编写充足的文档而留下时间。
5. 将项目分解成大的和小的里程碑并编写一个大概的项目时间表以获得项目主管的同意。小的里程碑应该不持续一个月以上。不论你用什么方法确定任务的持续时间，你都应该为修正错误留下时间。在与不熟悉的员工一起工作的时候，我通常把时间定为预计工作时间的140％到160％。如果你的时间比较紧，那么你应该重新评估你的项目发布目标。在预算的范围内和截止的时间以前完成项目能够为额外的改进留下空间。
6. 一旦时间表已经创立，那么你就需要使用一个PERT图表或者任务分配表来分配资源和确定项目的关键路径。微软Project软件能够自动为你创建这些东西。你项目的关键路径会在项目进行的过程中发生改变。遵循这个图表来确定什么发布目标必须在规定的时间里完成。在非常大的项目里，我尽量做到不把我的开发阶段标准定义得太早，但是即使一个大概的计划也能够为你提供成功发布软件的依据。
7. 意识到会出现项目范围蔓延。尽早填写“项目范围改变要求”表格并在开发的过程中说服项目主管。一个“项目范围改变要求”表格能够让你在按项目主管的要求进行时间表改变以前对这些改变进行收益投入比的分析。
如果你能够立刻开始所有这些步骤，那很好。但是，即使你只能开始遵循其中的一些步骤，那么你所遵循的任何步骤都能够让你尽可能的避免和控制项目范围蔓延。用那种方式，你就能够更好的控制你的项目，而不是让你的项目控制你。
|
--------------------------------------------------------------------------------------------------------
鱼得水逝，而相忘乎水；鸟乘风飞，而不知有风，识此可以超物累，可以乐天机。
>>> 由论坛统一发布的广告：
|
|
楼主
 pmman6866
职务 无
军衔 下士
来自 不告诉你 :)
发帖 271篇
注册 2004/7/15
PM币 509
经验 
 
|
|
 Re:转贴：“防止软件工程项目范围蔓延的七个步骤 ”
[回复于 2004/8/11]
|
谢，顶！
|
--------------------------------------------------------------------------------------------------------
积极创造人生
------------------------------------
|
|
1楼
轻轻松松
职务 无
军衔 少将
来自 北京
发帖 1900篇
注册 2004/7/17
PM币 14271
经验
|
|
Re:转贴：“防止软件工程项目范围蔓延的七个步骤 ”
[回复于 2004/8/12]
|
|
顶
|
|
|
|
2楼
eveningstar
职务 无
军衔 一等兵
来自 上海
发帖 1689篇
注册 2004/4/7
PM币 1361
经验
|
|
Re:转贴：“防止软件工程项目范围蔓延的七个步骤 ”
[回复于 2004/8/12]
|
|
对于范围的蔓延，其实每个人都有感触。关键在于项目经理在面对这种来自客户方或公司的强大压力面前，能不能顶得住。
|
|
|
|
3楼
xiong_h
职务 无
军衔 中士
来自 广东
发帖 326篇
注册 2004/7/12
PM币 1253
经验
|
|
Re:转贴：“防止软件工程项目范围蔓延的七个步骤 ”
[回复于 2004/8/13]
|
|
键在于项目经理在面对这种来自客户方或公司的强大压力面前，能不能顶得住
|
|
|
|
4楼
十三郎
职务 无
军衔 三等兵
来自 不告诉你 :)
发帖 11篇
注册 2004/8/13
PM币 115
经验
|
|
Re:转贴：“防止软件工程项目范围蔓延的七个步骤 ”
[回复于 2004/8/20]
|
确保自己明白项目的范围（只要项目经理做这件事就行了）
解你自己认为重要的东西和项目主管认为重要的东西（二者所处地位不同）
定义你的项目发布目标并让项目主管同意它们（应该由WBS自上而下分配下来）
把经过同意的项目发布目标细化成具体的工作要求。（WBS）
将项目分解成大的和小的里程碑并编写一个大概的项目时间表以获得项目主管的同意。（一种方法，但随着项目的进行，变动会很大）
旦时间表已经创立，那么你就需要使用一个PERT图表或者任务分配表来分配资源和确定项目的关键路径。（已经不是主题了：控制SCOPE）
意识到会出现项目范围蔓延。（做好风险管理）
|
--------------------------------------------------------------------------------------------------------
俺也升为SCM版主了,呵呵
欢迎加水!
 http://www.e-works.net.cn/eworkbbs/ Steve
|
|
5楼
lookmezh
职务 无
军衔 少尉
来自 天津
发帖 1284篇
注册 2004/1/8
PM币 3600
经验
|
|
Re:转贴：“防止软件工程项目范围蔓延的七个步骤 ”
[回复于 2004/8/20]
|
其实范围的蔓延倒不是最难处理的，用成本和时间为筹码跟公司和客户进行协商，一般还能处理。最难处理的是项目精度的问题，不知各位有什么看法
|
|
|
|
6楼
xiong_h
职务 无
军衔 中士
来自 广东
发帖 326篇
注册 2004/7/12
PM币 1253
经验
|
|
Re:转贴：“防止软件工程项目范围蔓延的七个步骤 ”
[回复于 2004/8/23]
|
|
提前进度，将使成本上升，质量下降。做个平衡吧。
|
--------------------------------------------------------------------------------------------------------
俺也升为SCM版主了,呵呵
欢迎加水!
http://www.e-works.net.cn/eworkbbs/ Steve
|
|
7楼
lookmezh
职务 无
军衔 少尉
来自 天津
发帖 1284篇
注册 2004/1/8
PM币 3600
经验
|
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
