|
◆决定好项目关键决策者
◆前景叙述
◆该软件的业务状况
◆初步努力与时程目标
◆初步努力与时程目标估计
◆十大风险列表
◆使用者接口风格简介
◆使用者接口细部雏形
◆使用手册/使用需求规格
◆软件质量保证计划
◆软件开发细节规划项目管理者联盟
上述每一项准备在本书其他部分会更详尽的解说。项目管理者联盟
如果这些项目都没准备好，表示还没有足够信息来决定项目的质量如何，就不用进行
规划审查了。如果项目团队一直都没能够做好这些规划审查的准备，失败的风险很大。service.mypm.net
做好这些准备所需要的时间依据软件所需要的工作量而定。当一般使用者知道他们要的软件是怎样的情形下，这个准备时间可能只需要软件总开发时间的10%。一般情况下，这段准备时间会占总开发时间的10%～20%。在一些项目中，这项工作最困难的部分是帮助一般使用者理清他们要的是什么，所以偶尔这部分的工作会占用总开发时间的25%以上。对规划审查的经费要求与计划应该将这项工作的变动考虑进去。项目管理者联盟
规划审查的一般项目项目管理者联盟
规划审查应该集中在下列各项目上：
◆本来的产品概念仍然可行吗？
◆发展一个满足项目前景叙述的产品可能吗？
◆该软件的业务状态在更新、更精确的成本与时间估计出炉后依然差距不大吗？
◆项目的主要风险可被克服吗？
◆使用者与开发人员都能够同意使用者接口的细节雏形布置吗？
◆使用说明/使用需求规格是否完整而稳定，足以支持更进一步的开发工作？
◆软件开发计划是否完整，并适合进行更进一步的开发工作？
◆完成项目所需的预估成本为多少？
◆完成项目所需的时间安排如何？club.mypm.net
在项目开头10%～20%的完成部分应该足以解答这些问题，而且这些问题的答案应该足项目管理者联盟
以让客户或上层主管决定是否要继续拨款进行项目的后面阶段。项目管理者联盟
规划审查的主要好处项目管理者联盟
让软件组织将软件项目经费分成两阶段处理至少有三种好处。首先，被取消的项目常被看成失败的案子，可是一个进行了10%～20%就取消的项目反而应该视为彻底成功。完成80%～90%才被取消的项目所耗用的经费足以负担许多在探索阶段进行10%～20%就取消的项目。项目管理者联盟
再者，将庞大的经费延迟到项目完成10%～20%之后再拨款的话，可以对项目所需的庞大经费做出更可靠的要求。pmp.mypm.net
最后，要求项目主管先完成项目的10%～20%才能要求拨款进行下面的部分，可以让这些主管做好与对项目成功息息相关的上游工作。这些工作往往被省去或忽略掉，带来的损失只有到项目下游阶段必须花费昂贵的成本来修正许多错误时才会突显出来。如果项目团队被要求在下游工作之前完成最重要的上游工作，项目的整体风险就会大大地降低。项目经理博客
风险管理项目管理者联盟
风险管理是一种特殊的规划方式。进行过大中型软件项目的人都亲身体验到许多事情都可能出错。最成功的项目就是采取积极步骤以免屈服在这些问题的困扰之下。你也许是完美主义者，可是对软件项目而言，就如人们说的，你可以有最佳期望，但是应该要有最坏准备。项目管理者联盟
几种最严重的软件项目风险与规划方式息息相关：转自项目管理者联盟
◆没规划好。
◆没照着规划方式做好。
◆没在项目环境变化后修正好规划方向。项目管理者联盟
在软件项目中不采取积极的风险管理就是忽视软件业界在过去几十年中从几千次教训项目经理圈子
中总结的一个经验：软件开发是高风险的活动。如果项目采取积极风险管理的方式，就可以避免或降低许多风险，而这些风险有许多如果没处理好，就可能使项目陷入瘫痪中。项目管理者联盟
本文求生策略中包含（并在本书其他部分谈到）的做法比起其他方式风险更低，并能够增强对其他类型的项目风险的发现与控制，而被选录。对软件项目中要不要采取风险管理策略，你没什么选择余地。如Tom Gilb在《软件工程管理原理》（Principles of Software Engineering Management）一书中所说的，如果你不积极面对软件项目中的风险，你就会碰到这些问题。training.mypm.net
项目控制pmp.mypm.net
本文的一个主旨是，软件项目可被控制，从而迎合时间、经费跟其他目标。对一些人来说，这种项目“控制”的点子简直惨无人道，令人想象起一名专制的项目主管以皮鞭和铜链展现威权的样子。项目管理者联盟
项目“控制”的反面就是项目失控。
项目管理者联盟
人们也许，会认为项目即使没人控制方向，也会顺利地进行下去而不会失控。我的想法和经验都告诉我那是不可能的，项目管理者联盟
有些人反对项目控制，因为他们认为这表示控制项目成员的行动。事情并不是这样，项目控制所控制的是项目本身。下面是一些我所指的“控制”的意思：club.mypm.net
◆选用一种软件生命周期模型，如本文中使用的阶段完成模型，给项目中技术性工作一个轮廓构架。
◆管理需求的改变，只接受必要的改变。
◆确立设计与程序写作标准，使设计方式与源代码以彼此一致的方式产生。
◆建立项目的细节规划，使每一名开发人员的工作朝项目目标前进而不会防碍到其他人的工作。项目管理者联盟
|
