规划审查的主要好处
让软件组织将软件项目经费分成两阶段处理至少有三种好处。首先，被取消的项目常被看成失败的案子，可是一个进行了10%～20%就取消的项目反而应该视为彻底成功。完成80%～90%才被取消的项目所耗用的经费足以负担许多在探索阶段进行10%～20%就取消的项目。

再者，将庞大的经费延迟到项目完成10%～20%之后再拨款的话，可以对项目所需的庞大经费做出更可靠的要求。

最后，要求项目主管先完成项目的10%～20%才能要求拨款进行下面的部分，可以让这些主管做好与对项目成功息息相关的上游工作。这些工作往往被省去或忽略掉，带来的损失只有到项目下游阶段必须花费昂贵的成本来修正许多错误时才会突显出来。如果项目团队被要求在下游工作之前完成最重要的上游工作，项目的整体风险就会大大地降低。

风险管理

风险管理是一种特殊的规划方式。进行过大中型软件项目的人都亲身体验到许多事情都可能出错。最成功的项目就是采取积极步骤以免屈服在这些问题的困扰之下。你也许是完美主义者，可是对软件项目而言，就如人们说的，你可以有最佳期望，但是应该要有最坏准备。

几种最严重的软件项目风险与规划方式息息相关：

◆没规划好。
◆没照着规划方式做好。
◆没在项目环境变化后修正好规划方向。

在软件项目中不采取积极的风险管理就是忽视软件业界在过去几十年中从几千次教训

中总结的一个经验：软件开发是高风险的活动。如果项目采取积极风险管理的方式，就可以避免或降低许多风险，而这些风险有许多如果没处理好，就可能使项目陷入瘫痪中。

本文求生策略中包含（并在本书其他部分谈到）的做法比起其他方式风险更低，并能够增强对其他类型的项目风险的发现与控制，而被选录。对软件项目中要不要采取风险管理策略，你没什么选择余地。如Tom Gilb在《软件工程管理原理》（Principles of Software Engineering Management）一书中所说的，如果你不积极面对软件项目中的风险，你就会碰到这些问题。

项目控制

本文的一个主旨是，软件项目可被控制，从而迎合时间、经费跟其他目标。对一些人来说，这种项目“控制”的点子简直惨无人道，令人想象起一名专制的项目主管以皮鞭和铜链展现威权的样子。

--------------------------------
项目“控制”的反面就是项目失控。
--------------------------------

人们也许，会认为项目即使没人控制方向，也会顺利地进行下去而不会失控。我的想法和经验都告诉我那是不可能的，

有些人反对项目控制，因为他们认为这表示控制项目成员的行动。事情并不是这样，项目控制所控制的是项目本身。下面是一些我所指的“控制”的意思：

◆选用一种软件生命周期模型，如本文中使用的阶段完成模型，给项目中技术性工作一个轮廓构架。
◆管理需求的改变，只接受必要的改变。
◆确立设计与程序写作标准，使设计方式与源代码以彼此一致的方式产生。
◆建立项目的细节规划，使每一名开发人员的工作朝项目目标前进而不会防碍到其他人的工作。

控制并不是良好的技术性工作的附属品。项目控制必须透过积极的项目管理与持续渐进的控制行动来落实。项目控制的具体行动将在本文其他部分谈到。[@more@]