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

1、工程遇险的3个问题4个因素和8个信号在你的职业生涯中，总有需要主动结束一个失败的开发项 目的时候。当然，这是我们最想防止的。从积极的一面来 看，失败会令人沮丧。从负面来看，工程的完成可能会威胁 到你的职业平安。如果你能采取行动拯救一个工程，那么你 就有机会影响这个工程的成败。但是，除非你是工程经理， 否那么你无能为力。但是，你可以试着去理解即将发生的问 题，以便寻找逃避的机会。这篇文章阐述了 3个同业务有关的预警信号，希望它们 能有助于你看清工程是否在走向崩溃。虽然这些总结并不太 具备科学意义上的准确性，但是，这些迹象能为你提供一些 早期警告。而且，尽管你无法拯救工程但你或许能通过这些 警示拯

2、救你自己。在文章的末尾还提出了一些建议性的应对 措施，这样一来，万一你发现自己正身陷工程失败的泥沼， 那么你好歹可以采取相应的合理行动自救。概述针对成功的IT工程的统计报告不具备太大的意义。根据 Standish商业研究公司的一份报告，将近三分之一的信息系 统工程在最终完成之前都被取消了。另外，在所有的工程中 几乎有一半左右会超出其预算。令人惊讶的是，工程失败的原因很少同技术有关。在软 件管理手册 Peopleware： Productive Projects and Team 一 书中，作者之一 Tom Demarco提醒读者注意，大多数工程都是因为技术以外的其他原因而招致失败的。可是，既然

3、不是 技术原因造成的工程失败，那么又该是什么原因令这些工程8、在工程工作会议上，与会人员只会扯皮说“都是接 口问题”、“必须采取行动”以及“该找某某人”。当然，就个人而言，这些病症并不意味着你的工程会死 亡。但它们都是真正的红色警报，需要你立即采取行动。如 果你的工程表现出以上8种病症，那么你只能说你已经在泰 坦尼克号上了。准备自救吧。失败的呢？答案是工程所牵扯的人和工作过程。具有挖苦意 味的是，普通开发人员在处理技术问题的时候应对有道但他 们在同其他人以及工作流程打交道的时候却不是这样。三个问题篇 问题#1 :缺乏有意义的商务案例 真的叫人很吃惊，有些工程从一开始就找不出有意义的商务案例来支

4、持它们。商务案例很重要，因为它为工程提供 了基础。商务案例应该能提出效益分析，同时还能考虑到商 业风险和工程之外事件的影响。机构会采用商务案例把它们 有限的资源划分出优先级别从而为其提供最大回报。这样说来，在没有商务案例的情况之下，一个工程该如 何起步呢？这也是可能的，因为工程的商业属主也许仅仅是 需要实现什么特定的目标，而且有能力到达自己需要实现的 目标。另外还有一种可能性，那就是IT机构认为商业单位需 要它因此它们自己先创立出来再说。最近两年，因为许多人相信他们必须开发某些工程来维 持竞争力，所以好多同Web关联的工程在不存在商务案例的 情况下就纷纷上马了。那争先恐后的样子就好象不奋力一搏

5、 就赶不上趟似的，的崩溃意味着商务实践回归原来的基 础，这其中自然也包括商务案例。对策：探询你目前着手的工程是否受到了商务案例的支 持。找一份商务案例来仔细阅读它。你所在工程的商业动力 是什么？这一商务案例符合逻辑而且可理解吗？该商务案例 存在怎样的前天条件？其风险是什么？什么外部因素会影响 商务案例？如果你无法为自己的工程找到可理解、有意义的 商务案例，那么你得知道为什么没有开发出有关的商务案 例。问题#2 ：没有获得同意的需求或系统规范缺乏需求确实是一件非常危险的事情。在Standish的报告里，挑战工程正常运行的三个最常见因素都和系统需求有 关。系统需求能给出将要创立的系统的大小和结构。

6、它们定 义了系统应该和不应该实现的任务。需求管理就是在整个工程周期之内定义、记录、追踪以 及管理需求的过程。需求管理保证了最终的解决方案能够满 足用户的需要。对策:密切关注你的需求管理过程。如果看起来没有人负 责管理系统的需求，或者系统的需求是不断变化的，那么你 可能就有麻烦了。问题#3 ：缺乏工程计划有些工程竟然会在没有工程计划的情况下运做。这简直就是不用图纸造房子。每个工程都是一个事业，都应当具备 相应的工程计划。工程计划对那些工程决策人来说是非常必 要的交流手段，工程计划为工程的进展以及确定需要进一步 完成的其他工作提供了指导。有一种说法是，具体的计划内容不需要告诉开发商；他们 只需要知

