專案失敗原因分析（專案失敗的八大原因）
由於各種各樣的專案管理和技術因素，從過高的期望值到基本的特性更改，軟體開發專案經常會偏離軌道，甚至是被宣佈失敗。
每一個軟體專案都是從遠大的夢想和巨集偉的願景開始的。或許在另一個世界的某個地方，的確會有一個專案可以實現每一個人的夢想，但是在我們的世界中，軟體專案總是跌跌撞撞地走向終點線，有時甚至會越過它。
當然，根據定義，軟體專案的失敗並不總是非此即彼的事情。你可能會得到執行良好但沒人使用的程式碼。或者你可能會得到不能編譯的程式碼。有時你可以從燃燒的殘骸中搶救出一些有用的東西，但最好在它爆炸前逃跑。
當悶熱的爛攤子冷卻下來，分析就開始了，因為人們想知道是什麼地方出了問題。以下是最常見的罪魁禍首。
過少的團隊成員
用太少的程式設計師做太多的事情是一個常見的問題。開發人員在耗盡精力之前只能編寫這麼多的程式碼。我曾經在一個團隊工作過，在這個團隊中，經理認為從敏捷團隊中擠出更多工作的正確方法是安排每個“sprint”，讓它在前一個sprint之後就立即開始。沒有深思熟慮的停頓來找出什麼是有效的，什麼是無效的。Sprint 42於週三下午1:59結束，Sprint 43就於週三下午2:00開始了。回顧性分析會議通常被安排在下一個sprint開始之後。一些聰明的傢伙建議他們將其改名為“馬拉松”，但很快就投入了另一份工作。
當然，很難知道究竟有多少程式設計師才是足夠的。有時路障和問題會阻礙我們前進。工作量翻倍也許不是經理的錯，但如果你沒有足夠的人手，你的專案就註定要失敗。
團隊成員太多
如果太少的程式設計師可能是不好的，那麼太多就可能會更糟，因為網路效應也可能會毀滅一個軟體專案。更多的人意味著需要更多的協調，也就意味著更多的會議，它將佔用原本編寫程式碼的時間。但是如果你召開的會議不夠多，你很快就會發現團隊A的API不能與團隊B的微服務進行銜接。
如果我們可以通過給專案配備過多的人員來砸錢解決問題，那當然很好，但你不能這樣做。
太多的溝通
編寫軟體是一門孤獨的藝術。人類可以一起工作，但只能在有限的時間內。許多開發人員討厭開會，因為他們需要將自己的思維從沉浸式的邏輯思維轉向更開放、更社會化的模式。這需要時間。一些團隊領導試圖通過召開更多的會議來使每個人保持同步以對抗失敗。這是一個崇高的努力，但你依舊可以聽到齒輪的磨擦聲。團隊需要分享足夠的資訊來保持同步，但太多的資訊只會浪費大腦週期。
基本功能的變化
理論上，開發人員喜歡認為自己是敏捷的。這就是他們擁抱這個詞的原因。但有時敏捷會讓人失去平衡。這一切取決於這種轉變是否需要對基礎框架進行根本性的改變。當只是移動按鈕或改變顏色時，很容易變得敏捷。但是，當涉及到需要重新編寫資料庫模式或處理分片和複製時，就沒有一種簡單的方法可以優雅地進行調整了。
為工作選擇了錯誤的技術
即使你仔細計劃並制定了正確的特性列表，如果使用了錯誤的技術，事情也可能會失敗。例如，資料庫被設計為通用和靈活的，但是存在架構上的限制。推動他們去做一些他們不想做的事情，當他們被要求擴充套件時，他們就會放慢速度，甚至是停止。或者，你可能會開始使用NoSQL資料庫，因為它們聽起來很酷，但後來發現你確實需要ACID級別的事務來保持一致性，而資料庫卻不提供這些事務。
缺乏優先順序
好的規劃者會列出一個特性列表，並對它們進行優先排序。但有時優先事項與實施它們的現實並不一致。在最糟糕的情況下，可能最重要的特性是最難建立的。
你的開發者該怎麼做?如果他們專注於最重要的特性，他們將無法取得任何進展，並且可能最終無法交付任何功能。但是如果他們開始完成那些簡單的特性，他們就可能會得到一些毫無價值的東西。
好的計劃所需要的不僅僅是一張清單。對遠景的架構必須考慮到需求和交付它們的成本。
市場視窗的關閉
有時候這不是程式設計師的錯。我曾經的一個專案是把一本最暢銷的參考書變成一個應用程式。在網際網路出現之前的幾年裡，這本書非常暢銷。該公司計劃利用這一需求，製作一個互動式的版本，讓人們可以對資料進行排序和搜尋。程式設計團隊交付的軟體包含了書中的所有內容，但比書本身更快、更漂亮、更輕。但是沒有人想要它了。因為已經有足夠多的其他來源了，沒有人需要另一個應用程式來做幾乎和新聞網站一樣的事情。
有時候一個想法看起來很不錯，但市場已經改變了。
糟糕的架構決策
在一個專案中，我的任務是更改資料庫中某一行中的一個數字。當使用者完成註冊後，我要將使用者的id號新增到最新的訂單中。聽起來很簡單，對吧?但是系統是建立在微服務架構上的，我不能通過編寫一行程式碼來告訴資料庫更新該列來解決這個問題。不行。架構的計劃是在現有堆疊中新增一個新的微服務呼叫，即使這樣做也很困難，因為我的第一個微服務呼叫需要觸發另一個微服務呼叫等等。
最後，建立這個微服務網路的架構奇才告訴我，這一切都非常簡單，並勾勒出了一條貫穿整個體系結構五層的蜿蜒路徑。我的工作是向5個不同的微服務新增5個新的API呼叫，這也意味著需要為每個層新增5組自動化測試。這些年來，每個API都是由不同的團隊開發的，這就要求我理解和模仿五種不同的編碼風格。所有的一切就是為了改變一個數字。
架構決策可能會持續一生--尤其是當你的自我意識已經完全投入其中而你無法改變它的時候。專案經理必須時刻注意主架構何時會不起作用，並做出重大決策。
政治衝突
將技術故障歸咎於政治因素似乎有些含糊其辭，但事實已經越來越真實了。隨著專案的擴大和跨越多個組織，出現派系和團隊來爭奪控制權、資源和最終權力也就不足為奇了。
政治派系不同於真正的技術差異。通常有一些技術標準或程式碼庫會以不同的方式做同樣的事情。以XML和JSON為例。我能感覺到這兩種技術的粉絲都急於解釋為什麼它們不一樣，以及為什麼他們最喜歡的選擇是正確的。但是當一個團隊的一部分喜歡一個選擇，而另一部分則最尊重有競爭關係的另一方時，摩擦就會把他們分開。
隨著架構師將應用程式拆分為多個更小的服務和API，這種情況將變得更加常見。不同的團體最終會控制這些，但他們不會總是和睦相處。如果A組喜歡JSON，而B組喜歡XML，那麼你的團隊要麼需要同時實現它們，要麼更改其中一個。所有這三種情況，對於必須同時與A組和B組合作的團隊來說都是一種痛苦。
押注於還沒有準備好投入生產的技術
程式設計師喜歡最新的工具和框架。他們願意相信，新方法將掃除上一代人遺留下來的所有糟粕。
但通常情況下，下一代的技術可能還沒有準備好投入生產。新功能或許看起來很完美，但通常會有一些不太明顯的缺陷。有時程式碼只支援少數的檔案型別，或者只支援幾個資料庫的介面。他們向你保證，其他產品很快就會推出，但是你的專案需要在這個月就釋出，而“很快”則可能意味著需要6個月或更多的時間才能完成所需的特性。
押注於即將過時的技術
根據我的經驗，舊的技術通常更可靠，更經得起考驗，但這並不意味著舊技術是完美的。即使軟體專案已經投入使用，也可能會缺少對軟體專案至關重要的特性。更糟糕的是，押注於老技術可能會讓你錯過未來可能出現的變化。新的思想、協議和檔案格式出現了，但它們可能還無法實現。如果競爭團隊的某個人堅持認為你應該支援某種新協議，那麼舊的技術將會帶來傷害。
不切實際的截止日期
截止日期是棘手的。許多專案需要在特定的季節或事件之前進入市場。然而，當第一次寫下截止日期時，開發人員可能還沒有發現他們前進道路上的障礙。然後，如果專案失敗，並且沒有啟動軟體，事件就過去了，那麼整個專案就會被視為失敗，即使程式碼已經準備好順利執行。截止日期可以幫助每個人集中精力，齊心協力，但也可能會讓人產生不切實際的期望。
無法預見的競爭
一個好的產品經理在進入市場之前會調查競爭情況，但是沒有人能預測什麼樣的競爭會突然出現。如果新的競爭對手引入了你必須複製的新特性，請參閱上面關於特性更改和優先順序不匹配的部分。
匆忙的流程
許多軟體專案都是從想要修復某些東西的個人或團隊的願景開始的。他們可能會想出“Snapchat for Y”或“Uber for Y”這樣的短語，然後就期望產品團隊能像Snapchat或Uber一樣反應迅速。問題在於，確定專案的範圍、描繪資料流和設想UI的工作量通常是編寫程式碼的十倍。而幻想家們想要馬上將想法變成程式碼。
線框圖、資料庫模式和使用者描述不是一蹴而就的，而是工作中必不可少的一部分。但大多數人認為軟體專案只是編寫程式碼來實現一個想法而已。
錯誤地相信軟體的力量
夢想家常常對軟體改變世界的力量抱有不切實際的信念。很多人以為社交媒體會把我們團結在一起，但不知為何，它只是暴露了一直以來都很明顯的斷層線。軟體專案通常是以幻燈片開始的，這些幻燈片承諾將徹底改變世界的某個角落。然後，當向資料庫中塞入資料並不能改變任何人時，人們就會感到憤怒、無聊、困惑甚至更糟。他們說，這個軟體被破壞了，因為它未能實現大家所期待的神奇轉變。
許多軟體專案可以編譯、通過QA、釋出，甚至獲得不錯的評審，但卻最終未能實現幻燈片上的任何承諾，因為那些改變世界的承諾是不可能的。
邪惡的分包商
我們喜歡那些提供庫和工具的廠商，這些庫和工具使得我們只需要使用幾行程式碼就能創造奇蹟。但是偶爾，他們會聽到自己的力量，並利用它來摧毀一個專案。版本1.0的預算表非常好，以至於管理層會毫不猶豫地批准版本2.0。然後供應商就可能會通過三倍或五倍的價格來擠壓我們。
即使供應商不是故意這樣做的，也可以感受到這種影響。免費的庫可以讓一個專案看起來非常便宜。然後，當需求飆升，第二個版本擴大了需求時，實際價格就會開始上升了。
翻天覆地的鉅變
在大流行和抗議的一年裡，沒有什麼比時代精神改變得更快了。該專案是否將強大的隱私保護作為了一個核心特徵?唉。大流行使得每個人都對追蹤接觸者感興趣了。有人想專注於商務旅行嗎?唉。酒店業已經崩潰了。需要一年或更長時間的大型軟體專案可能有被災難性事件中斷的風險。一開始看起來似乎是個很不錯的想法，但到了要付諸實踐的時候，就可能會變得毫無希望、毫無意義。
技術遷移
不僅僅是世界的變化。科技界的潮流變化也會產生同樣的效果。NoSQL曾經是一個天才的想法，它能夠將我們從關係模式中解放出來。然後又有人意識到檔案的膨脹是因為每個記錄都帶有一個本地模式。雖然一個好的敏捷開發團隊可以在技術的巨大變化改變領導層和客戶的態度時進行調整。但是即使是最敏捷的團隊也不能處理那些會把他們的架構計劃全部搞垮的重大變化。這個系統是建立在假設X是一個好主意的前提下的，而在突然之間X變成了一個垃圾。或許有時候最好的選擇是把它炸掉，然後再重新開始。
太多附庸
一些軟體專案的起步很好，甚至被成功地釋出了。然後就會有人新增了一到三個額外的特性，將新程式碼移植到現有的版本上，使程式碼繼續蹣跚前行。英勇的開發人員可能會多次實現這個目標，特別是在最初的架構師計劃良好的情況下。但是在某個時候，基礎就崩潰了。可能是資料庫無法處理負載。可能是需要太多連線來滿足各種查詢。好的軟體可能會變得過於臃腫，有時只是因為一些小小的改進把它推到了邊緣。
目標的改變
最初的計劃是建立一個資料庫來跟蹤客戶支出，以幫助制定營銷計劃。後來，一些天才又增加了一個功能，試圖利用人工智慧來將消費與天氣預報聯絡起來。或者有人想讓這個軟體自動為搜尋引擎廣告出價。改變目標也可能會顛覆一個專案。
很少有變化會自己毀掉一切。但是新的目標可能會揭示弱點並觸發失敗的模式。也許是這個團隊現在太小了，無法成功地完成這個專案。也許是其技術基礎對於新方法來說非常低效。總之，當決定改變目標時，每個人都會很難預料到這些煩躁的組合。