項目遇險的3個問題4個因素和8個信號

1、工程遇險的3個問題4個因素和8個信號在你的職業(yè)生涯中，總有需要主動結(jié)束一個失敗的開發(fā)項 目的時候。當(dāng)然，這是我們最想防止的。從積極的一面來 看，失敗會令人沮喪。從負面來看，工程的完成可能會威脅 到你的職業(yè)平安。如果你能采取行動拯救一個工程，那么你 就有機會影響這個工程的成敗。但是，除非你是工程經(jīng)理， 否那么你無能為力。但是，你可以試著去理解即將發(fā)生的問 題，以便尋找逃避的機會。這篇文章闡述了 3個同業(yè)務(wù)有關(guān)的預(yù)警信號，希望它們 能有助于你看清工程是否在走向崩潰。雖然這些總結(jié)并不太 具備科學(xué)意義上的準確性，但是，這些跡象能為你提供一些 早期警告。而且，盡管你無法拯救工程但你或許能通過這些 警示拯

2、救你自己。在文章的末尾還提出了一些建議性的應(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ù)以外的其他原因而招致失敗的?？墒?，既然

3、不是 技術(shù)原因造成的工程失敗，那么又該是什么原因令這些工程8、在工程工作會議上，與會人員只會扯皮說“都是接 口問題”、“必須采取行動”以及“該找某某人”。當(dāng)然，就個人而言，這些病癥并不意味著你的工程會死 亡。但它們都是真正的紅色警報，需要你立即采取行動。如 果你的工程表現(xiàn)出以上8種病癥，那么你只能說你已經(jīng)在泰 坦尼克號上了。準備自救吧。失敗的呢？答案是工程所牽扯的人和工作過程。具有挖苦意 味的是，普通開發(fā)人員在處理技術(shù)問題的時候應(yīng)對有道但他 們在同其他人以及工作流程打交道的時候卻不是這樣。三個問題篇 問題#1 :缺乏有意義的商務(wù)案例 真的叫人很吃驚，有些工程從一開始就找不出有意義的商務(wù)案例來支

4、持它們。商務(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ù)案例的 情況下就紛紛上馬了。那爭先恐后的樣子就好象不奮力一搏

5、 就趕不上趟似的，的崩潰意味著商務(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)。

6、它們定 義了系統(tǒng)應(yīng)該和不應(yīng)該實現(xiàn)的任務(wù)。需求管理就是在整個工程周期之內(nèi)定義、記錄、追蹤以 及管理需求的過程。需求管理保證了最終的解決方案能夠滿 足用戶的需要。對策:密切關(guān)注你的需求管理過程。如果看起來沒有人負 責(zé)管理系統(tǒng)的需求，或者系統(tǒng)的需求是不斷變化的，那么你 可能就有麻煩了。問題#3 ：缺乏工程計劃有些工程竟然會在沒有工程計劃的情況下運做。這簡直就是不用圖紙造房子。每個工程都是一個事業(yè)，都應(yīng)當(dāng)具備 相應(yīng)的工程計劃。工程計劃對那些工程決策人來說是非常必 要的交流手段，工程計劃為工程的進展以及確定需要進一步 完成的其他工作提供了指導(dǎo)。有一種說法是，具體的計劃內(nèi)容不需要告訴開發(fā)商；他們 只需要知

7、道該做什么。這種觀點對于只有一個人的工程團隊 是行得通的，但是做大事是站不住腳的。開發(fā)人員確實需要 計劃的指導(dǎo)。他們想知道什么任務(wù)優(yōu)先。他們不想去猜想什 么才是最重要的。僅僅有計劃是不夠的:計劃必須跟上工程的開展。比方有 些工程剛開始的時候，房間里貼滿了各種甘特圖和波特圖。 結(jié)果幾個月甚至幾年后，這些圖表還是老樣子，沒有任何變 化。這不是當(dāng)前的計劃。為了使計劃保持最新，工程計劃必 須反映實際完成的工作，同時預(yù)測要完成的工作。更新計劃的頻率不要高到一周一次，但也不能少于兩周一次。該計劃 應(yīng)準確反映完成工程的時間和本錢。只有在這種情況下，我 們才能說這個計劃是最新的。經(jīng)常改變的計劃和那些過期的計劃

8、一樣可怕。我見過這樣 的工程計劃，每周都要修改，結(jié)果工程的階段終止日期超出 了一周的范圍。計劃每周更新，但工程仍然失控。對策:如果沒有公開的工程方案，反正你得拿出一個。如 果你被告知因為信息保密不能查閱工程計劃，那么你不妨把 這件事當(dāng)作一個嚴重的警訊。除非你在研發(fā)新一代原子彈， 否那么秘密工程計劃根本沒有存在的理由。對信息保密通常意 味著管理層知道工程有問題，他們試圖掩蓋它。確保計劃總是新的，并有一個合理的更新間隔。它不應(yīng)該 是一個不斷變化的目標(biāo)，但它必須是最新的。如果你不能保 證工程計劃的最新狀態(tài)，那么工程就會出問題。工程快完蛋了，我該怎么辦？你發(fā)現(xiàn)自己的工程已經(jīng)出現(xiàn)了以上一個或者多個預(yù)警信