7、道该做什么。这种观点对于只有一个人的工程团队 是行得通的，但是做大事是站不住脚的。开发人员确实需要 计划的指导。他们想知道什么任务优先。他们不想去猜想什 么才是最重要的。仅仅有计划是不够的:计划必须跟上工程的开展。比方有 些工程刚开始的时候，房间里贴满了各种甘特图和波特图。 结果几个月甚至几年后，这些图表还是老样子，没有任何变 化。这不是当前的计划。为了使计划保持最新，工程计划必 须反映实际完成的工作，同时预测要完成的工作。更新计划的频率不要高到一周一次，但也不能少于两周一次。该计划 应准确反映完成工程的时间和本钱。只有在这种情况下，我 们才能说这个计划是最新的。经常改变的计划和那些过期的计划

8、一样可怕。我见过这样 的工程计划，每周都要修改，结果工程的阶段终止日期超出 了一周的范围。计划每周更新，但工程仍然失控。对策:如果没有公开的工程方案，反正你得拿出一个。如 果你被告知因为信息保密不能查阅工程计划，那么你不妨把 这件事当作一个严重的警讯。除非你在研发新一代原子弹， 否那么秘密工程计划根本没有存在的理由。对信息保密通常意 味着管理层知道工程有问题，他们试图掩盖它。确保计划总是新的，并有一个合理的更新间隔。它不应该 是一个不断变化的目标，但它必须是最新的。如果你不能保 证工程计划的最新状态，那么工程就会出问题。工程快完蛋了，我该怎么办？你发现自己的工程已经出现了以上一个或者多个预警信

9、 号吗？对这个问题的回答取决于你的个人状况。如果你感到 你能采取行动改变现状，那么你一定要立即行动。同工程经 理、顾客或你队伍中的其他成员对话。用一种就事论事、不 具威胁性的方式讨论你所关心的问题。试着尽可能提出正面 意见。看看你能否给工程带来转机。如果工程濒临失败，你发现自己无法控制事态的开展，那 么你最好想方法离开当前的工程。也许在同一个单位能找到 更好的工程，或者干脆离开现在的单位。反正去是上策。此 时，已经不是告诉别人如何运行工程的时候了。如果你粘在工程上了，或者正等着走人，那你也不妨换 个看问题的角度。就当你在长经验吧。比方说，你能从现状中获得什么？如果得到授权你将采取什么行动改变现

10、状？将 来你该如何防止撞上这样的工程？从当前工程进展中学到的 知识和掌握的经验必定能在你着手的将来工程上给你带来莫 大的帮助。仅仅是个开始以上三个问题主要与业务和规划有关，但工程窘迫的迹象 并不止于此。接下来，我们将继续讨论失败工程中涉及用户 和工程经理的四个因素，并讨论这些因素如何给你一个工程 苦恼的警告。个因素篇总有一些工程会最终获得成功，可是，相当大数量的项 目却没这么好的命。如果你不幸遭遇到这样的处境，在事情 恶化到不可收拾之前你如何知道工程遇到危险了呢？在项 目遇险的三个信号一文里，谈到前景不妙的某些工程时， 我们已经针对和业务有关的迹象做了阐述。接下来，我们继 续探讨一些牵扯到工程

11、人员的危险迹象，它们大致上可以表 现为4种预警信号。导致工程失败的大局部原因不在于技术而在于同工程有 关的人和过程，认为到这些更具“软性”的问题是相当重要 的。具体地说，其原因同用户和工程发起人以及缺乏开发人 员之间的交流有关（改变管理和工作报告）。如果你发现自 己涉及的工程已经出现这样的迹象，那就说明工程正在滑向 失败的边缘了。因素#1:你的客户或用户组不跟你说话或者客户不跟你沟通，只能说明情况不好。这意味着他们 没有多少热情。不过也可能说明业务组太专注于具体工作或 者太忙而没有时间配合你，也就是说。如果是这样的话，那么这个工程将走向灾难。为了成功地实现这个工程，你必须 与客户和用户合作。缺

12、乏用户的参与只能意味着用户抗拒变动。我们知道,所谓的“变动管理”，就其全部领域而言就是建立在赢得最 终用户的支持以及接受新系统和过程的基础之上。这一方面 不应该与被用来管理工程范围的变动控制过程相混淆。变动 管理不在这篇文章所涉及的范围之内。但我们必须清楚地认 识到，系统要想得到有效的实现就必须把用户包含进来。其他原因也可能造成客户或用户缺乏参与精神。比方， 具体的业务决定了工程不得不取消或者实现一个不同的解决 方案。工程赞助者可能让用户远离工程，原因是系统实现之 日就是他们失业之时。任何工程都需要获取客户或用户的输入信息。没有它，系 统需求和设计就相当于在真空中呼吸。最终的解决方案完全 不能

