項目管理綜合管理：被劫持的項目

申請免費試用、咨詢電話：400-8352-114

為什么一本講項目管理的小說要以主人公被綁架開始？湯普金斯先生，這位愛打瞌睡的資深項目經(jīng)理，公司近期裁員的犧牲品，被綁架到一個完全陌生的國度，委以 一項近乎不可能的任務(wù)，開始一次奇異的、難以測度的冒險......這聽起來完全像一部卡夫卡式的荒誕小說，但其實卻是IT名著《最后期限》的開頭。
你會說，這只是制造懸念、吸引讀者的套路而已?？墒恰皯夷睢保局辉摪l(fā)生在那些存在風(fēng)險、需要膽魄和運氣的領(lǐng)域：間諜或是反間諜，高空救險，買彩票等 等，哪里有懸念，哪里就有危險，就有失敗甚至喪命的可能。為什么軟件開發(fā)項目會卷入一場懸念、一次歷險之中？“最后期限”，英文本來是 “deadline”，直譯就是“死線”，據(jù)說原本指的是監(jiān)獄里的最后一道界限，犯人一旦越過就格殺勿論——難道作者是以此象征開發(fā)者們頭上懸著的劍？難 道作者在暗示，軟件項目就很可能掙扎在這樣的生死界限上，很可能陷入“被劫持”的危險中？
　　從軟件行業(yè)之外的角度看，“項目”往往意味著規(guī)范的運作，甚至是“成功”的同義語。請設(shè)想一個建筑項目。不考慮款項拖欠和成本回收，單純從設(shè)計、施工的角 度來說，“失敗”的可能性相當小。如果讓外行想當然地推測，軟件項目很少與有形的“物質(zhì)材料”打交道，成功的概率應(yīng)該較建筑業(yè)更高。但是，任何略有經(jīng)驗的 軟件開發(fā)者都會明白我說的“風(fēng)險”對于軟件項目意味著的比例。讓我們援引業(yè)界公認的“硬數(shù)據(jù)”：作為軟件開發(fā)管理的權(quán)威、軟件項目研究專家，本書作者迪馬 可在他的另一部名著《人件》中談到，他們“跟蹤研究的所有項目中，大約有15%的項目徹底失敗。它們或者是被取消、或者夭折、或者延期、或者提交的產(chǎn)品從 來就沒有投入使用。對大項目來說成功的可能性更低。在持續(xù)了25 個工作年或者更長時間的項目中，足足有25%的項目沒能完成?！笔聦嵣?，《人件》第一章的標題就是“此時此刻，在世界的某處有一個項目正在失敗”。無怪乎 有一本項目管理指南叫《軟件項目生存手冊》——暗示著項目經(jīng)理需要皇家空軍飛行員般的逆境求生技巧，另一本則干脆叫《死亡之旅》，那意思是說，如果一個項 目經(jīng)理像那些興致勃勃的探險家一樣天真莽撞地走入這片未知的領(lǐng)地，那么等待他的命運不問可知。
　　那么，或許可以說，軟件項目從本質(zhì)上來講，首先并且總是處于危險之中。面對如此高的風(fēng)險，不少深謀遠慮的項目規(guī)劃者甚至?xí)駮械臏战鹚挂粯?，讓多個項 目組同時開發(fā)同一模塊，取最優(yōu)的結(jié)果（據(jù)我所知，這種實踐在日本軟件業(yè)相當普遍）。但是，還是有很多不走運的軟件項目，要么對此沒有足夠意識，要么無法負 擔(dān)大量人力，只有前仆后繼地被無名的力量所劫持，像卡夫卡小說中的K或是捐軀南極的斯各特船長那樣，在不歸路上“繼續(xù)向前走，向前越迷越深”。
　　一段航程的展望
　　我立刻意識到了自己過度悲觀的語調(diào)。雖然每次探險都肯定是“死亡之旅”，但顯然不是每支探險隊都有去無還。以著名的失敗者斯各特為例，與他們幾乎同時出發(fā) 的挪威人阿德蒙森探險隊就獲得了成功?；氐杰浖袠I(yè)，根據(jù)上面的數(shù)字，25%的失敗率雖然不能容忍，但是畢竟多數(shù)軟件項目確實還算得上走運。那么，成功的 秘訣和失敗的主因各是什么？如果我們把多年以來軟件項目成功、失敗的道理都總結(jié)出來，不就能在以后的航程中智珠在握，一帆風(fēng)順了嗎？
　　在純技術(shù)領(lǐng)域，確實已有不少論著致力于這樣的工作。很多專家發(fā)現(xiàn)大家總在重復(fù)相同的錯誤，進而總結(jié)出了軟件設(shè)計中的一些典型錯誤思路，并把它們稱為“反模 式”。對于一些具體的開發(fā)領(lǐng)域，比如Java，我們陸續(xù)地看到了名為“Java Pitfalls”、“Bitter Java”、“Bitter EJB”的專著出現(xiàn)，從書名就能讀出陷阱之危險、教訓(xùn)之苦澀。
　　而在軟件項目管理方面，如果也有這樣一部記錄成功的航線和沉船的位置的書該多好，我們不就也能據(jù)此把握航向、避開那些臭名昭著的礁石了嗎？我最初就是懷著 這樣的念頭開始讀《最后期限》。這本書也確實能起到這樣的作用。伴隨著我們的朋友湯普金斯在虛構(gòu)的“摩羅維亞國”的歷險，我也從一個個機智美妙的故事中學(xué) 到了不少Dos & DoNots——每章之后，都有一段以“湯普金斯日記”形式出現(xiàn)的總結(jié)，如果時間實在緊張，單單瀏覽一遍這些日記，你就能在工作劃分、人員配備、項目時間 計劃、測試、發(fā)布等等問題上收割很多真知灼見。
　　但是這樣足夠嗎？如果單憑熟記若干原則就能塑造一位項目經(jīng)理，那么何以項目管理人才還是眼下最稀缺的資源之一呢？事實上，讀完全書后，我感到自己最大的收 獲并非任何特定的管理秘訣，而恰恰是這樣一個認識：沒有任何單一的實踐或原則能夠確保一個軟件開發(fā)項目的成功，同樣，任何單一的缺陷也未必會將項目導(dǎo)向失 敗。就像湯普金斯的成功并非完全依靠本人經(jīng)驗，或者憑借哪個全能智者的指引，而應(yīng)歸功于多種因素的綜合作用和他麾下的眾多天才的建議，如果我們單純乞靈于 一個新方法，比如“測試先行”或“持續(xù)集成”，甚至，如果我們完全復(fù)制書中的所有提示，在下一個項目中取得成功的概率未必會有多少提高。同樣，書中的故事 也表明，即使你身旁總有一位“邪惡的貝洛克部長”似的超級決策者，你的項目也不一定就單單因此而滿盤皆輸。
　　這似乎是對Brooks提出的“沒有銀彈”定理的一次簡單擴充。不過我個人更愿意稱此為“軟件行業(yè)的多元決定論”。多元決定，意味著特定情景下的多種因素 處于一種復(fù)雜、動態(tài)而又相互交錯的關(guān)系之中，強調(diào)其中哪一個的優(yōu)先地位都只能是對實情的簡化甚至歪曲。以我目前的辨識能力所見，我認為軟件開發(fā)航線上的最 大阻礙是“商業(yè)、技術(shù)和管理”這三重因素的互動：軟件開發(fā)首先并且最終是商業(yè)活動，商業(yè)利益要求開發(fā)周期越短越好、人力物力成本越少越好、后期能容忍的需 求變更越多越好；技術(shù)對于軟件企業(yè)具有核心意義的重要性，尤其是，如何處理商業(yè)因素固有的保守性和軟件持續(xù)的技術(shù)革命之間的沖突，成為每一個項目都會遇到 的問題；而軟件項目的管理者更存在如何協(xié)調(diào)技術(shù)與非技術(shù)因素，如何對看似純屬理智產(chǎn)物、其實充滿未知因素的開發(fā)過程進行監(jiān)控的難題。
　　軟件項目的一葉之舟，就航行在這三種因素共同作用而形成的湍流和漩渦之中。當我們將目光停留在任何單一的方面時，某個促狹的魔鬼就會從另兩個領(lǐng)域悄然潛 入，引發(fā)令人懊悔的后果?？朔@些阻礙，需要耐心、對所有問題領(lǐng)域的尊重、甚至還要一點點運氣。想要只靠使用某個“項目管理軟件”、掌握某種技巧或某種“ 境界的提升”，一勞永逸地解決所有問題，目前在我看來是不現(xiàn)實的：我們面臨的困難，在Brooks的意義上是“本質(zhì)”而非“偶然”的。即使某個特定的項目 中解決了某個困難，也無法保證從此我們就對它有了免疫力。來自考試大項目管理站。
　　但在硬幣的另一面，正如德國人的名句所言“哪里有危險，哪里就有救渡”。軟件項目的這種內(nèi)在的復(fù)雜性，也許同樣是其“奇異的魅力”之所在。如果軟件開發(fā)的 藝術(shù)完全可以通過抽象的原則“線性地”掌握，那么我們甚至可以自問，會不會有一天軟件項目只由計算機自行開發(fā)，人類開發(fā)者完全被取代呢？在嚴格的科學(xué)意義 上解決這個問題，也許需要更明晰的“可開發(fā)性”定義（就像上世紀中人們對“可計算性”的澄清一樣）。細致的考察留給有志于圖靈獎的各位完成。不過直觀地考 慮，依據(jù)上面的討論我們就可以相信，軟件開發(fā)的困難所在，正是機器無法通過形式化的方式克服，而人類開發(fā)者最為擅長的部分。我想這是真正傾心于這項事業(yè)的 人樂于看到的論證：要感謝這些困難，廣大軟件開發(fā)人員不會在某天早晨醒來發(fā)現(xiàn)自己已被一臺能干的計算機取代。