Chinaunix首页 | 论坛 | 博客
  • 博客访问: 14497542
  • 博文数量: 5645
  • 博客积分: 9880
  • 博客等级: 中将
  • 技术积分: 68081
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-28 13:35
文章分类

全部博文(5645)

文章存档

2008年(5645)

我的朋友

分类:

2008-04-28 21:35:36

下载本文示例代码
  在最好的情况下,管理软件项目也是很困难的。不幸的是,许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。   1、定义项目成功的标准   在项目的开始,要保证风险承担者对于他们如何判断项目是否成功有统一的认识。经常,满足一个预定义的进度安排是唯一明显的成功因素,但是肯定还有其他的因素存在,比如:增加市场占有率,获得指定的销售量或销售额,取得特定用户满意程度,淘汰一个高维护需求的遗留系统,取得一个特定的事务处理量并保证正确性。   2、识别项目的驱动、约束和自由程度   每个项目都需要平衡它的功能性,人员,预算,进度和质量同标。我们把以上五个项目方面中的每一个方面,要么定义成一个约束,你必须在这个约束中进行操作,要么定义成与项目成功对应的驱动,或者定义成通向成功的自由程度,你可以在一个规定的范围内调整。相关的详细信息,请参照我的《创建一种软件工程文化》(Creating a software Engineering Culture)(Dorset House,1996)中的第一章。   3、定义产品发布标准   在项目早期,要决定用什么标准来确定产品是否准备好发布了。你可以把发布标准基于:还存在有多少个高优先级的缺陷、性能度量、特定功能完全可操作、或其他方面表明项目已经达到了它的目的。不管你选择了什么标准,都应该是可实现的、可测量的、文档化的,并且与你的客户指的“质量”一致。   4、沟通承诺   尽管有承诺不可能事件的压力,从不作一个你知道你不能保证的承诺。和客户和管理人员沟通哪些可以实际取得时,要有好的信誉。你的任何以前项目的数据会帮助你作说服的论据,虽然这对于不讲道理的人来说没有任何可真正的防御作用。   5、写一个计划   有些人认为,花时间写计划还不如花时间写代码,但是我不这么认为。困难的部分不是写计划,困难的部分是作这个计划——思考,沟通,权衡,交流,提问并且倾听。你用来分析解决问题需要花费的时间,会减少项目以后会带给你的意外。   6、把任务分解成英寸大小的小圆石   英寸大小的小圆石是缩小了的里程碑。把大任务分解成多个小任务,帮助你更加精确的估计它们,暴露出在其他情况下你可能没有想到的工作活动,并且保证更加精确、细密的状态跟踪。   7、为通用的大任务开发计划工作表   如果你的组经常承担某种特定的通用任务,如实现一个新的对象类,你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成民确定和评估与他/她必须处理的大任务的每个实例相关的工作量。 共2页。 1 2 :   在最好的情况下,管理软件项目也是很困难的。不幸的是,许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。   1、定义项目成功的标准   在项目的开始,要保证风险承担者对于他们如何判断项目是否成功有统一的认识。经常,满足一个预定义的进度安排是唯一明显的成功因素,但是肯定还有其他的因素存在,比如:增加市场占有率,获得指定的销售量或销售额,取得特定用户满意程度,淘汰一个高维护需求的遗留系统,取得一个特定的事务处理量并保证正确性。   2、识别项目的驱动、约束和自由程度   每个项目都需要平衡它的功能性,人员,预算,进度和质量同标。我们把以上五个项目方面中的每一个方面,要么定义成一个约束,你必须在这个约束中进行操作,要么定义成与项目成功对应的驱动,或者定义成通向成功的自由程度,你可以在一个规定的范围内调整。相关的详细信息,请参照我的《创建一种软件工程文化》(Creating a software Engineering Culture)(Dorset House,1996)中的第一章。   3、定义产品发布标准   在项目早期,要决定用什么标准来确定产品是否准备好发布了。你可以把发布标准基于:还存在有多少个高优先级的缺陷、性能度量、特定功能完全可操作、或其他方面表明项目已经达到了它的目的。不管你选择了什么标准,都应该是可实现的、可测量的、文档化的,并且与你的客户指的“质量”一致。   4、沟通承诺   尽管有承诺不可能事件的压力,从不作一个你知道你不能保证的承诺。和客户和管理人员沟通哪些可以实际取得时,要有好的信誉。你的任何以前项目的数据会帮助你作说服的论据,虽然这对于不讲道理的人来说没有任何可真正的防御作用。   5、写一个计划   有些人认为,花时间写计划还不如花时间写代码,但是我不这么认为。困难的部分不是写计划,困难的部分是作这个计划——思考,沟通,权衡,交流,提问并且倾听。你用来分析解决问题需要花费的时间,会减少项目以后会带给你的意外。   6、把任务分解成英寸大小的小圆石   英寸大小的小圆石是缩小了的里程碑。把大任务分解成多个小任务,帮助你更加精确的估计它们,暴露出在其他情况下你可能没有想到的工作活动,并且保证更加精确、细密的状态跟踪。   7、为通用的大任务开发计划工作表   如果你的组经常承担某种特定的通用任务,如实现一个新的对象类,你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成民确定和评估与他/她必须处理的大任务的每个实例相关的工作量。 共2页。 1 2 : 下载本文示例代码


成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验成功项目管理的20条经验
阅读(89) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~