9、 號嗎？對這個問題的回答取決于你的個人狀況。如果你感到 你能采取行動改變現(xiàn)狀，那么你一定要立即行動。同工程經(jīng) 理、顧客或你隊伍中的其他成員對話。用一種就事論事、不 具威脅性的方式討論你所關(guān)心的問題。試著盡可能提出正面 意見?？纯茨隳芊窠o工程帶來轉(zhuǎn)機。如果工程瀕臨失敗，你發(fā)現(xiàn)自己無法控制事態(tài)的開展，那 么你最好想方法離開當(dāng)前的工程。也許在同一個單位能找到 更好的工程，或者干脆離開現(xiàn)在的單位。反正去是上策。此 時，已經(jīng)不是告訴別人如何運行工程的時候了。如果你粘在工程上了，或者正等著走人，那你也不妨換 個看問題的角度。就當(dāng)你在長經(jīng)驗吧。比方說，你能從現(xiàn)狀中獲得什么？如果得到授權(quán)你將采取什么行動改變現(xiàn)

10、狀？將 來你該如何防止撞上這樣的工程？從當(dāng)前工程進展中學(xué)到的 知識和掌握的經(jīng)驗必定能在你著手的將來工程上給你帶來莫 大的幫助。僅僅是個開始以上三個問題主要與業(yè)務(wù)和規(guī)劃有關(guān)，但工程窘迫的跡象 并不止于此。接下來，我們將繼續(xù)討論失敗工程中涉及用戶 和工程經(jīng)理的四個因素，并討論這些因素如何給你一個工程 苦惱的警告。個因素篇總有一些工程會最終獲得成功，可是，相當(dāng)大數(shù)量的項 目卻沒這么好的命。如果你不幸遭遇到這樣的處境，在事情 惡化到不可收拾之前你如何知道工程遇到危險了呢？在項 目遇險的三個信號一文里，談到前景不妙的某些工程時， 我們已經(jīng)針對和業(yè)務(wù)有關(guān)的跡象做了闡述。接下來，我們繼 續(xù)探討一些牽扯到工程

11、人員的危險跡象，它們大致上可以表 現(xiàn)為4種預(yù)警信號。導(dǎo)致工程失敗的大局部原因不在于技術(shù)而在于同工程有 關(guān)的人和過程，認為到這些更具“軟性”的問題是相當(dāng)重要 的。具體地說，其原因同用戶和工程發(fā)起人以及缺乏開發(fā)人 員之間的交流有關(guān)（改變管理和工作報告）。如果你發(fā)現(xiàn)自 己涉及的工程已經(jīng)出現(xiàn)這樣的跡象，那就說明工程正在滑向 失敗的邊緣了。因素#1:你的客戶或用戶組不跟你說話或者客戶不跟你溝通，只能說明情況不好。這意味著他們 沒有多少熱情。不過也可能說明業(yè)務(wù)組太專注于具體工作或 者太忙而沒有時間配合你，也就是說。如果是這樣的話，那么這個工程將走向災(zāi)難。為了成功地實現(xiàn)這個工程，你必須 與客戶和用戶合作。缺

12、乏用戶的參與只能意味著用戶抗拒變動。我們知道,所謂的“變動管理”，就其全部領(lǐng)域而言就是建立在贏得最 終用戶的支持以及接受新系統(tǒng)和過程的基礎(chǔ)之上。這一方面 不應(yīng)該與被用來管理工程范圍的變動控制過程相混淆。變動 管理不在這篇文章所涉及的范圍之內(nèi)。但我們必須清楚地認 識到，系統(tǒng)要想得到有效的實現(xiàn)就必須把用戶包含進來。其他原因也可能造成客戶或用戶缺乏參與精神。比方， 具體的業(yè)務(wù)決定了工程不得不取消或者實現(xiàn)一個不同的解決 方案。工程贊助者可能讓用戶遠離工程，原因是系統(tǒng)實現(xiàn)之 日就是他們失業(yè)之時。任何工程都需要獲取客戶或用戶的輸入信息。沒有它，系 統(tǒng)需求和設(shè)計就相當(dāng)于在真空中呼吸。最終的解決方案完全 不能

13、滿足業(yè)務(wù)需求。顯然，如果你的客戶或用戶沒有和你一起工作。你的麻煩 來了。因素#2：工程發(fā)起人效率低或者角色不明確擁有一個好的工程發(fā)起人是工程成功交付的關(guān)鍵因素。他 或她為工程目標(biāo)的焦點做出貢獻，并為團隊清除主要的絆腳 石，尤其是從公司政治的角度。工程發(fā)起人必須有排除障礙的能力，在利益沖突的情況下 必須有解決問題的權(quán)利。他們還需要做出堅定的決定來支持 開發(fā)團隊。如果沒有明確的工程發(fā)起人，開發(fā)過程中的各種阻礙必然 會影響工程的進度。公司政治也將開始告訴團隊和工作。項 目發(fā)起人離開公司會產(chǎn)生很多問題。保薦人為什么離職？他 或她是被迫逃跑的嗎？贊助商的政治對手會試圖阻止該工程 或改變其范圍嗎？你的職業(yè)

