内容


Rational Edge

度量项目的健康性,第 1 部分

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Rational Edge

敬请期待该系列的后续内容。

此内容是该系列的一部分:Rational Edge

敬请期待该系列的后续内容。

illustration大多数组织用各种方法来使用度量制度对项目性能或者各种行动路线的有效性进行评估。没有度量尺度他们只能依靠主观判断来决定事物是否在正常轨道上运行,所以度量制度是不可缺少的。但是度量制度却是需要慎重对待的——很多时候您不能直接度量您真正想要得到的,比如当您真正想知道资源利用率的时候它却测量出的是生产量的增量(生产力)。

对于度量还有更为敏感的方面——人们通常对被度量的事情十分关注,并假设那些被度量的事物非常重要。即使这些度量与报酬不直接相关,他们也会在他们认为被度量的区域对项目性能进行改进。感觉是非常关键的:有时管理者们会公开地讲述一件事并通过度量对此进行加强,事实上却严重地破坏了他们所规定的目标。度量意味着被度量的事物是有意义的。

有一点需要说明:人们期望这些度量能够暗示什么是重要的事物。他们会解释这个信息,并将经常改变他们的行为来交付他们认为人们所需要的信息。效果会有很多种展示方式——从当被问到“项目进行得怎么样?”时,告诉管理者们他们想要听到的答案,到报告比实际工作时间更长或更短,报告时间的长短取决于比期望的工作时间更长是一件好事情(通常是“英雄文化”的迹象)还是一件坏事情(比实际期望工作的时间长有时也表明项目陷入了困境)。

应对这种无意识的度量结果的最好的方法是,完全公开您要的度量对象和原因,这要求您完全透明化项目的目标以及如何按照项目目标进行度量。

这篇文章是阐述在迭代软件开发生命周期中进行度量文章系列的第一篇。它描述了一些与传统软件项目度量相关的错误思想,接着针对先启阶段期间的有效度量进行了讨论。接下来的部分涉及了在精化、构建,以及产品化阶段的度量。

度量和目标

在您决定度量什么之前,需要决定什么是重要的事物。大多数组织都集中于以下三个区域:

  • 缩短交付一种解决方案的时间(快速上市的时间),却遭受得到最小化的功能以及特定水平质量和成本的影响
  • 降低成本,却遭受得到最小化功能性以及一定质量的影响,往往也限制了快速上市的时间
  • 提高质量,却遭受得到最小化功能性,成本以及快速上市时间的限制

项目管理的实质就是以一种可接受的方式管理平衡,从而得到想要得到的结果。为了达到这个目的,需要为这四个区域设置目标。大多数项目度量成本和时间,但是范围和质量影响了成本和时间,因此也需要度量。事实上,绝大多数项目的度量要想成功就必须包含不限于成本和时间的度量——这个可交付的解决方案必须做一些有用的事情(范围),还必须有满意的质量保证。

可变性和目标

"预测十分困难--尤其是预测未来。" -- Niels Bohr

一个目标就是一个预言——对在将来的某个时间什么将会获得成功的描述。现实可能会达不到预期的目标,或者,如果您很幸运的话,还可能超出目标。从统计学来看,项目结果是随机变化的,目标就是对那些随机变化的期望值的估计。

对于随机的变化关键要记住的是,实际的观测资料都在平均数或者中间值周围。这些值的分布状态的扩展称作可变性,表示观测值偏离中间值的程度。从对称分布来看,分布在中间值上面的与下面的差不多是相等的,最可能的值,即mode,是与中间值相等的。图1显示了一个典型的正态概率分布函数,这样命名是因为绝大多数值都属于这个分布范围内。

Figure 1

Figure 1

图1:正态概率分布函数,它表明实际的观测值可能会偏离期望值(或者平均值)

人们通常会犯的一个关键错误是,他们对目标只设定一个具体的值——期望值(或者平均值)。但是实际情况是变化的——我们需要考虑的是要为目标值建立一个公差,在这个公差范围之内的性能都认为是可接受的。这是一个很有价值的实践,因为它迫使您认为可变性的总计是可接受的,它还可以防止您集中关注重要变化时分散精力去关注与变化性不相关的因素。

