在你的職業(yè)生涯里，總有些時候需要你當機立斷地終結(jié)一個失敗的開發(fā)項目。當然，那是我們希望避免出現(xiàn)的結(jié)果。從好的方面看失敗會令人沮喪，從壞的方面看項目的完蛋或許會威脅到你的職業(yè)安全性了。如果你能采取行動拯救一個項目，那么你可能有機會影響項目的成敗。然而，除非你是項目經(jīng)理，否則你只能束手無策。不過，你倒可以想法了解迫近的問題以便尋找機會逃跑。

　　這篇文章闡述了3個同業(yè)務(wù)有關(guān)的預(yù)警信號，希望它們能有助于你看清項目是否在走向崩潰。雖然這些總結(jié)并不太具備科學(xué)意義上的準確性，但是，這些跡象能為你提供一些早期警告。而且，盡管你無法拯救項目但你或許能通過這些警示拯救你自己。在文章的末尾還提出了一些建議性的應(yīng)對措施，這樣一來，萬一你發(fā)現(xiàn)自己正身陷項目失敗的泥沼，那么你好歹可以采取相應(yīng)的合理行動自救。 概述

　　針對成功的IT項目的統(tǒng)計報告不具備太大的意義。根據(jù)Standish商業(yè)研究公司的一份報告，將近三分之一的信息系統(tǒng)項目在終完成之前都被取消了。另外，在所有的項目中幾乎有一半左右會超出其預(yù)算。

　　令人驚訝的是，項目失敗的原因很少同技術(shù)有關(guān)。在軟件管理手冊Peopleware: Productive Projects and Team一書中，作者之一Tom Demarco提醒讀者注意，大多數(shù)項目都是因為技術(shù)以外的其他原因而招致失敗的�？墒�，既然不是技術(shù)原因造成的項目失敗，那么又該是什么原因令這些項目失敗的呢？答案是項目所牽扯的人和工作過程。具有諷刺意味的是，普通開發(fā)人員在處理技術(shù)問題的時候應(yīng)對有道但他們在同其他人以及工作流程打交道的時候卻不是這樣。

問題 # 1 ：缺乏有意義的商務(wù)案例

　　真的叫人很吃驚，有些項目從一開始找不出有意義的商務(wù)案例來支持它們。商務(wù)案例很重要，因為它為項目提供了基礎(chǔ)。商務(wù)案例應(yīng)該能提出效益分析，同時還能考慮到商業(yè)風(fēng)險和項目之外事件的影響。機構(gòu)會采用商務(wù)案例把它們有限的資源劃分出優(yōu)先級別從而為其提供大回報。 這樣說來，在沒有商務(wù)案例的情況之下，一個項目該如何起步呢？這也是可能的，因為項目的商業(yè)屬主也許僅僅是需要實現(xiàn)什么特定的目標，而且有能力達到自己需要實現(xiàn)的目標。另外還有一種可能性，那是IT機構(gòu)認為商業(yè)單位需要它因此它們自己先創(chuàng)建出來再說。

　　近兩年，因為許多人相信他們必須開發(fā)某些項目來維持競爭力，所以好多同Web關(guān)聯(lián)的項目在不存在商務(wù)案例的情況下紛紛上馬了。那爭先恐后的樣子好象不奮力一搏趕不上趟似的，“.com”的崩潰意味著商務(wù)實踐回歸原來的基礎(chǔ)，這其中自然也包括商務(wù)案例。

　　對策：探詢你目前著手的項目是否受到了商務(wù)案例的支持。找一份商務(wù)案例來仔細閱讀它。你所在項目的商業(yè)動力是什么？這一商務(wù)案例符合邏輯而且可理解嗎？該商務(wù)案例存在怎樣的前天條件？其風(fēng)險是什么？什么外部因素會影響商務(wù)案例？如果你無法為自己的項目找到可理解、有意義的商務(wù)案例，那么你得知道為什么沒有開發(fā)出有關(guān)的商務(wù)案例。

問題 #2 ：沒有獲得同意的需求或系統(tǒng)規(guī)范

　　缺乏需求確實是一件非常危險的事情。在Standish的報告里，挑戰(zhàn)項目正常運行的三個常見因素都和系統(tǒng)需求有關(guān)。系統(tǒng)需求能給出將要創(chuàng)建的系統(tǒng)的大小和結(jié)構(gòu)。它們定義了系統(tǒng)應(yīng)該和不應(yīng)該實現(xiàn)的任務(wù)。

　　需求管理是在整個項目周期之內(nèi)定義、記錄、追蹤以及管理需求的過程。需求管理保證了終的解決方案能夠滿足用戶的需要。

　　對策：密切注意你的需求管理過程。如果看起來沒人負責(zé)管理系統(tǒng)的需求，或系統(tǒng)的需求老是在變，那么你可能會遇到麻煩了。

問題 #3 ：缺乏項目計劃

　　有些項目竟然會在沒有項目計劃的情況下運做。這簡直是不用圖紙造房子。每個項目都是一個事業(yè)，都應(yīng)當具備相應(yīng)的項目計劃。項目計劃對那些項目決策人來說是非常必要的交流手段，項目計劃為項目的進展以及確定需要進一步完成的其他工作提供了指導(dǎo)。 有一種說法稱不需要告訴有關(guān)開發(fā)人員具體的計劃內(nèi)容；他們只需要知道做什么可以。這種看法對只有一個人的項目隊伍來說管用，但要做大事站不住腳了。開發(fā)人員確實需要接受計劃的指導(dǎo)。他們想要知道什么任務(wù)排在前面。他們不想猜測哪些東西是重要的。

