軟體專案失敗最常見的5大原因

最佳實踐建議在啟動一個新的軟體專案時，尋求一名在軟體開發領域具有豐富經驗並且可以在專案計劃的早期階段提供協助的主題專家的幫助。這一策略已經被證實可以極大提升專案的成果，然而在專案結束時你還是隻能眼睜睜的看著失敗發生。為什麼會這樣呢？

專案失敗可分為成本超支、交付延期、質量不合格和/或產品未被應用等一種或幾種情況。無論是否曾經參與到專案計劃階段，通常情況下，軟體開發人員都會首當其衝承擔失敗的責任；無論怎樣，他們是真正構建這個應用的人。然而，對專案更進一步的審查表明並非所有失敗的專案都應歸咎於開發人員能力不足。當對這些失敗的專案進行評估時，其中一些專案與行業趨勢相比完成的“還算不錯”，然而卻被其所在組織認定為失敗專案。其原因在於絕大多數的問題都與專案之初有缺陷的評估或錯誤的商務決策聯絡緊密。為了避免這種情況發生，整個組織首先必須要使用標準的評估術語集合。我們經常會發現個人和組織大量地互換使用關鍵術語，而實際上他們各自都有獨特的含義。

目標 - 我們想要完成或達成的目標 約束 - 在我們所能完成的工作上的一些內部或外部的限制 估算 - 在範圍、成本、日程、人員和可能性確定的情況下，對我們所能完成的工作的技術性計算。 承諾 – 通過選擇一個評估場景並分配合適的資源，在一系列的限制條件下達成目標的商務決策。 計劃 – 一系列專案任務和活動的集合，讓我們可以在確定的範圍、預算、日程以及人員的情況下，有一定的概率可以履行某一承諾。

這些概念的清晰定義可以確保專案擁有一個良好的開端——實際的目標和對專案所受限制的理解。若非如此，下面這些因素很有可能導致專案在一開始就踏上死亡的征程。

1. 在沒有實質的資料和分析的情況下，就接受一個強制的日程安排或完成日期/里程碑日期

 組織中的某個人公開推測專案將在某一特定日期完成，這樣在無意中整個團隊都會致力於這一期限。也許你的預算週期顯示分配給這一專案的資金必須花費到今年年底或者下一個版本不會得到資金支援。也許專案的利益相干人希望專案能在聖誕節前完成，知道專案已經結束他/她就可以安靜地享受假期。或者乾脆就是因為利益相干人特別喜歡整數，希望專案能夠在該月一號釋出。為什麼一個開發團隊會被設定一個主觀的專案完成日期的原因五花八門。過於狂熱的計劃經常導致專案人員配備過度的不幸現實是為什麼軟體專案失敗的另一原因。

2. 新增過多的人員以實現不切實際的日程壓縮

 專案經理如何處理過度樂觀的專案計劃？一個常見的反應就是增加專案組成員，增加的成員經常會比完成專案所需的成員更多。這樣不僅會大幅增加專案的成本，還會降低專案質量。讓更多的人蔘與到專案中會增加錯誤傳達的可能性，也會讓不同部分的程式碼整合更具挑戰。此外，Frederick Brooks (1975) 的主張“在延期專案中增加人手只會讓專案更加滯後”是有一些道理的。這些人員通常是從其他專案中調派而來。這會讓其他專案的專案計劃更加滯後並且還要求新的成員能夠趕上資深成員，這樣整體來說生產力是下降的。

3. 未能考慮和調整需求的增長或變化並據此對計劃和預算預期進行必要的調整

 “如果……不是更好麼？”這種話有時候是最可怕的，特別是在專案組建的過程中道聽途說而來時。當然，確實需要時間和場所進行頭腦風暴，這些活動應該在第一階段和第二階段開展。實際上，這兩個階段的目的就是要決定一個專案是否可行，以及應用應該具備哪些功能特性。你可以如此考慮這個問題，第二階段幫助你確定所要構建的內容，第三階段則開始構建在第二階段所確定的內容。在這兩個高階階段之間存在一定的重疊，當處於階段三時，對於一個產品釋出版本來說，應該已經有了一個清晰的必要功能列表。如果在沒有增加開發時間和預算的前提下就增加功能，需求的增長就會成為問題。實際上，這是在要求在更短的時間內完成更多的工作，這種手段早已被證明無效。取決於其特性和時點，已有需求的變更也有可能成為問題。只要變更發生在某一特定迭代的構建之前，使用敏捷開發方法的專案就可以處理這些明細需求的變更。不過，對於任何會導致程式碼返工的軟體架構方面的需求變更幾乎必然會對專案的計劃和預算產生影響。

