IT项目管理 第四章 习题

一、单选题

1、在你以前的项目实施期间,即使你交付了客户指定的内容,你也很难得到范围定义的签字认可。为了未来项目更好实施,你会更注意哪个过程?( B )
A.绩效报告
B.范围确认
C.范围定义
D.管理收尾

IT项目管理 第四章 习题

B是最佳选择,因为它是正式验收的过程。尽管范围的工作贯穿整个项目生命周期,但是它是每个项目阶段结束时对每个可交付成果和产品所做的重要工作之一。如果这项工作随着项目的实施而恰当地进行,那么,通常在项目结束时,无论是项目团队还是项目发起人就不会有那么多的异议。
C范围定义非常重要,但是范围确认是你检查或保证你的交付确实是按照范围定义进行的,范围定义包括所有经过适当批准的范围变更申请。

2、下列规则除 以外对于工作分解结构最低层次的工作包都是正确的。( C )
A.可以在一个位置不发生中断地完成
B.可以做出可信的估算
C.必须且只能分配给一个人
D.必须在80小时内完成

工作分解结构最低层次的工作包可以用一个人以上来做,只要它符合工作分解结构的其他规则。例如,两个人可以坐在一起创作一项新设计。80小时规则既不是一个严格的规则也不是什么公式。在许多项目中对工作包的定义有一个惯例,就是为了适当的检查它可以在80小时或两个工作周内完成。

3、下列哪项最不真实?(正确的英文为:which 0f the followings is most false:) ( C )
A.WBS的最低层次也可以叫作工作包
B.WBS词典可以用于保存各种工作要素的说明
C.承包商的WBS和合同工作分解结构(CWBS)基本上是相同的
D.WBS中的工作包还可以进一步细化

C:CWBS是一个定义,它处在承包商向买方报告所依据的层次,它通常处于比WBS更高的层次,承包商需要用它实际管理详细的工作。虽然工作包是WBS的最低层次,但是工作包可以并且经常被进一步分解。

4、客户通知你对原始范围做一项小的变更。与整个项目相比,这是一项很小的投入,并且你需要这个大项目的亲善关系。你将:( D )
A.拒绝做这个工作
B.同意免费做这个工作
C.做这个工作,然后给客户开账单
D.评估这个工作对成本和进度产生的影响,然后告诉他们你将在晚些时候决定这件事

A:拒绝是不合适的。范围总是可以变更的。范围管理并非意味着维持原始范围,而是在项目的生命周期中自始至终地对范围进行管理。 B:在现实生活中听起来是很好的,但是没有风险评估我们就不知道这件事对其他项目要素的影响。 C:只有在遵循买卖双方一致同意的变更程序的前提下才是可能的。 D:对影响进行审核始终是重要的。应该对包括“拒绝”在内的选择方案进行评估后做出决定。

5、一个项目的启动阶段输出不包括下列哪项? ( C )
A.项目章程
B.约束条件
C.产品描述
D.项目经理选择

启动过程用于1) 指定项目章程2)定义假设条件3)确定约束条件4)指派项目经理

6、你的公司刚刚收到对收购一个为你公司提供补充服务的公司的批准。你被指派为这次收购的项目经理。首席财务执行官给了你一份项目章程,她介绍了这次收购将如何改进你公司产品的市场渗透和打开一条新的销售渠道。她还授权你在项目活动中使用组织的资源。在回办公室的路上,你既担忧又兴奋,你要回去组织你的思路并开始计划编制过程。使用这份项目章程,你定义了可交付成果和主要项目目标,包括成本、进度和质量测量指标。你开始准备的是什么文件? ( C )
A.范围管理计划
B.项目计划
C.范围说明
D.工作分解结构

7.范围确认的主要内容是什么? ( B )
A.确保项目可交付成果按时完成
B.通过确保客户对可交付成果的接受,保证项目不偏离轨道
C.显示可交付成果符合技术规范
D.提供一个发现不同意见的机会