度量与迭代开发

迭代方法的一个主要的好处是,它可以有意识地减少整个项目过程中的变化,如下图2所示。注意这个图对图1进行了反转,在这个迭代趋于结束时得到了一个非常狭窄的分布。

Figure 2

Figure 2

图2:迭代开发的方法减少了项目整个过程中的变化性

“X”轴代表一个评估的期望值,这个轴线上面以及下面的虚线表示这些围绕在这些评估值上下的预期变动。在这个项目整个过程中,当风险降低时,如图3所示,变化性也会随之降低。

Figure 3

Figure 3

图3:风险,主要代表了变化性和不可预测性,在项目的迭代中随着时间而降低

在图3中的四个阶段——先启、精化,构建以及产品化——中,主要关注于不同类型风险的减轻。因此,四个不同阶段的目标也不同。这表明用来跟踪项目目标进度的度量需要随着状态的不同而变化。

当度量出现错误的时候

许多组织使用的最糟糕实践之一是“详细地计划,然后度量这个计划。”他们自己说,计划与度量并不是坏事,但是大多数组织使用的时间更多的用来促使错误行为的发生,而不是其它单个的实践。以下是几种通常发生的情况:

  • 一个项目一旦开始,作为最早的行动之一项目经理通常会创建一个项目计划。基于这些对需要解决的问题和不明确的目标的粗略信息,项目经理会尽最大努力来“猜测”时间日程表和大概成本。
  • 无论有多少关于这个计划实验性本质的问题被提出,这个计划都会开始它自己的生命。组织的高层管理者们忽略了一个事实:尽早计划事实上只是思维试验,还不如他们以之为基础的假设有效。计划变成了一种对成功将是什么样的预言,管理失败的焦点从计划转移到测量偏差上来,而没有指导这个项目朝着成功结果的方向发展。这个计划变成了项目经理脖子上的一个沉重的负担。1
  • 由于他们采取的措施与计划不一致而导致这个项目团队成员都很气馁,尤其是当每个人似乎知道这个计划是完全虚构的时候,知道这个计划与项目的日常现实不相连贯的时候。如果这个计划从理论上讲,能够是正确,那么它就是非常靠不住的。当这个计划不可避免地导致了对将来预测的失败,按照计划执行的管理者们也毫无疑问会带领他们的团队和项目一起失败。

    当这个计划不能与事实相匹配时,唯一的逻辑线路就是偏离计划,但是当管理系统要处罚这个计划时,它通常会毫无选择地丢下团队而去创建这样一个假象:即使他们错了也好按照这个计划继续下去。

为什么会发生这样的事情呢?问题不是计划本身,而是计划缺乏现实性,违背了经验。问题是对事情的详细计划根本没有起到计划的作用,因为我们所知道的太少,然后让团队成员对这种虚构的事物“负责”。

一种比较好的方法是,知道这个项目在什么地方结束,然后利用灵活地操纵使其朝着目标的方向进行,并在整个项目中持续这种状态。为了做到这一点,您需要在这个项目的不同点查找正确的信息。

预先详细的计划有什么不对呢?

虽然前面的讨论简单涉及到了在项目开始就进行详细计划是错误的,但是这种实践是如此的普遍且深入并且是项目管理传统的一部分,以至于需要关注才能阻碍它的使用。简单地说,在项目的早期就创建并管理一个详细的计划是不正确的,因为:

  • 因为期望一个项目经理懂得决定项目活动和项目技术工作的时间选择是不切实际的。重要的事件和目标可以决定,但是需要达到这些目标的实际工作超出了这个项目经理的技术理解。需要在每个有意义的精确级别计划的技术估计需要包含更大的开发团队,由项目经理制定的任何“计划”都很可能是不确定的。
  • 项目早期中的这种行为详细路线的不确定性是值得高度怀疑的,即使是开发团队创建的详细计划也是不确定的。在项目的头几天或者几个周内,对需要解决什么问题和要达到什么目标都缺乏可靠的信息,因此在缺少信息的情况下指定详细的计划也只是浪费时间。
  • 如果详细地计划是浪费时间,那么在这个项目的早期度量这个详细的计划是很冒险的。这个项目通常注定会失败。使人们对这个有缺陷不完善的计划负责通常会使他们打消采取正确行为的念头,即使当他们得知信息是可利用的。它还迫使人们采取错误的行为,因为这个计划告诉他们应该这样做,或者,它通常会鼓励人们创建“两套制度”:一个用在“真实的”项目中,另一个则追溯到原始但有缺陷的并与他们正在进行的度量相抵触的计划。不论如何,早期详细的计划会促使人们采取错误的行为。

