早期预警系统的组成要素

早期预警系统的组成要素

我们已经知道，早期预警系统（EarlyWarning System，简称EWS）有5个基本要素，如图12-1所示。

1．开发数据的收集

2．定期的项目现状评审

3．触发警报的潜在问题（或风险）的识别

4．启动校正行动

5．后续行动

如果实施拯救过程的机构早已成功部署了先进的软件开发过程管理系统，那么我们可以认为所有这5个基本要素或者其中的大部分要素已经齐备。因此，对于这些机构而言，早期预警系统已经存在，需要考虑到只是应如何将它用于重启后的项目（这个问题将在12.7节中进一步讨论）。

 

 

但是，遭遇项目灾难的常常是那些开发过程管理系统已失效或者是根本就没有有效的开发过程管理系统的机构。这意味着在项目拯救过程的最后一步，需要迅速建立起有效的、包含早期预警系统5个基本要素的过程管理系统。建立起这样一个过程管理系统的可能性有多大呢？

下面一个例子说明了一个大型的软件开发机构如何成功地同时为多个项目安装这样的过程管理系统。我们可以认为，对于单个项目而言，这项工作完成起来会更简单一些。

20世纪90年代早期，美国一家著名的通信公司在其通信基础设施部产品开发组做坏了几个项目之后，为这个部门招聘了一名新的总经理。客户对该部门所开发产品的质量有非常多的抱怨，他们开始转向使用该公司竞争对手的产品，该公司的客户正在流失。而且更为棘手的是，这发生在了一个以质量的同义词做名字的公司。新的总经理麦克·布莱恩特有着深厚的商业背景和开发背景，肩负着扭转该部门的使命走马上任了。

上任之后，布莱恩特立即开展了一系列的行动，这些行动和前面的几个灾难拯救步骤很类似。他请了几个“局外人”到公司来，让他们与部门的高级经理一起工作以确定该部门正在承担的项目的真实状况。以下是他所了解到的一些情况：

—  到处都存在着问题，软件开发方面存在的问题最多。

—  虽然所有的软件开发人员都说软件的开发遵循了一个有序的过程，但实情并非如此。有些项目制定了临时的开发过程，但每个项目都有自己的版本，而且这些过程不完整，它们也并没有被一致地遵循，只有很少数的开发人员知道这些过程的内容。

项目有进度、预算开支和进展报告，但是这些报告的内容不准确，因为基本没有价值或完全没有价值。

—  项目开发数据没有以可靠的方法收集。

—  项目评审只是偶尔进行，并且没有遵从合理的或者一致的评审过程，评审结果很少归档，也基本上没有后续行动。

—  开发机构和该部门的客户之间很少沟通。

布莱恩特指定了一名质量经理（QM）与之一起工作，来处理这些问题。这名质量经理每两周做一次项目评审（评审的频率后来更改为每月一次）。评审工作在一个大的报告厅举行，从早晨6:30开始费时1天（这一天中会供应咖啡、水果和点心），评审对象是该部门正在承担的所有项目。参与人员包括布莱恩特、质量经理、该部门的所有高级经理、每个项目的高层员工以及该部门主要客户的代表。

第一次评审简直就是一场灾难。布莱恩特和质量经理向每个项目经理提了一些非常尖锐的问题，几乎没有人能够给出满意的答案，因为他们不知道如何为评审做准备。这一天中大部分的时间都花在了向项目经理们说明如何准备下一次的评审报告上。在这次评审中，对每个项目设置了一些行动项，并要求项目经理们在下一次评审时针对这些行动项进行汇报。

在第一次评审和第二次评审之间的两个星期里，质量经理跟踪了这些行动项的落实情况，并且在必要的时候给项目团队提供了指导和帮助。同时也在如下方面提供了指导：如何为演示文稿收集原始数据、分析方法（例如帕累托图法）、缺陷和错误报告及进展报告等。

经过上述工作，第二次评审比较成功。包括项目团队成员在内的几乎每一个人都开始觉得更好地了解了自己的工作。当然，也有一些项目成员跟不上新的评审过程，需要给予他们额外的帮助。

到了第三次评审的时候，每个项目团队都有了一个项目经理能对之进行解释和辩护的项目计划。此时项目团队也积累了六个星期的数据，他们开始做一些初步的“计划VS实际”分析或者“挣值”分析。这为该部门建立早期预警系统奠定了基础。当一个项目负向偏移其计划价值超过10%时，就会自动标上一个小红旗。每次评审结束时，针对红旗所警示的问题安排校正行动或者确定将校正行动计划提交给质量经理的日期。当然，下次评审时每个项目演示文稿的开始部分都要对各自的小红旗进行回顾（有时更为频繁）。

布莱恩特花了两个月的时间对部门的所有项目进行了重组（两个大项目被取消），之后的两个月使这些项目回到正轨，在接下来的两个月确保这些项目都在控制之下稳步进行（此时一共花了6个月的时间）。

当布莱恩特到通信基础设施部走马上任时，他仅仅知道该部门深陷困境之中，但他并不清楚原因是什么（虽然他有一些想法）。该部门不能给他提供可靠的关于项目现状、进展和解决情况的信息。他怀疑手中有好几个项目是陷入灾难的，迫切需要关注。因此他的第一个行动就是了解项目的真实状况。布莱恩特从机构外部招聘了一位经验丰富的专业人士来帮助他完成这项工作。实际上，布莱恩特是从灾难拯救过程的第二步和第三步开始他的拯救活动的（后来，也相继实施了其他步骤中的大部分步骤，尤其是对那些陷入了非常严峻的困境的项目）。

从这个案例中我们可以学到以下一些经验：

—  首先，可逐渐引入有序的项目评审过程，但不能跨时太长（布莱恩特的部门花了6个月的时间使承担的项目恢复了正常，但只用了2个月时间就能有效地开展项目评审工作了，而且在第二个月（包含了2次评审），项目就已开始从评审中受益了）。

—  早期预警系统的所有要素最好在专业人士的帮助下引入（在布莱恩特的部门中，这个专业人士是质量经理）。

—  开始时，早期预警系统的要素可以比较简单。这些要素可以逐渐扩展，变得比较复杂。从后面的讨论中我们将认识到，对于被拯救的项目而言，在项目的整个生命周期中可以自始至终使用比较简单的评审过程（前面已经提到，项目灾难拯救过程不是引入非必需的新步骤的恰当时机）。

—  当高级管理层以身作则认真对待预警系统每一部分的工作（包括收集可靠的数据、准确报告项目状况以及其他基本要素等）时，项目成员也会认真对待这些工作。

从布莱恩特案例中得出的一个重要结论就是：能够而且必须将早期预警系统的各要素引入到开发机构中来，即使这个机构很特别。将一个早期预警系统过程引入到被拯救的项目中会占用1天半左右的时间。在下面的章节中，我们将讨论早期预警系统如何运作。

 

本文节选自《灾难拯救——让软件项目重回轨道》一书

[美]Bennatan（本拿塔） 著

侯艳飞，侯玉芳，李萌译

电子工业出版社出版

图书详细信息:http://blog.csdn.net/broadview2006/article/details/7719723