范围确认的关键方面是客户对项目可交付成果的接受。

8.一个新项目经理正在计划一个复杂的硬件安装项目。项目团队由15个人组成,他们都是各自领域的专家。这个项目经理不想在详细层次上对项目进行管理。他应该把项目工作分解到何种程度呢?( D )
A.尽可能小,因为工作复杂
B.尽可能大,因为与他打交道的都是专家
C.分解成每项任务1 000小时,因为与他打交道的都是专家
D.分解成大约每项任务80小时,因为它适合检查期

我们用于项目分解的方法(凭经验的方法)是80小时。团队成员的经验如何没有关系。你需要这个报告层次来有效地管理项目。

9.项目的工作分解结构是项目经理和她的团队一起开发的。但现在项目团队成员好像正在做工作分解结构以外的工作。工作分解结构的目的是:( D )
A.指导项目的成本估算,而不是工作怎么做
B.给高级管理层提供高层次项目范围概观
C.把制造项目产品所需的工作包括进去
D.把整体项目范围或完成项目所必须做的全部工作包括进去

工作分解结构的设计要显示生产项目输出产品所需的所有工作和其他项目特定的任务。它应该包括足够的细节,以便使你能够根据工作分解结构产生的工作包对项目进行管理。

10.参与准备范围基准计划的是:( B )
A.职能经理
B.项目团队
C.所有干系人
D.项目发起人

范围基准包括三个内容:项目范围说明书、WBS和WBS词典。 范围说明书的编制、WBS的分解以及WBS词典的描述都是项目团队完成的。

11.一个新软件产品的构建阶段即将完工。下一个阶段是测试和执行。这个项目比进度计划提前了两周。在进入最后阶段之前,项目经理最应该关注什么?( A )
A.范围确认
B.质量控制
C.绩效报告
D.成本控制

每个阶段结束时都必须进行范围确认,以便验证所做的工作符合项目的范围。

12.一个客户要求你给项目增加工作范围。现在项目低于预算并比进度计划提前一些。你应该怎么做? ( B )
A.批准该项变更
B.让客户了解该项变更对项目的影响
C.请发起人批准该项变更
D.从配置变更委员会获得批准

13.为了有效地管理一个项目,应该把工作分解成若干小块。下列哪项不是描述工作分解程度的? ( C )
A.直到得到有意义的结论
B.直到在逻辑上不能再进一步分解
C.直到可以由一个人来完成
D.直到可以进行现实的估算

WBS的最低层次可以是一个工作包,它可以进一步分解并由一个以上的人来实施。

14.下列哪项是范围确认的一项重要输入? ( A )
A.工作结果
B.历史信息
C.正式接受
D.变更申请

范围确认是确认工作完成的过程。因此,你在分析中需要使用工作结果。 C正式接受是一项输出,而不是输入。B历史信息是范围定义的一项输入。

15.下列哪项不是范围确认的输入? ( D )
A.工作分解结构
B.项目计划
C.工作结果
D.变更申请

D变更申请是范围变更控制的输入。范围确认关注的是对所实施工作的接受,而不是项目范围的变更。

16.在项目的实施阶段期间,你发现分包商在按照不完整并且不同的范围说明进行工作。作为项目经理,你应该首先做什么? ( B )
A.检查按照正确的范围说明完成的工作
B.与项目干系人一起审核工作范围
C.用文件记录与管理不一致之处,计算不一致性的成本
D.在工作范围完整之前停止工作

17.工作分解结构可以用于下列哪项? ( A )
A.与客户沟通
B.显示每项任务的日历日期
C.对每个团队成员显示职能经理
D.显示对项目的商业需求

PMI说工作分解结构是一个沟通工具。这并不意味着你必须向客户提交WBS。你可以在与客户讨论时使用WBS。你用甘特图显示日历日期,你用资源分配矩阵显示职能经理并在章程中显示商业需求。

18.在编制WBS时不需要下列哪项? ( B )
A.历史信息
B.项目章程
C.假设条件
D.范围说明

