風(fēng)險管理三個問題

風(fēng)險管理三個問題篇

三個問題篇

在你的職業(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)。大多數(shù)工程都是因為技術(shù)以外的其他原因而招致失敗的。可是，既然不是技術(shù)原因造成的工程失敗，那么又該是什么原因令這些工程失敗的呢？答案是工程所牽扯的人和工作過程。具有挖苦意味的是，普通開發(fā)人員在處理技術(shù)問題的時候應(yīng)對有道但他們在同其他人以及工作流程打交道的時候卻不是這樣。

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

真的叫人很吃驚，有些工程從一開始就找不出有意義的商務(wù)案例來支持它們。商務(wù)案例很重要，因為它為工程提供了根底。商務(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ù)實踐回歸原來的根底，這其中自然也包括商務(wù)案例。

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

問題#2：沒有獲得同意的需求或系統(tǒng)標準

缺乏需求確實是一件非常危險的事情。挑戰(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ù)排在前面。他們不想猜測哪些東西是最重要的。

僅僅有了一個方案還是不夠的：方案必須跟隨工程的開展保持最新狀態(tài)。舉個例子吧，有些工程剛開始的時候房間里貼滿了五花八門的甘特圖和波特圖，結(jié)果幾個月乃至數(shù)年過去了這些圖表還是老樣子放在那里，沒有任何變化。這可不是一個當前方案。為了讓方案與時俱進，工程方案就必須反映實際完成的工作，同時還要預(yù)計將要完成的工作。方案更新的頻率倒不至于到達每周一次的程度，但也不能低于每兩周一次。方案應(yīng)該準確地反映完成工程的時間和開銷。只有在這樣的情況下才可以說方案保持在最新的狀態(tài)。

過于頻繁變更的方案同過期的方案一樣令人恐懼。我曾經(jīng)見過這樣的工程方案，該工程方案每周都要修改，結(jié)果把工程的階段終止日期超出了一周的范圍。方案每周都在更新，但工程工程仍然失去了控制。

對策：如果沒有公開的工程方案你無論如何得趕快弄出一個來。如果你被告知，因為信息的機密性你不能查閱工程方案，那么，你不妨把這一事件看做一個嚴重的警示跡象。除非你在開發(fā)新一代的原子彈，否那么秘密工程方案根本沒有存在的道理。保持信息的隱秘通常意味著管理層知道工程出了問題，他們正試著把問題掩蓋起來。

一定要保證方案常新而且還得具有合理的更新間隔。它不該是個不斷變動的目標，但它一定得是最新的。如果你不能保證工程方案的最新狀態(tài)，那么工程會出問題的。

工程快完蛋了，我該怎么辦？

你發(fā)現(xiàn)自己的工程已經(jīng)出現(xiàn)了以上一個或者多個預(yù)警信號嗎？對這個問題的答復(fù)取決于你的個人狀況。如果你感到你能采取行動改變現(xiàn)狀，那么你一定要立即行動。同工程經(jīng)理、顧客或你隊伍中的其他成員對話。用一種就事論事、不具威脅性的方式討論你所關(guān)心的問題。試著盡可能提出正面意見?？纯茨隳芊窠o工程帶來轉(zhuǎn)機。

如果工程瀕于失敗而且你發(fā)現(xiàn)自己沒有方法控制事態(tài)的開展，那么你最好想方法離開現(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ù)量的工程卻沒這么好的命。如果你不幸遭遇到這樣的處境，在事情惡化到不可收拾之前你如何知道工程遇到危險了呢？接下來，我們繼續(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)和過程的根底之上。這一方面不應(yīng)該與被用來管理工程范圍的變動控制過程相混淆。變動管理不在這篇文章所涉及的范圍之內(nèi)。但我們必須清楚地認識到，系統(tǒng)要想得到有效的實現(xiàn)就必須把用戶包含進來。

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

任何工程都需要獲得客戶或用戶的輸入信息，沒有它，系統(tǒng)需求和設(shè)計就等于在真空中呼吸。最終的解決方案根本不可能滿足業(yè)務(wù)需要。

如果你的客戶或用戶沒有在工程上與你一道工作，顯然。你的麻煩來了。

問題#2：工程發(fā)起人效率低或者角色不明確

有一位良好的工程發(fā)起人是工程成功交付的一個關(guān)鍵因素。他或她有助于工程目標的集中，為團隊搬走主要的絆腳石，從企業(yè)政治上講尤其如此。

工程發(fā)起人必須有去除障礙的能力，他們一定得有權(quán)力在利益發(fā)生沖突的情況下解決問題。他們還需要做出堅決的決策支持開發(fā)隊伍。

如果工程沒有明確的發(fā)起人，在開發(fā)過程中那些形形色色的障礙就必然會影響工程的進展。企業(yè)政治也會開始給團隊和工作說事。在工程發(fā)起人離開公司的情況下更會產(chǎn)生很多的問題。發(fā)起人為什么要離開公司？他或她是被迫出走的嗎？發(fā)起人的政敵會試圖停止工程或者改變其范圍嗎？你的職業(yè)將會受到這些政敵的影響嗎？也許你壓根就不打算繼續(xù)逗留在這里非要弄出個子丑寅卯。