4. 忽略事實和統計資料的情緒化或”全憑直覺的“利益干係人談判

 或早或晚，我們都會與某個我們參與的具體專案緊密聯絡並在該專案的產出之上投入情感。對於許多人來說，該專案可能關乎自己的聲望；專案太大經不起失敗，而這經常會讓我們被我們的情感所控制。當軟體專案的成功或失敗懸而未決導致個人的事業處於危險之中時，任何相關的業務決策很有可能都會受到影響。壓力可以讓人思維混亂，特別是在賭注巨大之時。為了給客戶留下深刻的印象，某個利益相干人可能會要求一個12個月的專案計劃安排，而完全不顧之前類似規模的專案報告均顯示了15個月的生命週期。利益相干人很可能會忽略專案成員的建議，並聲稱他“感覺”專案團隊可以渡過難關。在這種情況下，憑直覺可能是相當不利的並且有可能直接導致專案的失敗。

5. 錯誤，但普遍認為眾所周知的銀彈可以獨自解決專案吞吐量或過程問題

 當其他嘗試都已失敗時，一個常見的方法就是改變策略。這時比較常見的想法就是“我們現在的所作所為一定是錯誤的”以及“我們的競爭對手在做些什麼？”也就在這時，“IT銀彈”的思慮可能就會開始在辦公室中蔓延。例如，某人可能會建議組織，需要採用最新的流行開發方法。雖然這可能會將組織引領至一個偉大的方向，但像這樣的決策決不應該草草定論。無論你的組織決定採用哪種開發方法，這也只是實現層面的變化。僅僅是開發方法的轉變並不足以完成開發操作的轉換。無論做出什麼決策，為了能夠成功實施，就需要各方均能接受並支援這一決策，並且需要為專案成員提供培訓，而且所有人都需要為同樣的標準負責。否則，每次啟動新的專案時，你的開發策略就基本相當於等待天空的星辰排列整齊，期盼奇蹟發生一樣。如果沒有經過深思熟慮，實現這種策略不僅存在令人難以置信的風險，同時也會減少團隊成員在專案中期提供反饋的機會。簡而言之，造成軟體專案失敗的原因林林總總。花點時間認真反思一下上述原因是否曾經也是導致你的組織中專案失敗的元凶。那麼現在是否有了應對它的措施？作為一個執行領導人，可以做的工作有很多，不過對開發操作提供支援仍需很大的勇氣。他們需要在合理的預期內執行。顯然，他們仍需要對自己的行為負責，因此就需要歷史績效資料作為證明他們能力的證據。你需要從多個不同的維度搜集資料，包括專案的計劃持續時間、所花費的精力、工作的範圍、專案的整體質量以及所達到的生產力水平。這種情況下，生產率指數（PI）以指數點數作為計量單位，這是一個有專利的QSM計算單位，範圍從0.1到40。它讓專案之間的比較更有實際意義並且對軟體開發因子作出瞭解釋，其中包括如下變數：管理影響、開發方法、工具、經驗水平和應用程式型別的複雜度。一旦某個組織建立了已完成專案的倉庫，就可以計算定製化趨勢線，用於基線建立。這些趨勢線作為參考點可用於組織內的專案比較。專案相對於趨勢線所處的位置表明了專案與平均水平的相比孰優孰劣。這會讓你對組織的當前能力有清晰的洞察。

圖1. 公司專案組合與基線生產力趨勢對比圖通過檢視我們的專案與基線的相對關係，可以瞭解到許多關於我們在哪些方面做的很好，哪些方面仍需提高的資訊。檢測專案與各種趨勢的偏離度有助於杜絕最好或最差的績效。專案的極端值也可以為此提供有力的洞察。圖1展示了公司專案組合與他們的基線平均生產率的對比。有兩個專案由於落在兩個標準偏差之外而顯得尤為突出，其中一個在平均線之上而另一個則在平均線之下。對影響這些專案的因子的進一步檢查（如，新技術、工具和方法、人員或專案複雜度）可以幫助瞭解為什麼這些專案的執行如此成功或失敗。效仿一流專案中最好的經驗，避免失敗專案中的教訓可以幫助提升未來專案的績效。通過展示過去已經完成的成果，瞭解當前開發操作的基線，可以幫助你合理地設立將來的專案的預期。如果所需的專案引數將評估置於一個未知的領域，就可以使用歷史基線協商出一個更加合理的方案。這個基線還可以用於合約談判、報價及供應商績效評估以及引導客戶約束，從而達到縮減成本和改進過程的目標。這一工作會讓你在與客戶和業務干係人的談判中佔據更加有利的位置。理想的結果是達到共贏。很有可能這會需要一些妥協和折衷，但這個過程中你會播下成功的種子。