　　僅僅有了一個計劃還是不夠的：計劃必須跟隨項目的發(fā)展保持新狀態(tài)。舉個例子吧，有些項目剛開始的時候房間里貼滿了五花八門的甘特圖和波特圖，結(jié)果幾個月乃至數(shù)年過去了這些圖表還是老樣子放在那里，沒有任何變化。這可不是一個當前計劃。為了讓計劃與時俱進，項目計劃必須反映實際完成的工作，同時還要預(yù)計將要完成的工作。計劃更新的頻率倒不至于達到每周一次的程度，但也不能低于每兩周一次。計劃應(yīng)該準確地反映完成項目的時間和開銷。只有在這樣的情況下才可以說計劃保持在新的狀態(tài)。 過于頻繁變更的計劃同過期的計劃一樣令人恐懼。我曾經(jīng)見過這樣的項目計劃，該項目計劃每周都要修改，結(jié)果把項目的階段終止日期超出了一周的范圍。計劃每周都在更新，但項目工程仍然失去了控制。

　　對策：如果沒有公開的項目計劃你無論如何得趕快弄出一個來。如果你被告知，因為信息的機密性你不能查閱項目計劃，那么，你不妨把這一事件看做一個嚴重的警示跡象。除非你在開發(fā)新一代的原子彈，否則秘密項目計劃根本沒有存在的道理。保持信息的隱秘通常意味著管理層知道項目出了問題，他們正試著把問題掩蓋起來。 一定要保證計劃常新而且還得具有合理的更新間隔。它不該是個不斷變動的目標，但它一定得是新的。如果你不能保證項目計劃的新狀態(tài)，那么項目會出問題的。

項目快完蛋了，我該怎么辦？

　　你發(fā)現(xiàn)自己的項目已經(jīng)出現(xiàn)了以上一個或者多個預(yù)警信號嗎？對這個問題的回答取決于你的個人狀況。如果你感到你能采取行動改變現(xiàn)狀，那么你一定要立即行動。同項目經(jīng)理、顧客或你隊伍中的其他成員對話。用一種事論事、不具威脅性的方式討論你所關(guān)心的問題。試著盡可能提出正面意見�？纯茨隳芊窠o項目帶來轉(zhuǎn)機。 如果項目瀕于失敗而且你發(fā)現(xiàn)自己沒有辦法控制事態(tài)的發(fā)展，那么你好想辦法離開現(xiàn)在的項目。你也許能在同一家機構(gòu)內(nèi)找到一個好一些的項目，要不你干脆離開現(xiàn)在的單位算了。反正走為上策。到這份兒上已經(jīng)不是告訴某人該如何運做項目的時候了。

　　如果你粘在項目上了，或者正等著走人，那你也不妨換個看問題的角度。當你在長經(jīng)驗吧。比方說，你能從現(xiàn)狀中獲得什么？如果得到授權(quán)你將采取什么行動改變現(xiàn)狀？將來你該如何避免撞上這樣的項目？從當前項目進展中學(xué)到的知識和掌握的經(jīng)驗必定能在你著手的將來項目上給你帶來莫大的幫助。 僅僅是個開始

　　以上的3個問題主要牽扯到業(yè)務(wù)和計劃方面，但是，項目遇險的跡象還并不止于這些。接下來，我們將繼續(xù)討論在失敗的項目中涉及到用戶和項目主管人員的4個因素，討論下這些因素是如何給你提出項目遇險警告的。

四個因素篇

　　總有一些項目會終獲得成功，可是，相當大數(shù)量的項目卻沒這么好的命。如果你不幸遭遇到這樣的處境，在事情惡化到不可收拾之前你如何知道項目遇到危險了呢？在《項目遇險的三個信號》一文里，談到前景不妙的某些項目時，我們已經(jīng)針對和業(yè)務(wù)有關(guān)的跡象做了闡述。接下來，我們繼續(xù)探討一些牽扯到項目人員的危險跡象，它們大致上可以表現(xiàn)為4種預(yù)警信號。

　　導(dǎo)致項目失敗的大部分原因不在于技術(shù)而在于同項目有關(guān)的人和過程，認為到這些更具“軟性”的問題是相當重要的。具體地說，其原因同用戶和項目發(fā)起人以及缺乏開發(fā)人員之間的交流有關(guān)（改變管理和工作報告）。如果你發(fā)現(xiàn)自己涉及的項目已經(jīng)出現(xiàn)這樣的跡象，那表明項目正在滑向失敗的邊緣了。

問題#1：你的客戶或用戶組不跟你說話

　　客戶或用戶不和你交流只能說明情況不妙。這意味著他們幾乎毫無積極性。不過也可能說明業(yè)務(wù)組太關(guān)注于具體的工作或者太忙了，難以同你合作，這是說。如果正是那樣的情況，那么項目正在向災(zāi)難邁進了。你必須同客戶和用戶合作，這樣才能成功地實現(xiàn)項目。

　　缺乏用戶的參與只能意味著用戶抗拒變動。我們知道，所謂的“變動管理”，其全部領(lǐng)域而言是建立在贏得終用戶的支持以及接受新系統(tǒng)和過程的基礎(chǔ)之上。這一方面不應(yīng)該與被用來管理項目范圍的變動控制過程相混淆。變動管理不在這篇文章所涉及的范圍之內(nèi)。但我們必須清楚地認識到，系統(tǒng)要想得到有效的實現(xiàn)必須把用戶包含進來。

　　其他原因也可能造成客戶或用戶缺乏參與精神。比如，具體的業(yè)務(wù)決定了項目不得不取消或者實現(xiàn)一個不同的解決方案。項目贊助者可能讓用戶遠離項目，原因是系統(tǒng)實現(xiàn)之日是他們失業(yè)之時。