問題#3：沒有管理變動的機制

我們都知道，工程發(fā)生變動是不可防止，管理工程的變動非常重要。優(yōu)秀的變動控制過程并難于管理，但是它們確實需要對細節(jié)保持關(guān)注。高效的變動控制要求同客戶或軟件解決方案的商務(wù)屬主密切合作。

不幸的是，某些工程仍然在沒有管理變動的過程的情況下運轉(zhuǎn)。要不就是工程的范圍模糊不清，或者不討論變動控制，或者客戶或業(yè)務(wù)主人不斷地根據(jù)自己的意愿改變解決方案。沒有變動控制過程的工程是不可能得到準確估計的，這是因為解決方案的規(guī)?？傇诓粩嗟刈儎又?。另外，變動通常會導(dǎo)致某些重復(fù)性的工作，從而進一步推遲了開發(fā)過程令工程團隊失去動力。

記住，客戶不是變動的唯一來源。有時團隊自身也能引起范圍的變動。畢竟，團隊成員也是人，而人總會犯錯誤的。團隊的成員可能聽說或“假設(shè)〞解決方案因客戶的實際要求而發(fā)生了變動。另外還有一種可能，那就是工程需求比較模糊，因此團隊成員從不同方面對其進行解釋?；蛘?，團隊成員可能無意中創(chuàng)造出一個相比客戶需求更漂亮或更復(fù)雜的解決方案。這就是所謂的“鍍金〞操作。

如果你所在的團隊沒有執(zhí)行變動策略，你應(yīng)該問一下原因何在。如果你找不出答案，那可要警惕了，工程很可能正在失去控制而且失敗的風(fēng)險顯著增大了。

問題#4：沒有準確的工作報告

準確的工作報告是工程的活命源。這些報告把有關(guān)的信息報告給負責(zé)人，同時提供一種有效的機制來確定是否采取正確的行動。準確的工作報告還能起到記分卡的作用，可以顯示出工程的方案完成情況。所有的工程都需要工作報告。

為什么工程絕對離不開工作報告呢？主要有兩個原因：工程經(jīng)理需要認識到工程的需求，或者工作不妙以至于工程經(jīng)理決定干脆啥也不說了。在這兩個原因之中，后者可能更壞。如果某個工程落在了既定目標之后或者超出了預(yù)算而有沒有上報，顯然這樣的工程不如取消。

如果你的工程缺乏工作報告，我看也沒什么必要找出原因了。你趕快跑吧。

工程陷入麻煩該怎么辦？

如果你不是工程經(jīng)理，那么你對瀕臨失敗的工程只能無可奈何。然而，如果你確定工程已經(jīng)遇到麻煩了那么你應(yīng)該采取一些行動。

如果你的用戶拒絕參與工程，或者沒有給你足夠的工程運做時間，那么你應(yīng)該同工程的用戶方做一番開誠布公的對話。雖說不一定就能拯救工程但也不至于給工程造成傷害。

尋找可以轉(zhuǎn)移的其他工程〔反正比你現(xiàn)在的好一些〕。順便說一句，別到處說你為什么離開當前的工程。事成之后，每個人都會認為你采取了正確的行動。

如果事情糟透了，請打其他公司工程的主意吧。

如果你一直堅守在某個一兩年之后就瀕于完蛋的工程之內(nèi)，它對你的身體、精神或職業(yè)都不會帶來半點好處?，F(xiàn)在就采取行動。如果你不能拯救工程至少得拯救你自己。

八個信號篇

作為工程經(jīng)理，當你面對成堆的MicrosoftProject工作任務(wù)報告時，想到已經(jīng)花了好幾個小時陷入在扯不清、說不明的工程工作會議的泥沼之內(nèi)，也許這是你感覺最令人惱火和沮喪的時刻。

可是，像這樣的痛苦會議還不僅僅意味著一種失敗感。它們的本質(zhì)問題可能掩蓋得更深，這些問題會最終消滅你經(jīng)手的工程。這里我想與你一道分析和了解工程即將陷入困境的一些跡象：

沒有引人注目的業(yè)務(wù)案例。那種“超酷〞的Flash網(wǎng)站在增加業(yè)務(wù)收入方面的作用值得疑心。

自作主張地編寫代碼。如果你不同意業(yè)務(wù)需求或系統(tǒng)標準，你怎么知道所交付的工作或標準是最新的？實際上你不可能知道。

沒有工程規(guī)劃。這是針對工程經(jīng)理的。比方說，通過電子郵件交流的內(nèi)容儼然成為系統(tǒng)的功能標準。這簡直是沒有藍圖就造房子。

你和你的顧客各說各話。發(fā)生這種情況時，你必須消除咒罵工程發(fā)起人家庭成員的欲望〔比方誰誰母親的〕。

工程發(fā)起人生活在“洞穴〞里。當你需要額外資源時就知道這將造成多大的損害了！當你的老板要求給工程