因此度量一个与详细计划相抵触的项目不会是一种好的方法,那么应该怎样度量才能确保这个项目在正常运行呢?

确定度量方法 -- 按阶段划分

简单的回答是,在这个项目的不同阶段您要度量不同的事物。这个项目可被分成一个统一过程中的四个阶段(先启、精化、构建以及产品化),每个阶段都会集中关注一套与不同风险相关的目标。也就是说,每个阶段都集中关注于如何减少不同的风险。

但是在我们对一个风险讨论之前,了解每个阶段的主要目标是十分重要的,如图4所示。

Figure 4

Figure 4

图4:目标和目的与生命周期的四个阶段是相关联的

这篇文章以及后续的文章都将讨论如何建立合适的度量来确定这个项目是否正常运行,并达到这些目标。

在先启阶段要度量什么

在先启阶段有以下的目标:

  • 确定并减少业务、项目以及投资的风险
  • 从技术层面和财务层面评估这个项目的生存能力
  • 在项目的范围以及目标方面达成一致的协议
  • 为项目的进展制定一个全面的计划

每个项目至少在先启阶段都需要投资,为以后的阶段进行投资将取决于先启阶段的结果。

先启阶段的重点是减少项目中要么是经济上不合理的要么是技术上不可实行的风险。对于这一点,团队必须探究这个项目的利益和成本以至于可以制定一个可靠的计划,无论项目是否进行下去。在先启阶段结束时,项目出资人认为这个项目是可行的,并认为这个项目的商业案例如果继续运行下去是可以获取成就的。每个人都必须认同这个项目是可行的——那就是说,这个项目是值得做的,时间和成本的评估也是可信的。如果这些事情不能达成一致,最好在项目开始之前就转移您的注意力到其它更有价值的项目上。

这个阶段的度量主要是答复以下这些问题:

  • 这个项目的商业利益是什么?
  • 达到这个商业利益所预期的成本是多少?
  • 这个项目值得完成吗?

前两个问题很难回答,它们将决定对第三个问题的回答。在紧接着的两个部分中我们将讨论如何度量商业利益和预期成本,以及如何将找到这些答案融入到全面的度量计划中。

评估财务能力

商业预期利益是建立在对其付出所得的回报的限制上的。在项目的这个阶段,不需要精确的评估,粗略的估计就足以在启动这个项目时建立一个清楚的估价。

商业利益通常以净现值来表示,它综合考虑了金钱所得的时间价值和风险问题。从数字层面来看,它可以这样定义:

NPV=initial investment +_ sigma multiplied by (cash flows at year t) over (1+r)superscript t where t = end of project and t=1

NPV=initial investment +_ sigma multiplied by (cash flows at year t) over (1+r)superscript t where t = end of project and t=1

“项目的末尾”的确是这个解决方案预期生命的最后阶段,r 代表贴现率,或者这个项目的要求回报率。我们应该慎重选择这个 要求回报率 以此确保充分考虑这个项目的风险。值得注意的是此要求回报率是建立在与项目风险等同的基础上的。

暂时不考虑最初的投资(在下一个部分涉及到项目成本),商业利益是由这个解决方案的未来现金流来评估的——既有与增长的收入有关的积极的一面,也有与由预期维护导致的负现金流相关的消极的一面。

评估这个商业利益的支持证物通常包含少量产品或者服务的市场调查,项目所关注成本缩减的商业成本数据,或者两者兼有。正如NPV公式所表明的那样,评估的具体适时性也是十分重要的,很快就能收到利益比在未来的某个时候收到更有价值。

受遵从性规则驱使的项目利益更容易评估。通过处罚回避来评估此项目的利益。无论如何,遵从性利益的适时性仍然十分重要。

