项目遇险的3个问题4个因素和8个信号.docxVIP

工程遇险的3个问题4个因素和8个信号 在你的职业生涯中，总有需要主动结束一个失败的开发项 目的时候。当然，这是我们最想防止的。从积极的一面来 看，失败会令人沮丧。从负面来看，工程的完成可能会威胁 到你的职业平安。如果你能采取行动拯救一个工程，那么你 就有机会影响这个工程的成败。但是，除非你是工程经理， 否那么你无能为力。但是，你可以试着去理解即将发生的问 题，以便寻找逃避的机会。 这篇文章阐述了 3个同业务有关的预警信号，希望它们 能有助于你看清工程是否在走向崩溃。虽然这些总结并不太 具备科学意义上的准确性，但是，这些迹象能为你提供一些 早期警告。而且，尽管你无法拯救工程但你或许能通过这些 警示拯救你自己。在文章的末尾还提出了一些建议性的应对 措施，这样一来，万一你发现自己正身陷工程失败的泥沼， 那么你好歹可以采取相应的合理行动自救。 概述 针对成功的IT工程的统计报告不具备太大的意义。根据 Standish商业研究公司的一份报告，将近三分之一的信息系 统工程在最终完成之前都被取消了。另外，在所有的工程中 几乎有一半左右会超出其预算。 令人惊讶的是，工程失败的原因很少同技术有关。在软 件管理手册 Peopleware： Productive Projects and Team 一 书中，作者之一 Tom Demarco提醒读者注意，大多数工程都是因为技术以外的其他原因而招致失败的。可是，既然不是 技术原因造成的工程失败，那么又该是什么原因令这些工程 8、在工程工作会议上，与会人员只会扯皮说“都是接 口问题”、“必须采取行动”以及“该找某某人”。 当然，就个人而言，这些病症并不意味着你的工程会死 亡。但它们都是真正的红色警报，需要你立即采取行动。如 果你的工程表现出以上8种病症，那么你只能说你已经在泰 坦尼克号上了。准备自救吧。 失败的呢？答案是工程所牵扯的人和工作过程。具有挖苦意 味的是，普通开发人员在处理技术问题的时候应对有道但他 们在同其他人以及工作流程打交道的时候却不是这样。 三个问题篇 问题#1 :缺乏有意义的商务案例 真的叫人很吃惊，有些工程从一开始就找不出有意义的商务案例来支持它们。商务案例很重要，因为它为工程提供 了基础。商务案例应该能提出效益分析，同时还能考虑到商 业风险和工程之外事件的影响。机构会采用商务案例把它们 有限的资源划分出优先级别从而为其提供最大回报。 这样说来，在没有商务案例的情况之下，一个工程该如 何起步呢？这也是可能的，因为工程的商业属主也许仅仅是 需要实现什么特定的目标，而且有能力到达自己需要实现的 目标。另外还有一种可能性，那就是IT机构认为商业单位需 要它因此它们自己先创立出来再说。 最近两年，因为许多人相信他们必须开发某些工程来维 持竞争力，所以好多同Web关联的工程在不存在商务案例的 情况下就纷纷上马了。那争先恐后的样子就好象不奋力一搏 就赶不上趟似的，的崩溃意味着商务实践回归原来的基 础，这其中自然也包括商务案例。 对策：探询你目前着手的工程是否受到了商务案例的支 持。找一份商务案例来仔细阅读它。你所在工程的商业动力 是什么？这一商务案例符合逻辑而且可理解吗？该商务案例 存在怎样的前天条件？其风险是什么？什么外部因素会影响 商务案例？如果你无法为自己的工程找到可理解、有意义的 商务案例，那么你得知道为什么没有开发出有关的商务案 例。 问题#2 ：没有获得同意的需求或系统规范缺乏需求确实是一件非常危险的事情。在Standish的报 告里，挑战工程正常运行的三个最常见因素都和系统需求有 关。系统需求能给出将要创立的系统的大小和结构。它们定 义了系统应该和不应该实现的任务。 需求管理就是在整个工程周期之内定义、记录、追踪以 及管理需求的过程。需求管理保证了最终的解决方案能够满 足用户的需要。 对策:密切关注你的需求管理过程。如果看起来没有人负 责管理系统的需求，或者系统的需求是不断变化的，那么你 可能就有麻烦了。 问题#3 ：缺乏工程计划有些工程竟然会在没有工程计划的情况下运做。这简直 就是不用图纸造房子。每个工程都是一个事业，都应当具备 相应的工程计划。工程计划对那些工程决策人来说是非常必 要的交流手段，工程计划为工程的进展以及确定需要进一步 完成的其他工作提供了指导。 有一种说法是，具体的计划内容不需要告诉开发商；他们 只需要知道该做什么。这种观点对于只有一个人的工程团队 是行得通的，但是做大事是站不住脚的。开发人员确实需要 计划的指导。他们想知道什么任务优先。他们不想去猜想什 么才是最重要的。 仅仅有计划是不够的:计划必须跟上工程的开展。比方有 些工程刚开始的时候，房间里贴满了各种甘特图和波特图。 结果几个月甚至几年后，这些图表还是老样子，没有任何变 化。这不是当前的计划。为了使计