每一個軟件項目都是從遠大的夢想和宏偉的愿景開始的。或許在另一個世界的某個地方，的確會有一個項目可以實現每一個人的夢想，但是在我們的世界中，軟件項目總是跌跌撞撞地走向終點線，有時甚至會越過它。
當然，根據定義，軟件項目的失敗并不總是非此即彼的事情。你可能會得到運行良好但沒人使用的代碼。或者你可能會得到不能編譯的代碼。有時你可以從燃燒的殘骸中搶救出一些有用的東西，但最好在它爆炸前逃跑。
當悶熱的爛攤子冷卻下來，分析就開始了，因為人們想知道是什么地方出了問題。以下是最常見的罪魁禍首。
過少的團隊成員
用太少的程序員做太多的事情是一個常見的問題。開發人員在耗盡精力之前只能編寫這么多的代碼。我曾經在一個團隊工作過，在這個團隊中，經理認為從敏捷團隊中擠出更多工作的正確方法是安排每個“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變成了一個垃圾。或許有時候最好的選擇是把它炸掉，然后再重新開始。
太多附庸
一些軟件項目的起步很好，甚至被成功地發布了。然后就會有人添加了一到三個額外的特性，將新代碼移植到現有的版本上，使代碼繼續蹣跚前行。英勇的開發人員可能會多次實現這個目標，特別是在最初的架構師計劃良好的情況下。但是在某個時候，基礎就崩潰了。可能是數據庫無法處理負載。可能是需要太多連接來滿足各種查詢。好的軟件可能會變得過于臃腫，有時只是因為一些小小的改進把它推到了邊緣。
目標的改變
最初的計劃是建立一個數據庫來跟蹤客戶支出，以幫助制定營銷計劃。后來，一些天才又增加了一個功能，試圖利用人工智能來將消費與天氣預報聯系起來。或者有人想讓這個軟件自動為搜索引擎廣告出價。改變目標也可能會顛覆一個項目。
很少有變化會自己毀掉一切。但是新的目標可能會揭示弱點并觸發失敗的模式。也許是這個團隊現在太小了，無法成功地完成這個項目。也許是其技術基礎對于新方法來說非常低效。總之，當決定改變目標時，每個人都會很難預料到這些煩躁的組合。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號