项目章程不是编制WBS的输入。

19.关于项目可交付成果,下列哪句是正确的? ( C )
A.项目可交付成果是在完全定义了工作之后确定的
B.在项目计划编制期间对项目可交付成果进行描述,然后随着时间的推移对它们进行细化
C.在项目开始时用项目干系人的输入对可交付成果进行定义
D.项目可交付成果由项目发起人来确定

“产品描述”是在启动阶段定义或考虑的。从定义项目阶段的时候开始,对主要可交付成果就进行定义并循序渐进的细化。产品是在项目章程或合同中定义的,可交付成果是根据项目干系人的输入定义并写出范围说明的。

20.你正在管理一个为期6个月的项目并且每两周与你的项目发起人开一次会。在工作了五个半月后,这个项目既符合进度又在预算内,但是项目发起人对可交付成果不满意。这一情况会把项目完工延误一个月。可以防止这种情况的最重要的过程是:( C )
A.风险监控
B.进度控制
C.范围计划编制
D.范围变更控制

范围说明是范围计划编制的输出,范围说明包括可交付成果。范围说明在项目干系人中提供一个对项目范围的共同理解。

21.除了 下面所有陈述是错误的? ( C )
A.WBS传达每个定义项目活动的日历日期
B.WBS对每个定义活动的商业需求加以说明
C.WBS向项目干系人传达定义的项目活动
D.WBS对负责每项定义项目活动的职能经理加以说明

D:WBS是用来分配责任的基本要素。

22.产品文件是 的输入。( A )
A.范围确认
B.绩效报告
C.风险分析
D.范围计划编制

B绩效报告讲的是项目绩效。产品描述是风险识别的一项输入。PMBOK中用的产品文件描述项目的产品,以供审核。例子有,计划、规范、技术文件、图纸等等。

23.用于向组织单位分配的工作分解结构中的控制点被称为:( A )
A.工作包
B.子任务
C.投入水平
D.综合控制点

工作包是工作分解结构的最低层次,它们用于分配一组工作,为的是在组织单位内进一步分解。

24.什么时候向一个项目指派项目经理? ( C )
A.合同签订后
B.就在合同执行之前
C.合同启动期间
D.合同计划编制期间

25.在过去的几周里项目团队已经对活动和任务做了3项范围变更。项目经理必须非常仔细地:( C )
A.记录所有变更
B.向发起人提交所有变更的文件
C.确保变更都反映在项目范围内
D.防止更多的变更发生

变更不可避免,要防止不必要的变更

26.一个项目经理发现两个团队成员讨论要完成一项活动需要什么并且做了很多范围变更。现在这项可交付成果完成了,那两个团队成员准备进行下一项任务。在看了他们所做的之后,项目经理确定他们所做的工作不符合项目要求。该项目经理的最佳行动路径是什么?( B )
A.增加另一项任务,与正确的项目范围相符合
B.拒绝交付的任务
C.让团队重新做这项任务并把这个事故加入到他们的绩效审核中
D.请该团队成员的经理派别的人执行这项任务

不应接受交付不符合要求的任务

27.范围确认应在何时做? ( C )
A.项目结束时
B.项目开始时
C.项目的每个阶段期间
D.计划编制期间

范围确认是为了获得对项目范围的正式接受,项目范围的结果是可交付成果。在每个项目阶段结束时(或在主要里程碑完成时)进行的可交付成果审核包括范围确认。因此,范围确认贯穿项目始终。

28.你是一个IT项目的项目经理。你项目团队的一个信息专家在同与他一起工作的一个低级别客户代表共进午餐后得知,在显示中一项简单的改造会给项目增加巨大的附加功能。你和项目发起人都已经对范围签字认可。那位信息专家进行了这项改造,没有给项目进度带来负面影响,也没有增加额外的费用。你应该采取什么管理措施? ( C )
A.这位信息专家所做的超过了客户预期,并且既没有影响项目成本也没有影响项目进度,因此,这位信息专家应该受到表扬
B.项目经理应该在项目计划中增加一项没有相应时间的任务
C.应该告诉这位信息专家,’他的行为是不可接受的,因为它完全可能给整个项目带来负面影响
D.由于这项变更已经做了,因此项目经理应该做一份变更控制表并请客户在上面签字