评估技术可行性并且估计全面的项目成本

要获取预期成本的评估,从理论上讲,可以基于历史成本数据从参数评估模式中得到2,但是由于当前缺乏与这个项目相关的有用数据,这意味着您必须构建一些小的且有代表性的部分系统来推断项目的成本和日程表数据。它有利于选择一些代表性的情景和开发软件来进行交付。这样做通常能够确定您对这个项目技术复杂性的假设是否是正确的,即使您不得不“剔除”相当一部分系统的功能。即使您拥有了参数评估模型,早期的原型成果同样可以帮助您验证这个参数评估。

从早期的原型成果中可以得到两个结论:一个是关于这个项目的技术是否可行的定性评估,一个是项目日程表和成本的定量度量。这些从早期的原型成果获得的原始数据主要用来加入一个或者更多的评估模型,从而衍生出成本信息。使用不止一个模型是预测中一种跨越——验证评估——较大分歧的方法 ,这些由模型提供的预测表明您应该仔细分析您的假定情况。

图3展示了这个项目的预期风险曲线图表,在精化阶段出现了风险高峰点,在随后的阶段又逐渐衰退。注意这条曲线代表了一个您应该为之奋斗的 理想风险的轮廓,只要您积极并迅速地管理风险就可以得到这个目标。导致风险数量减少风险程度降低的纯粹时间段并不是什么不可思议的。

为了使风险在掌控之下,您必须有高度的意识来判断您所面临的风险以及您期望什么时候可以减轻它。很多项目都收集了一个风险表,通常在项目的前期,但是除非这个风险表是很关键的管理工具,否则基本上不起作用。仅仅收集一个风险列表是远远不够的,您还需要在这个项目的全面计划中将这些风险融合到迭代中,然后制定降低这些风险的行动,并分配到迭代中作为迭代计划的一部分。在为迭代早期进行风险绘图时,您不必为项目的活动创建一个详细的计划,目前只需要为迭代绘制风险就足够了。这样做将会给您是否足够早地处理风险的意识。当您将这些风险分配给迭代时,要确保将较大的风险分配给初期的迭代。为了绘制这个风险图,在先启阶段需要做一些探究工作来帮助理解您所要面临什么样的风险。

绘制出这些风险,然后做一些关于将要完成什么样的工作的有根据的猜想,据此来处理风险可以让您知道迭代将需要什么资源。再一次提醒,这个目标不是创建一个详细的计划,而是为项目成员提供一个大致的路标。这个人员配备模型(如果“模型”这个词听起来太正式,可换成“图”)将通过对成本适时的评估提供所需的全部成本评估。

确定项目的生存能力

确定财务生存能力通常有一个两步方法。首先,经常有一个快速上市的因素需要考虑:有时如果在一个特定的时间段内一个解决方案不能交付到市场,那么这个项目就不值得完成。如果这个上市所需的时间能够满足,那么这个解决方案的NPV就可以计算出来。如果这个NPV是负的,那么这个项目也不值得继续从事下去。如果这个NPV是正的,那么这个项目可能就值得继续进行,除非它不能比投资其它项目有更高的价值。3

通过增加评估的可变性,将风险分散到各个目标往往比较主观,也能很好地实现——事实上,是通过扩大“误差范围”。其实这个阶段的大多数评估都是高度主观的,并可通过较大的误差范围将其去除。对于一个评估最有价值的问题不是“它正确吗?”,而是“这组值的什么范围是可能实现的?”。反过来说,评估中的可变性可通过增加NPV中项目的要求汇报率来调整。通常,我们会分析很多情节来为NPV确定期望情况和最差情况的价值。我们经常用项目前期的结论作为后面的基础,无论最差情况是否在可接受范围之内。

一旦这个解决方案被展开,评估的NPV将作为实际结果对照的度量,具有非常重要的地位。

其它度量