14、生涯會受到這些政敵的影響嗎?也許你根本不打算留在這里，但你要出丑。因素#3：沒有管理變動的機制 我們都知道，工程發(fā)生變動是不可防止，管理工程的變動非常重要。優(yōu)秀的變動控制過程并難于管理，但是它們確 實需要對細節(jié)保持關(guān)注。高效的變動控制要求同客戶或軟件 解決方案的商務(wù)屬主密切合作。不幸的是，一些工程仍然沒有管理變更的過程。要么是項 目的范圍不明確，要么是沒有討論變更控制，要么是客戶或 企業(yè)主根據(jù)自己的意愿不斷地變更解決方案。沒有變更控制 過程就不可能準確地評估一個工程，因為解決方案的規(guī)模是 不斷變化的。此外，變更通常會導(dǎo)致一些重復(fù)性的工作，從 而進一步延遲開發(fā)過程，并使工程團隊失去動力。記住，客

15、戶不是變動的唯一來源。有時團隊自身也能引起范圍的變動。畢竟，團隊成員也是人，而人總會犯錯誤 的。團隊的成員可能聽說或“假設(shè)”解決方案因客戶的實際 要求而發(fā)生了變動。另外還有一種可能，那就是工程需求比 較含糊，因此團隊成員從不同方面對其進行解釋。或者，團 隊成員可能無意中創(chuàng)造出一個相比客戶需求更漂亮或更復(fù)雜 的解決方案。這就是所謂的“鍍金”操作。如果你的團隊沒有實施變革策略，你應(yīng)該問為什么。如果 找不到答案，就要警惕了。工程很可能失去控制，失敗的風(fēng) 險大大增加。因素#4：沒有準確的工作報告準確的工作報告是工程的生存之源。這些報告向負責(zé)人報 告相關(guān)信息，并提供有效的機制來確定是否采取正確的措 施。

16、準確的工作報告還可以起到記分卡的作用，可以顯示項 目的計劃完成情況。所有工程都需要工作報告。為什么工程絕對離不開工作報告呢？主要有兩個原因： 工程經(jīng)理需要認識到工程的需求，或者工作不妙以至于工程 經(jīng)理決定干脆啥也不說了。在這兩個原因之中，后者可能更 壞。如果某個工程落在了既定目標(biāo)之后或者超出了預(yù)算而有 沒有上報，顯然這樣的工程不如取消。如果你的工程缺少工作報告，我覺得沒必要找原因。你跑 得很快。工程陷入麻煩該怎么辦?如果你不是工程經(jīng)理，對于瀕臨失敗的工程，你只能束手 無策。然而，如果你確定這個工程遇到了麻煩，那么你應(yīng)該 采取一些行動。如果你的用戶拒絕參與工程，或者沒有給你足夠的時間來 運行工程

17、，那么你應(yīng)該與工程的用戶進行公開對話。雖然可 能救不了工程，但也不會對工程造成傷害。找其他可以轉(zhuǎn)的 工程（反正比你的好）。對了，不要到處說為什么離開現(xiàn)在的 工程。完成后，每個人都會認為你采取了正確的行動。如果 事情很糟糕，請調(diào)用其他公司的工程。如果你堅持一個一兩年就能完成的工程，無論是身體上、 精神上還是專業(yè)上，都不會給你帶來任何好處。現(xiàn)在就采取 行動。如果你救不了工程，至少救你自己。八個信號篇作為工程經(jīng)理，當(dāng)你面對成堆的Microsoft Project X作任務(wù)報告時，想到已經(jīng)花了好幾個小時陷入在扯不清、說 不明的工程工作會議的泥沼之內(nèi)，也許這是你感覺最令人惱 火和沮喪的時刻。然而，像這樣痛苦的會議并不僅僅意味著失敗感。他們的 本質(zhì)問題可能隱藏的更深，這些問題最終會毀掉你經(jīng)手的項 目。在這里我想和你一起分析和理解工程即將陷入困境的一 些跡象：1、沒有引人注目的業(yè)務(wù)案例。那種“超酷”的Flash網(wǎng)站在增加業(yè)務(wù)收入方面的作用值得懷疑。站在增加業(yè)務(wù)收入方面的作用值得懷疑。2、自作主張地編寫代碼。如果你不同意業(yè)務(wù)需求或系統(tǒng)規(guī)范，你怎么知 道所交付的工作或規(guī)范是最新的？實際上你不可能知道。3、沒有工程規(guī)劃。這是針對工程經(jīng)理的。比方說，通