项目经理应该确保交付给客户的是客户所要求的,不能多也不能少!

29.在对一项任务的检查中,你发现一个团队成员正在用与WBS词典中的规定不同的方法完成这项工作。你应该如何处理这种情况? ( D )
A.告诉这名团队成员采取纠正措施
B.确定这种不同的方法对职能经理是否是可接受的
C.问这名团队成员,这种变化是否必要
D.确定这种变化是否改变了工作包的范围

团队成员在任务层次应该有一些做出改变的灵活性,只要他们没有超出WBS词典的整体范围即可。A 如果该项工作需要采取纠正措施,则应该由一个以上领域的人来实施。

30.一个项目经理正在对一项可交付成果实施审计时听到做这项工作的团队成员对所有人抱怨说,审计他做的工作是挑他的刺儿。你知道这是不对的。对于今后的项目你应该吸取什么教训?( B )
A.在项目开始时就告诉团队成员,他们的可交付成果将受到审计
B.在范围管理计划中制定一项政策
C.降低审计频率
D.用简单检查代替审计

通常没有必要像A说的那样对所有可交付成果都进行审计。降低审计频率或用简单检查(C和D)代替解决不了真正的问题。

31.在已经建立的绩效测量基准计划之后,客户要求扩大项目范围。客户将需要提交哪类文件? ( A )
A.变更申请
B.工作说明
C.修改的项目进度计划
D.发票

配置管理程序用文件记录正常项目文件的物理特征以及控制对它们的变更所需的步骤。

32.在一个设计项目开始两个月后,客户要求对产品作修改。在没有通知项目经理的前提下就做了这项变更。在最终测试阶段,测试结果与当初计划的不同。这种情况是下列哪项的例子?( C )
A.测试计划定义不完善
B.质量管理计划的开发不完善
C.使用范围变更控制的技能差
D.不坚持沟通计划

如果当时恰当地记录了范围变更,完全可能立刻提出该项变更的影响。

33.一个项目经理被分配到一个高优先度的新项目。只有5个可用的资源,因为其他资源已经被承诺给别的项目。完成项目的资源可用时间不足所需时间的一半,并且这个项目经理不能说服管理层改变项目的结束日期。这个项目经理应:(C )
A.与团队成员协调必要的加班,以便完成工作
B.对可以完成的工作,给团队提供做出杰出工作的机会
C.通过删除在限定的时间内不能完成的工作来削减工作范围
D.使用更有经验的资源,更快地完成工作

D是不可行的,因为资源已经提供了。
B是个好主意,但是它不针对这道题。
A永远不能是解决这种问题的首选手段,因为项目经理使用加班会失去他的可信性和绩效。最佳的选择是考虑削减工作范围C。

34.你正在管理一个位于偏远地区的项目,你的团队与客户的工作人员一起工作。在那里你的团队与客户工作人员之间的互动性很高,并且客户满意度被认为非常重要。由于客户对项目的进展情况表示非常满意,因此,你的管理层一点也不担心这个项目。然而,现在你落后于进度计划并且预算超支。另外,团队成员的士气低落,甚至有几个人谈论过辞职的事。团队成员对优先顺序的调整和任务的变化抱怨不断。你收到的有关所完成活动的周报常常与WBS和项目计划不符。为了最有效地解决这些问题,你应采取什么措施?( A )
A.你应该加强范围变更控制
B.你应该通过使用最实用的激励理论确定能使团队成员工作更令人满意的方法
C.你应该对现场投人必要的额外费用,对项目团队的活动进行更密切的监测
D.你应该建立一个奖惩机制,以便确保项目团队成员在项目计划规定的时间框架内完成任务

