在你的職業(yè)生涯里，總有些時候需要你當(dāng)機立斷地終結(jié)一個失敗的開發(fā)項目。當(dāng)然，那是我們希望避免出現(xiàn)的結(jié)果。從好的方面看失敗會令人沮喪，從壞的方面看項目的完蛋或許會威脅到你的職業(yè)安全性了。如果你能采取行動拯救一個項目，那么你可能有機會影響項目的成敗。然而，除非你是項目經(jīng)理，否則你只能束手無策。不過，你倒可以想法了解迫近的問題以便尋找機會逃跑。
這篇文章闡述了3個同業(yè)務(wù)有關(guān)的預(yù)警信號，希望它們能有助于你看清項目是否在走向崩潰。雖然這些總結(jié)并不太具備科學(xué)意義上的準(zhǔn)確性，但是，這些跡象能為你提供一些早期警告。而且，盡管你無法拯救項目但你或許能通過這些警示拯救你自己。在文章的末尾還提出了一些建議性的應(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)什么特定的目標(biāo)，而且有能力達到自己需要實現(xiàn)的目標(biāo)。另外還有一種可能性，那是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)當(dāng)具備相應(yīng)的項目計劃。項目計劃對那些項目決策人來說是非常必要的交流手段，項目計劃為項目的進展以及確定需要進一步完成的其他工作提供了指導(dǎo)。
有一種說法稱不需要告訴有關(guān)開發(fā)人員具體的計劃內(nèi)容；他們只需要知道做什么可以。這種看法對只有一個人的項目隊伍來說管用，但要做大事站不住腳了。開發(fā)人員確實需要接受計劃的指導(dǎo)。他們想要知道什么任務(wù)排在前面。他們不想猜測哪些東西是重要的。
僅僅有了一個計劃還是不夠的：計劃必須跟隨項目的發(fā)展保持新狀態(tài)。舉個例子吧，有些項目剛開始的時候房間里貼滿了五花八門的甘特圖和波特圖，結(jié)果幾個月乃至數(shù)年過去了這些圖表還是老樣子放在那里，沒有任何變化。這可不是一個當(dāng)前計劃。為了讓計劃與時俱進，項目計劃必須反映實際完成的工作，同時還要預(yù)計將要完成的工作。計劃更新的頻率倒不至于達到每周一次的程度，但也不能低于每兩周一次。計劃應(yīng)該準(zhǔn)確地反映完成項目的時間和開銷。只有在這樣的情況下才可以說計劃保持在新的狀態(tài)。
過于頻繁變更的計劃同過期的計劃一樣令人恐懼。我曾經(jīng)見過這樣的項目計劃，該項目計劃每周都要修改，結(jié)果把項目的階段終止日期超出了一周的范圍。計劃每周都在更新，但項目工程仍然失去了控制。
對策：如果沒有公開的項目計劃你無論如何得趕快弄出一個來。如果你被告知，因為信息的機密性你不能查閱項目計劃，那么，你不妨把這一事件看做一個嚴(yán)重的警示跡象。除非你在開發(fā)新一代的原子彈，否則秘密項目計劃根本沒有存在的道理。保持信息的隱秘通常意味著管理層知道項目出了問題，他們正試著把問題掩蓋起來。
一定要保證計劃常新而且還得具有合理的更新間隔。它不該是個不斷變動的目標(biāo)，但它一定得是新的。如果你不能保證項目計劃的新狀態(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)不是告訴某人該如何運做項目的時候了。
如果你粘在項目上了，或者正等著走人，那你也不妨換個看問題的角度。當(dāng)你在長經(jīng)驗吧。比方說，你能從現(xiàn)狀中獲得什么？如果得到授權(quán)你將采取什么行動改變現(xiàn)狀？將來你該如何避免撞上這樣的項目？從當(dāng)前項目進展中學(xué)到的知識和掌握的經(jīng)驗必定能在你著手的將來項目上給你帶來莫大的幫助。
僅僅是個開始
