軟件項目最常見的失敗原因分析
最佳實踐建議在啟動一個新的軟件項目時，尋求一名在軟件開發領域具有豐富經驗并且可以在項目計劃的早期階段提供協助的主題專家的幫助。這一策略已經被證實可以極大提升項目的成果，然而在項目結束時你還是只能眼睜睜的看著失敗發生。為什么會這樣呢？
項目失敗可分為成本超支、交付延期、質量不合格和/或產品未被應用等一種或幾種情況。無論是否曾經參與到項目計劃階段，通常情況下，軟件開發人員 都會首當其沖承擔失敗的責任；無論怎樣，他們是真正構建這個應用的人。然而，對項目更進一步的審查表明并非所有失敗的項目都應歸咎于開發人員能力不足。當 對這些失敗的項目進行評估時，其中一些項目與行業趨勢相比完成的“還算不錯”，然而卻被其所在組織認定為失敗項目。其原因在于絕大多數的問題都與項目之初 有缺陷的評估或錯誤的商務決策聯系緊密。為了避免這種情況發生，整個組織首先必須要使用標準的評估術語集合。我們經常會發現個人和組織大量地互換使用關鍵 術語，而實際上他們各自都有獨特的含義。
目標- 我們想要完成或達成的目標 約束 - 在我們所能完成的工作上的一些內部或外部的限制 估算 - 在范圍、成本、日程、人員和可能性確定的情況下，對我們所能完成的工作的技術性計算。 承諾 – 通過選擇一個評估場景并分配合適的資源，在一系列的限制條件下達成目標的商務決策。 計劃 – 一系列項目任務和活動的集合，讓我們可以在確定的范圍、預算、日程以及人員的情況下，有一定的概率可以履行某一承諾。
這些概念的清晰定義可以確保項目擁有一個良好的開端——實際的目標和對項目所受限制的理解。若非如此，下面這些因素很有可能導致項目在一開始就踏上死亡的征程。
1. 在沒有實質的數據和分析的情況下，就接受一個強制的日程安排或完成日期/里程碑日期。組織中的某個人公開推測項目將在某一特定日期完成，這樣在無意中整個 團隊都會致力于這一期限。也許你的預算周期顯示分配給這一項目的資金必須花費到今年年底或者下一個版本不會得到資金支持。也許項目的利益相干人希望項目能 在圣誕節前完成，知道項目已經結束他/她就可以安靜地享受假期。或者干脆就是因為利益相干人特別喜歡整數，希望項目能夠在該月一號發布。為什么一個開發團 隊會被設定一個主觀的項目完成日期的原因五花八門。過于狂熱的計劃經常導致項目人員配備過度的不幸現實是為什么軟件項目失敗的另一原因。
2. 添加過多的人員以實現不切實際的日程壓縮。項目經理如何處理過度樂觀的項目計劃？一個常見的反應就是增加項目組成員，增加的成員經常會比完成項目所需的成 員更多。這樣不僅會大幅增加項目的成本，還會降低項目質量。讓更多的人參與到項目中會增加錯誤傳達的可能性，也會讓不同部分的代碼整合更具挑戰。此 外，Frederick Brooks (1975) 的主張“在延期項目中增加人手只會讓項目更加滯后”是有一些道理的。這些人員通常是從其他項目中調派而來。這會讓其他項目的 項目計劃更加滯后 并且還要求新的成員能夠趕上資深成員，這樣整體來說生產力是下降的。
3. 未能考慮和調整需求的增長或變化并據此對計劃和預算預期進行必要的調整。“如果……不是更好么？”這種話有時候是最可怕的，特別是在項目組建的過程中道聽 途說而來時。當然，確實需要時間和場所進行頭腦風暴，這些活動應該在第一階段和第二階段開展。實際上，這兩個階段的目的就是要決定一個項目是否可行，以及 應用應該具備哪些功能特性。你可以如此考慮這個問題，第二階段幫助你確定所要構建的內容，第三階段則開始構建在第二階段所確定的內容。在這兩個高級階段之 間存在一定的重疊，當處于階段三時，對于一個產品發布版本來說，應該已經有了一個清晰的必要功能列表。如果在沒有增加開發時間和預算的前提下就增加功能， 需求的增長就會成為問題。實際上，這是在要求在更短的時間內完成更多的工作，這種手段早已被證明無效。取決于其特性和時點，已有需求的變更也有可能成為問 題。只要變更發生在某一特定迭代的構建之前，使用敏捷開發方法的項目就可以處理這些明細需求的變更。不過，對于任何會導致代碼返工的軟件架構方面的需求變 更幾乎必然會對項目的計劃和預算產生影響。
4. 忽略事實和統計數據的情緒化或”全憑直覺的“利益干系人談判。或早或晚，我們都會與某個我們參與的具體項目緊密聯系并在該項目的產出之上投入情感。對于許 多人來說，該項目可能關乎自己的聲望；項目太大經不起失敗，而這經常會讓我們被我們的情感所控制。當軟件項目的成功或失敗懸而未決導致個人的事業處于危險 之中時，任何相關的業務決策很有可能都會受到影響。壓力可以讓人思維混亂，特別是在賭注巨大之時。為了給客戶留下深刻的印象，某個利益相干人可能會要求一 個12個月的項目計劃安排，而完全不顧之前類似規模的項目報告均顯示了15個月的生命周期。利益相干人很可能會忽略項目成員的建議，并聲稱他“感覺”項目 團隊可以渡過難關。在這種情況下，憑直覺可能是相當不利的并且有可能直接導致項目的失敗。
5. 錯誤，但普遍認為眾所周知的銀彈可以獨自解決項目吞吐量或過程問題。當其他嘗試都已失敗時，一個常見的方法就是改變策略。這時比較常見的想法就是“我們現 在的所作所為一定是錯誤的”以及“我們的競爭對手在做些什么？”也就在這時，“IT銀彈”的思慮可能就會開始在辦公室中蔓延。例如，某人可能會建議組織， 需要采用最新的流行開發方法。雖然這可能會將組織引領至一個偉大的方向，但像這樣的決策決不應該草草定論。無論你的組織決定采用哪種開發方法，這也只是實 現層面的變化。僅僅是開發方法的轉變并不足以完成開發操作的轉換。無論做出什么決策，為了能夠成功實施，就需要各方均能接受并支持這一決策，并且需要為項 目成員提供培訓，而且所有人都需要為同樣的標準負責。否則，每次啟動新的項目時，你的開發策略就基本相當于等待天空的星辰排列整齊，期盼奇跡發生一樣。如 果沒有經過深思熟慮，實現這種策略不僅存在令人難以置信的風險，同時也會減少團隊成員在項目中期提供反饋的機會。簡而言之，造成軟件項目失敗的原因林林總 總。花點時間認真反思一下上述原因是否曾經也是導致你的組織中項目失敗的元兇。那么現在是否有了應對它的措施？作為一個執行領導人，可以做的工作有很多， 不過對開發操作提供支持仍需很大的勇氣。他們需要在合理的預期內運行。顯然，他們仍需要對自己的行為負責，因此就需要歷史績效數據作為證明他們能力的證 據。你需要從多個不同的維度搜集數據，包括項目的計劃持續時間、所花費的精力、工作的范圍、項目的整體質量以及所達到的生產力水平。這種情況下，生產率指 數（PI）以指數點數作為計量單位，這是一個有專利的QSM計算單位，范圍從0.1到40。它讓項目之間的比較更有實際意義并且對軟件開發因子作出了解 釋，其中包括如下變量：管理影響、開發方法、工具、經驗水平和應用程序類型的復雜度。一旦某個組織建立了已完成項目的倉庫，就可以計算定制化趨勢線，用于 基線創建。這些趨勢線作為參考點可用于組織內的項目比較。項目相對于趨勢線所處的位置表明了項目與平均水平的相比孰優孰劣。這會讓你對組織的當前能力有清 晰的洞察。
圖1. 公司項目組合與基線生產力趨勢對比圖通過查看我們的項目與基線的相對關系，可以了解到許多關于我們在哪些方面做的很好，哪些方面仍需提高的信息。檢測項目 與各種趨勢的偏離度有助于杜絕最好或最差的績效。項目的極端值也可以為此提供有力的洞察。圖1展示了公司項目組合與他們的基線平均生產率的對比。有兩個項 目由于落在兩個標準偏差之外而顯得尤為突出，其中一個在平均線之上而另一個則在平均線之下。對影響這些項目的因子的進一步檢查（如，新技術、工具和方法、 人員或項目復雜度）可以幫助了解為什么這些項目的執行如此成功或失敗。效仿一流項目中最好的經驗，避免失敗項目中的教訓可以幫助提升未來項目的績效。通過 展示過去已經完成的成果，了解當前開發操作的基線，可以幫助你合理地設立將來的項目的預期。如果所需的項目參數將評估置于一個未知的領域，就可以使用歷史 基線協商出一個更加合理的方案。這個基線還可以用于合約談判、報價及 供應商績效評估 以及引導客戶約束，從而達到縮減成本和改進過程的目標。這一工作會讓你在與客戶和業務干系人的談判中占據更加有利的位置。理想的結果是達到共贏。很有可能這會需要一些妥協和折衷，但這個過程中你會播下成功的種子。
關于作者
C. Taylor Putnam-Majarian 是 QSM的一名顧問分析師，有超過7年的專業的數據分析、測試和研究經驗。除了為來自商業和政府部門的客戶提供軟件評估和基準測試方面的咨詢支持之 外，Taylor還撰寫了大量敏捷開發、軟件評估和過程改進方面的出版物，她還是QSM博客的定期撰稿人。最近Taylor在華盛頓特區舉辦的Agile in Government會議上展示了題為 Does Agile Scale? A Quantitative Look at Agile Projects 的研究。泰勒擁有迪金森學院的學士學位。
Doug Putnam 是數量化軟件管理股份有限公司（QSM）的聯合首席執行官。他在軟件度量領域有35年的經驗并且被看作是這一行業發展的先驅者。Putnam先生曾幫助指 導業界領先的軟件評估和度量工具SLIM套件的開發，并且是一個相當出名的國際化作家、演說家和顧問。其主要職責包括管理和交付QSM軟件度量服務，定義 SLIM產品套件的需求以及監督從QSM基準數據庫衍生而來的研究活動。