对项目范围和计划的非正式变更可能是进度延迟、成本超支和项目团队成员受挫的主要原因。有效的范围变更控制对项目的成功是至关重要的。

35.一个职能经理与项目经理的上司开会讨论对一个主要可交付成果的验收标准做一项变更。会后,这个上司与项目经理联系,让他实施这项变更。对这种情况最佳的做法是什么?( B )
A.尽快做这项变更
B.理解该项变更
C.给管理层一份变更申请表,让他们填写后尽快交回
D.把这项变更告诉团队

首先你需要理解该项变更,然后你才能与团队一起确定它的影响和选择方案。

36.一个在执行一个多国网站项目的项目经理在参加这个项目的完工和网站推出的聚会时和这个新网站的重量级用户聊天。他们表达了对目前网站恼人方面的一些意见。这个项目经理把这些反馈意见转达给项目发起人并建议对设计和范围做变更。下列哪项能最佳地描述项目经理所做的事情?( D )
A.范围限制
B.发起人管理
C.配置管理
D.项目干系人管理

这个项目经理必须识别项目干系人,确定他们的需求和预期,然后对预期进行管理和影响,以确保项目成功。

37.一个项目发起人给了项目经理一份章程并告诉该项目经理,他不能肯定该章程是否完整。项目章程应包括:(A )
A.可交付成果和目标
B.详细的工作范围
C.详细的进度计划
D.网络图

BCD在项目章程之后

38.在实施期间,你发现尽管以前已经批准了工作范围,但客户却对工作范围进行了变更,对该项变更的成本没有异议。你应该首先做什么? ( B)
A.遵循变更过程
B.与客户讨论该项变更并协商新的范围
C.与团队开会,计划选择方案
D.对该项变更可能导致的风险进行评估并形成文件

这里你要确定客户想要做的变更到底是什么并且要获得尽可能多的详细信息,根据这些详细信息团队可以对影响和选择方案进行评估。

39.产品确认不同于范围确认,产品确认:( D )
A.在实施阶段发生
B.确认使用了正确的产品
C.获得客户的签字认可
D.确保所有工作都已完成

范围确认关注的是客户接受,而产品确认关注的是确保所有工作都已完成。

40.管理层已经给你提供了项目章程,你正处于编制范围说明的过程中。你向团队征求输入数据以确保范围说明的完整性。然而,团队拒绝定义范围。下列哪项可以最恰当地描述这个问题?( B )
A.在范围说明开始之前没有完成WBS
B.团队正在做的范围说明没有产品分析结果的帮助和项目干系人对项目产品的一致同意
C.团队处在范围定义过程中,需要范围说明作为一项输入
D.在范围说明开始之前没有确定项目目标

在范围计划编制阶段,在可以完成范围说明之前需要项目章程、产品分析和成本/收益分析。

41.一个项目经理刚刚被分配到一个新项目中并得到一份完整的项目范围。这个项目经理必要做的第一件事是什么? ( B )
A.使用WBS建立项目计划
B.确认所有项目干系人的输人都包括在工作范围中
C.组织一个团队制定采购计划
D.建立网络图

范围是未来项目决策的依据和在项目干系人中间确认理解的基础。由于范围如此重要,因此,在继续项目管理过程之前,项目经理必须确认所有项目干系人的需求都包括在范围之中。按照顺序,答案应为:B→C→A→D。

二、案例分析题

【案例1】
创建工作分解结构
某信息系统项目较为复杂,有许多需要进行的工作,老刘是这个项目的经理,为了更好地制订项目计划,更有效地对项目实施过程进行管理与控制,老刘需要对项目开发过程可能涉及的工作进行分解。老刘的助手对开发过程进行了分解,认为可以划分为5大块:确定需要、设计、研发、测试和安装,如表2-1所示。

老刘认为,制订WBS是项目范围管理中的重要过程,一个详细的工作分解结构对项目的管理工作很有好处,但助手的工作分解结构并不完整。