13、满足业务需求。显然，如果你的客户或用户没有和你一起工作。你的麻烦 来了。因素#2：工程发起人效率低或者角色不明确拥有一个好的工程发起人是工程成功交付的关键因素。他 或她为工程目标的焦点做出贡献，并为团队清除主要的绊脚 石，尤其是从公司政治的角度。工程发起人必须有排除障碍的能力，在利益冲突的情况下 必须有解决问题的权利。他们还需要做出坚定的决定来支持 开发团队。如果没有明确的工程发起人，开发过程中的各种阻碍必然 会影响工程的进度。公司政治也将开始告诉团队和工作。项 目发起人离开公司会产生很多问题。保荐人为什么离职？他 或她是被迫逃跑的吗？赞助商的政治对手会试图阻止该工程 或改变其范围吗？你的职业

14、生涯会受到这些政敌的影响吗?也许你根本不打算留在这里，但你要出丑。因素#3：没有管理变动的机制 我们都知道，工程发生变动是不可防止，管理工程的变动非常重要。优秀的变动控制过程并难于管理，但是它们确 实需要对细节保持关注。高效的变动控制要求同客户或软件 解决方案的商务属主密切合作。不幸的是，一些工程仍然没有管理变更的过程。要么是项 目的范围不明确，要么是没有讨论变更控制，要么是客户或 企业主根据自己的意愿不断地变更解决方案。没有变更控制 过程就不可能准确地评估一个工程，因为解决方案的规模是 不断变化的。此外，变更通常会导致一些重复性的工作，从 而进一步延迟开发过程，并使工程团队失去动力。记住，客

15、户不是变动的唯一来源。有时团队自身也能引起范围的变动。毕竟，团队成员也是人，而人总会犯错误 的。团队的成员可能听说或“假设”解决方案因客户的实际 要求而发生了变动。另外还有一种可能，那就是工程需求比 较含糊，因此团队成员从不同方面对其进行解释。或者，团 队成员可能无意中创造出一个相比客户需求更漂亮或更复杂 的解决方案。这就是所谓的“镀金”操作。如果你的团队没有实施变革策略，你应该问为什么。如果 找不到答案，就要警惕了。工程很可能失去控制，失败的风 险大大增加。因素#4：没有准确的工作报告准确的工作报告是工程的生存之源。这些报告向负责人报 告相关信息，并提供有效的机制来确定是否采取正确的措 施。

16、准确的工作报告还可以起到记分卡的作用，可以显示项 目的计划完成情况。所有工程都需要工作报告。为什么工程绝对离不开工作报告呢？主要有两个原因： 工程经理需要认识到工程的需求，或者工作不妙以至于工程 经理决定干脆啥也不说了。在这两个原因之中，后者可能更 坏。如果某个工程落在了既定目标之后或者超出了预算而有 没有上报，显然这样的工程不如取消。如果你的工程缺少工作报告，我觉得没必要找原因。你跑 得很快。工程陷入麻烦该怎么办?如果你不是工程经理，对于濒临失败的工程，你只能束手 无策。然而，如果你确定这个工程遇到了麻烦，那么你应该 采取一些行动。如果你的用户拒绝参与工程，或者没有给你足够的时间来 运行工程

17、，那么你应该与工程的用户进行公开对话。虽然可 能救不了工程，但也不会对工程造成伤害。找其他可以转的 工程（反正比你的好）。对了，不要到处说为什么离开现在的 工程。完成后，每个人都会认为你采取了正确的行动。如果 事情很糟糕，请调用其他公司的工程。如果你坚持一个一两年就能完成的工程，无论是身体上、 精神上还是专业上，都不会给你带来任何好处。现在就采取 行动。如果你救不了工程，至少救你自己。八个信号篇作为工程经理，当你面对成堆的Microsoft Project X作任务报告时，想到已经花了好几个小时陷入在扯不清、说 不明的工程工作会议的泥沼之内，也许这是你感觉最令人恼 火和沮丧的时刻。然而，像这样痛苦的会议并不仅仅意味着失败感。他们的 本质问题可能隐藏的更深，这些问题最终会毁掉你经手的项 目。在这里我想和你一起分析和理解工程即将陷入困境的一 些迹象：1、没有引人注目的业务案例。那种“超酷”的Flash网站在增加业务收入方面的作用值得怀疑。站在增加业务收入方面的作用值得怀疑。2、自作主张地编写代码。如果你不同意业务需求或系统规范，你怎么知 道所交付的工作或规范是最新的？实际上你不可能知道。3、没有工程规划。这是针对工程经理的。比方说，通