当评估的NPV在先启阶段仍然有十分重要地位时,此时必须为项目考虑其它作为辅助的度量:

  • 主观度量,比如:
    消费者满意度, 主办组织对项目的进展满意吗?
    士气,项目团队对项目的进展满意吗?他们对成功有信心(至少是被保护着的)吗?
  • 客观度量,比如:
    绝对进度,这个阶段是否在期望的时间内完成的?
    需求稳定性,在这个阶段的整个过程中项目的目标的变化程度有多大。有很多变化就意味着项目目标仍在变化,同时也意味着NPV评估部分或者全部都值得怀疑。
    风险稳定性,正如测试的那样,项目的风险有多大仍在被发现。我们很难知道您不清楚哪些问题,因此这只能是一个片面的主观度量方法,但是如果新的主要风险仍在以相当大的速率被发现说明您可能没有很好地理解这个解决方案或者这个业务需要继续开展。

在这个项目的整个过程中,您需要搜集数据并与期望值作比较以保持项目的正常进行。在先启阶段您将不会有很多关于以后度量的数据,但是在适当的地方您需要有一定的装置在您离开这个阶段之前搜集这些数据。在所有这些度量中,倾向性比绝对的值要重要得多。

  • 支出的工作量,实际的与期望的
  • 缺陷发现以及修复趋势,实际的与期望的
  • 风险发现以及减轻,实际的与期望的
  • 未计划工作的识别与执行,包括范围变更
  • 已计划工作的执行与测试, 实际的与期望的

所有的这些评估都是粗略的。对于计划中的工作,一张关于迭代情景的图已经足够。在此项目接下来的阶段中如何利用这些度量将是后面文章的话题。

总的来说,尽管这些度量都比较粗糙,但是为在项目整个过程中决定此项目是否在正常运行的项目过程和性能的度量提供了一个框架。

决定不投资一个项目是先启阶段一个完美的结果也没什么大不了的,只要这个决定是基于将被交付的商业价值和技术可行性的,就不能认为是失败。事实上,决定不再继续投资这个项目可能是最好的结果,如果它能为其它更有价值的项目腾出资源。

总结

每个项目团队的目标都应该是在减少时间和成本的同时增加项目的成功率。这个普遍的目标与商业常见目标是紧密相关的,它将在一个预期的时间和满意质量内,以及可接受所交付的商业价值范围内为消费者交付一些改进的性能。

使用正确的度量可以通过为团队成员提供关于何为重要之物的清晰指导,从而帮助达到这些目标。清晰的度量明显与项目执行和项目性能相紧密相关,其实是它们帮组了团队交付的成功。保持度量的简单可以帮助团队尽快集中于焦点问题。简单的度量还有其它好处:他们减少了报告的运行时间,使度量的转换更为简单。度量正确的事物可以支持良好的项目行为,然而度量错误的事物不仅浪费时间和资源,还向团队发送重要事情的错误信息。

根据项目生命周期的不同阶段改变度量方法可以使人们在思维混乱的时候关注风险和十分重要的问题。我们说迭代方法的价值在于降低项目风险,因此利用争取的度量加强管理使团队能够将其付诸于行动之中。

在先启阶段,度量主要关注于建立项目的财务和技术可行性,同时还有为项目剩余的部分设立成本,全面日程表以及减轻风险的目标。财务可行性是建立在对市场分析和机会的基础上的,在整个过程中通常以现金流的方式表达,而技术可行性的评估是根据一个或者更多技术探究可选择技术方法,它们的成本以及利益来进行的。在这个阶段的末尾,从这些研究中获取的信息将为在项目接下来的过程中用来决定此项目是否正常运行的度量框架提供基础。

进一步阅读

这篇文章摘自早期发表的管理迭代化软件开发项目,由 Kurt Bittner 和 Ian Spence 所著,于2006年由Addison-Wesley发行。

注释

1 如果此参考资料不太容易理解,我建议您阅读 Samuel Taylor Coleridge 所著的"The Rime of the Ancient Mariner"。

2 例如,CoCoMo II 模型,Coarse-grained Wide-band Delphi (如协商一致的评估),以及功能点分析(包括“用例点”)。

3 由于项目的相互关系,项目组合管理事实上比这里所建议的复杂一点,但是现在我们只谈到这里。我们将在后面的文章中回到组合管理关注点上来。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=202217
ArticleTitle=Rational Edge: 度量项目的健康性,第 1 部分
publish-date=03152007