问题:
(1)说明你对WBS的理解,创建WBS有哪些作用?老刘的助手在创建WBS中遗漏了哪些工作?
答:WBS将项目分解为小的、可以管理的片断。WBS的最底层为工作包,最终的工作包都必须有明确可验证的交付成果,逻辑上不可再分。在WBS中需要对各层各个分解进行编码。
创建WBS的主要作用如下:
(1)防止应该做的工作被遗漏掉。
(2)方便于项目团队沟通,项目成员很容易找到自己负责部分在整个项目中的位置。
(3)防止不必要的变更。
(4)提供一个基本的资源(人员和成本)估算依据。 (5)帮助获取团队认同和创建团队。
老刘的助手WBS不完整,遗漏了“项目管理”这项工作。

(2) 请补充完整本项目树型结构的WBS,并用三位数字给每项目工作编码。

(3) 叙述在创建WBS中应该把握什么原则。
答:
①在各层次上保持项目的完整性,避免遗漏必要的组成部分。
②一个工作单元只能从属于某个上层单元,避免交叉从属。
③相同层次的工作单元应用相同性质。
④工作单元应能分开不同责任者和不同工作内容。
⑤便于满足项目管理计划、控制的管理需要。
⑥最低层工作应该具有可比性,是可管理的,可定量检查的。
⑦应包括项目管理工作(因为是项目具体工作的一部分),包括分包出去的工作。

案例1分析
问题一:
WBS将项目分解为小的、可以管理的片断。WBS的最底层为工作包,最终的工作包都必须有明确可验证的交付成果,逻辑上不可再分,在WBS中需要对各层各个分解进行编码。
一个详细的WBS可以防止遗漏的可交付成果:帮助项目经理关注项目目标和澄清职责;建立可视化的项目可交付成果,以便估算工作量和分配工作;帮助改进时间、成本和资源估计和准确度;帮助建立项目团队和获得项目成员的承诺;为绩效测量和项目控制定义一个基准;辅助沟通清晰的工作责任;为其他项目计划的制订建立框架;帮助分析项目的最初风险。
“项目管理”工作是WBS中所必须的,显然,老刘的助手的WBS不完整,遗漏了“项目管理”这项重要的工作。
问题二:
WBS可以由树型的层次结构图或者行首缩进的表格表示。在本题中给出了一个树型的层次结构图,并且已经给出了这一层工作的编码和工作名称。对应于案例场景中给出的这层工作的下一级工作,可以将缺少的工作填补上,并按给定的3位编码格式进行编码。
最后还要检验WBS是否定义完整,项目的所有任务是否都被完全分解。
在实际应用中,表格形式的WBS应用比较普遍,特别是在项目管理软件中,一般都使用表格形式。
问题三:
创建WBS是指将复杂的项目分解为一系列明确定义的项目工作并作为随后计划活动的指导文档。
创建WBS的方法主要如下:
(1) 使用传导方针。
(2) 类比方法。参考类似项目的WBS创建新项目的WBS。
(3) 自上而下的方法。从项目的目标开始,逐级分解项目工作,直到参与者满意地认为项目工作已经充分地得到了定义。该方法由于可以将项目工作定义在适当的细节水平,对于项目工期、成本和资源需求的估计可以比较准确。
(4) 自下而上的方法。从详细的任务开始,将识别和认可的项目任务逐级归类到上一层次,直到达到项目的目标。这种方法存在的主要风险是可能不能完整地识别出所有任务或者识别出的任务过于粗略或过于琐碎。
创建WBS时需要满足以下几点基本要求:
(1)某项任务应该在WBS中的一个地方且保应该在WBS中的一个地方出现。
(2)WBS中某项任务的内容是其下所有WBS项的总和。
(3)一个WBS项只能有一个责任人,即使许多人都可能在其上工作,也只能由一个人负责,其他人只能是参与者。
(4)WBS必须与实际工作中的执行方式一致。
(5)应让项目团队成员积极参与创建WBS,以确保WBS的一致性。
(6)每个WBS项都必须文档化,以确保准确理解已包括的和未包括的工作范围。
(7)WBS必须在根据范围说明书正常地维护项目工作内容的同时,也能适当无法避免的变更。
另外,在实际工作中,对于一些较小的项目一般分解到4~6层足够了。WBS中的支路也没有必要全部分到同一层次,即不必把结构强制做成对称的。在任意一条支路,当达到一个层次时,如果符合所要求的准确生估算,就可以停止了。

【案例2】
某信息技术有限公司刚刚和M签订了一份新的合同,合同的主要内容是处理公司以前为M公司开发的信息系统的升级工作。升级后的系统可以满足M公司新的业务流程和范围。由于是一个现有系统的升级,项目经理张工特意请来了原系统的需求调研人员李工担任该项目的需求调研负责人。在李工的帮助下,很快地完成了需求开发的工作并进入设计与编码。由于M公司的业务非常繁忙,M公司的业务代表没有足够的时间投入到项目中,确认需求的工作一拖再拖。张工认为,双方已经建立了密切的合作关系,李工也参加了原系统的需求开发,对业务的系统比较熟悉,因此定义的需求是清晰的。故张工并没有催促业务代表在需求说明书中签字。
进入编码阶段后,李工因故移民加拿大,需要离开项目组。张工考虑到系统需求已经定义,项目已经进入编码期,李工的离职虽然会对项目造成一定的影响,但影响较小,因此很快办理好了李工的离职手续。
在系统交付的时候,M公司的业务代表认为已经提出的需求很多没有实现,实现的需求也有很多不能满足业务的要求,必须全部实现这些需求后才能验收。此时李工已经不在项目组,没有人能够清晰地解释需求说明书。最终系统需求发生重大变更,项目延期超过50%,M的业务代表也因为系统的延期表示了强烈的不满。

问题1:对张工在项目管理工作中的行为进行点评。
答:
①张工为了更明确地把握系统需求,聘请了原系统的需求调研人员李工,提高了需求定义的效率和质量。
②张工没有对李工开发的系统需求进行评审和复查,从而使得需求的缺陷没有被及时发现。
③张工没有要求用户对已经定义的需求进行确认,从而导致需求理解的偏差。
④张工对需求的变更不能进行有效控制,最终造成项目延期50%。

问题2:请从项目范围管理的角度找出该项目实施过程中的问题,以500字内回答。
答:该项目实施过程中的主要问题包括:
①在范围定义中,张工没有对李工定义的需求进行评审,造成需求中的质量缺陷没有被及时发现。
②在范围确认中,张工没有主动地要求用户对需求进行确认。
③在范围控制中,张工无法进行有效的范围控制,最终造成了重大的需求变更。

问题3:请结合你本人项目经验,谈谈应如何避免类似的问题,以500字内回答。
答: 对于本案例,项目经理需要对需求定义的结果进行质量控制,采取评审等方式减少需求中的问题。对已经定义的需求需要与用户进行确认,保证双方理解的一致。在发生需求变更时,也应该采取灵活的手段,在满足用户需求的前提下,尽量减少需求变更的范围。

 案例2分析
这是一个失败的软件项目,与很多失败的软件项目一样,在系统需求上栽了跟头。开发与定义软件系统的需求在整个软件开发过程中是最重要的一环,这是每个从事信息系统建设的项目经理都清楚的事情,但往往又因为一时的疏忽而造成需求的重大缺陷,最终导致项目的失败。案例中的项目经理张工就是既重视需求又没有控制好需求的一个例子。
在案例中,张工接手了一个系统升级的软件项目。对于这样的项目,首先需要熟悉原有的系统,然后才能谈升级的问题。因此张工专门找到了原系统的需求调研人员李工来解决新系统的需求问题。这无疑是一个很好的办法,可以快速准确地把握新系统的需求。从这一点上来说,张工是成功的,找到了合适的资源进行需求的开发与定义。李工也没有让张工失望,很快就整理出了新系统的需求,并进入了设计和编码阶段,除了客户太忙没有时间确认需求外,一切尽在张工的掌握之中。这是一个阳光灿烂的开端,如果一切顺利的话,项目的成功也就是早晚的事情。就如同大多数经典的悲剧故事一样,故事的序幕是美好的。
晴朗的天空飘来一块乌云,李工要移民加拿大。不过仅仅是一片乌云而已,并没有下起雨来。开发出的需求都已经过设计,一些编码工作也已经开始,李工的工作已近圆满完成,毕竟,一些细枝末节的问题还可以同客户直接沟通。
经过项目组努力,项目终于完成开发,准备发布了。这时,乌云开始下雨,问题爆发了。客户不认可项目组的工作,认为很多需求没有实现,实现的功能也与需求不符。
谁是这个项目组的罪人呢?李工?还是张工?换一个思路考虑一下,如果李工没有离开项目组,结果又会是什么样呢?客户会因为李工还在项目组就认可这个系统吗?很显然,不会。至多可以在双发的协商下少一些变更,项目延期不是50%,而是30%而已。如果非要区分50%和30%的区别,也不过是五十步笑百步而已。
从项目管理的角度来说,项目范围直接决定了工作量和工作目标,所以项目经理必须管理项目的范围。在范围管理中,范围定义、范围确认和范围控制又是最核心的三项活动,缺一不可。范围定义是基础的活动,不进行范围定义就不能进行范围确认和范围控制。范围确认则是基线化已定义的范围,是范围控制的依据。范围控制的作用在于减少变更,保持项目范围的稳定性。在案例中,由于张工没有进行范围确认,最后的范围控制也就变成了无本之木,控制过程肯定变成了讨价还价,失去本身的意义。
在软件系统的开发中,系统需求就是项目的范围。从软件诞生至今的几十年中,人们探索出了很多获取系统需求的方法,但是熟悉软件开发的人都知道,无论哪种方法都不可能定义出完美无误的需求,需求中的缺陷必然存在,无法完全避免。因此需求确认或者说是范围确认就显得更为重要。
有人可能会说,很难说服客户在需求上签字,很难让客户为需求的缺陷负责。以现在软件行业的情况,这种说法是不无道理的。让客户在需求上签字很困难,但并不等于就不需要进行范围确认,而且范围确认的方法也不仅仅只有需求签字这一种方法。召集客户的业务代表对需求进行评审、详细记录最原始的调研材料,让客户确认调研报告、采用迭代开发逐步确认系统需求,都是可以采用的方法。这些方法虽然没有直接确认需求分析报告,但至少可以让现有需求在项目组和客户之间达成一致,提供范围控制的基准,一样可以达到范围确认的目的。
再回到这个案例,项目经理张工乐观认为李工开发的需求没有什么问题,也误认为双方已经有良好的合作,在不紧逼要求客户代表签字显得不近人情,于是就抱着侥幸信息进入了开发。然而最终的结果是,项目延期严重,业务代表反而更不满意,张工也要承担项目延期造成的成本增加的责任。
有了上面的分析,后面问题的答案就不难得出。首先看第一个问题,对张工的行为进行点评。前面已经提到,张工注意到了需求的问题,专门找到了原系统需求负责人李工进行需求开发,这是对项目有利的一面。但由于缺少需求评审和确认的过程,造成需求中的缺陷没有被及时发现,系统需求没有与客户确认,造成缺少需求控制的基准,最终导致需求的重大变更。
对于第二题,联系范围管理的知识,我们不难发现张工在范围确认和范围控制中都有重大的缺陷,在范围定义中也由于缺乏评审造成需求的质量问题。
在完成第二题后,第三题就水到渠成了,第三题的要点见参考答案,此处不再赘述。

版权声明:如无特殊标注,文章均来自网络,本站编辑整理,转载时请以链接形式注明文章出处,请自行分辨。

本文链接:https://www.shbk5.com/dnsj/72939.html