軟件項目可能在你意識到之前就已經脫離軌道了。以下是其中的一些微妙的警告信號，表明您最新的應用程序開發計劃可能並沒有看上去的那麼順利。
每個軟件項目都是在號角和樂觀中開始的。即使是在深夜中拼湊起來的最微不足道的小項目，也都是源於一個星光璀璨的夢想。團隊相信，只要幾行代碼和一些開源庫，我們就可以完成任務，並可以為我們優雅、完美的工作而接受獎勵。
但是在幾周或幾個月後，我們就會從夢中醒來，並發現git存儲庫中充滿了各種決策、修訂和恢復。它足夠好了嗎?滿足標準了嗎?會有人真正使用它嗎?很多時候，軟件團隊深入到一個項目中，卻發現這些問題的答案中至少有部分是否定的。有沒有辦法預見到它的到來呢?
的確，有時候，即使是最好的編程計劃在沒有任何警告的情況下也會誤入歧途，但大多數情況下，一個註定要失敗的結局對於任何一個一路上密切關注它的人來說都是顯而易見的。
下面是軟件工程師列出的十幾個軟件項目可能失敗的早期警告信號。
在管理層支持下的轉變
這個項目的業務冠軍是在某天早上試圖把他或她的孩子送進南加州大學或耶魯大學後被捕的嗎?CIO是否取消了最近的三次進度評審會議?算一下，你是否已經大概有一年沒見到CIO了?財務總監問過你的員工預算嗎?合併能掃除一半的組織結構圖麼?
許多軟件項目失敗的原因可能與編寫代碼的人沒有任何關係。如果管理層中有人喜歡您的軟件項目，就會通過審批流程以支持它，如果這個人消失了，支持也就會消失。你的願景其實是無關緊要的。如果另一個團隊對公司的發展方向有不同的看法，並且這個派別控制了公司，你的項目就可能會消失。所以，儘管你可能不想這麼做，但還是要關注政治。
市場的變化
重要的不僅僅是內部支持。消費者和他們所驅動的市場也能改變他們的慾望。軟件項目需要幾個月的時間才能完成，而市場卻可能在幾周、幾天甚至幾分鐘內就消失了。
如果你的項目針對的是一個快速發展的市場，那麼當你完成代碼時，市場變得完全不同的可能性就會更高。即使你的項目是在一個更穩定的領域，新的競爭也幾乎可以在一夜之間出現。如果你的團隊沒有一個計劃來適應不斷變化的趨勢，就很有可能會被淘汰。
程序員的跳槽
人們總是在換工作，優秀的程序員需求量總是很大，但是如果團隊不斷地流失人員，那麼就會出現問題。如果工資已經足夠高，工作條件已經足夠好，那麼項目本身就可能是罪魁禍首。也許編碼人員被需求弄糊塗了，他們跳起來是為了避免心理壓力。也許整個架構都是錯的，他們已經無法讓它正常工作。也許團隊中有一些害群之馬正在趕走所有人。團隊外流是一個預兆，表明有些事情是錯誤的，可能會破壞項目成功的機會。
在簡單的事情上花了太多時間
團隊對簡單的變更響應速度有多快?他們能改變背景顏色嗎?將複選框移動幾個像素?如果微小的更改需求沒有得到快速處理，那麼大的更改將會需要更長時間。
有時候糟糕的架構決策會讓一些簡單的事情變得幾乎不可能。我的一個工作項目要求我在數據庫中填寫一個額外的列，這需要更改五個不同的微服務。這意味著要檢查五個不同的項目，通過五個不同的代碼審查，並編寫五組不同的單元測試。它們都只是為了更新一行中的一個數字。
開發人員有一種過度複雜化簡單任務的習慣，有時最聰明的開發人員反而是最糟糕的。有些更改將是困難的，但是如果團隊在處理大多數小更改時也遇到困難，那麼這就表明基礎過於複雜了。
沒有成本模型
估計每個用戶的成本比以往任何時候都要容易。雲計算按小時計算，無服務器系統按事務定價。如果用戶每個月使用M字節的數據訪問服務器N次，你知道對這些數據進行所有計算需要多少成本嗎?
一些項目團隊對成本一無所知，然後他們可能會發現，一筆花費X便士的交易只能帶來Y便士的收入，遺憾的是，X > Y。該軟件可以編譯和運行，也沒有太多bug，但是項目失敗了，因為它是一臺賠錢的機器。跟蹤成本和確定一個明確的目標是至關重要的，否則開發人員可能最終構建出一個非常酷的東西，但需要周圍有6臺最複雜的雲機器。
開發人員一味地遵從一個天才
有聰明人在你的項目上工作是件好事。但是當一個人的思想佔據主導地位時，危險就來了。除了一些奇怪的情況外，如果每個人都說“我們去問X吧”，而X總是同一個名字，這通常就是一個不好的信號。如果X死了或者跑到山裡去尋找啟示，這個項目就會失去方向。
但是，如果X不離開，情況可能會更糟，因為每個人都希望由X來執行決策，而出現的瓶頸會阻止所有人繼續前進。X可能享受權力，X也可能是一個合格的天才，但強迫所有的工作都得到X的批准將是緩慢的。
代碼標準主導著討論
美學很重要，但一些開發人員過分關注代碼中的空白空間，並將這一點發揮到了極致。所謂的代碼標準只是妨礙團隊成員行使權力的一種方式。在代碼評審期間，當他們發現一個放錯位置的空格或製表符時，他們就不祥地宣佈“沒有達到標準”。
功能最終決定著一個項目的成敗，如果團隊不停止爭論外部人員永遠不會看到的內部代碼的美學，那麼團隊可能永遠也無法達到目標。
指標看起來太過完美
通過指標來衡量團隊進度是一個必要的要求，但是對它們過於信任也是很危險的，因為開發人員會玩弄您所能想象的任何度量。一位朋友解釋說，他的老闆有一個指標，可以衡量有註釋的功能的比例，所以他使用了著名的AI聊天機器人Eliza，以確保他的所有功能都有註釋，無論是多麼愚蠢的註釋。他甚至編寫了一些快速代碼來搜索變量名稱，並將它們包括在毫無意義的註釋當中。他的統計數據非常棒。要求所有功能都有註釋的老闆從來沒有讀過這些註釋，所以老闆也一直不知道內情。他剛剛在儀表板上看到了100%的註釋代碼，然後就去了高爾夫球場。
目光朝著閃亮的新事物移去
新的語言、庫和體系結構都很棒，但它們也有自己的定位，而且通常不在關鍵任務的堆棧中。它們適用於示範和探索性的次要項目。對於項目外圍的非必要微服務來說，它們是可以的。如果團隊有一個舒適的時間表，並且也沒有其他選擇，那麼這些選擇可能是可以接受的。
然而，隱藏在對某些新軟件解決方案的渴望中的真正含義是，開發人員可能正在與當前的項目或體系結構作鬥爭。當前的計劃可能已經產生了太多的小故障、錯誤和令人頭疼的事。他們可能正試圖迫使一些方形圖庫與圓形API進行通信。膠水代碼可能比實際代碼還要來的多。對當前方法的不滿可能導致開發人員在不斷地徘徊。
業務規範的不明確
這個過程的前景是否模糊得令人難以置信?它是否充斥著像“disrupt”或“meta”這樣的流行詞，而不是像“HTTP”或“AJAX”這樣的技術術語?是否存在大量關於“改變世界”的討論，卻很少討論數據庫的選擇或架構策略?
創建軟件需要具體的技術決策，而有時候那些項目的幻想家並沒有花足夠的時間來考慮如何實現這個目標。有時候，他們很幸運，因為有一些聰明的人能夠構建它，但是通常情況下，不清晰的業務規範通常會導致項目的失敗。也許它需要太多的帶寬。也許延遲會讓用戶界面變得遲鈍。也許所有這些雲計算的成本還不足以被廣告和訂閱費所覆蓋。我們不知道會發生什麼，因為規劃文件裡沒有涉及到那個細節。
不受控制的複雜性
管理軟件項目的主要任務是找到一種方法來讓用戶滿意，同時將任務的複雜性降低到可管理的程度。每個人都希望代碼能夠輕鬆地閱讀他們的想法並提供答案，但是這些東西只有在用戶都想要相同的東西時才有可能。
當多個派系開始要求不同的東西時，項目就開始出錯了。如果他們對項目擁有太多的權力，而項目經理不能找到一種方法來協調他們的興趣並讓每個人都滿意時，那麼項目將變得非常複雜，完成它所需的代碼量將會大幅增加。如果項目團隊不能有效地說“不”，那麼工作的複雜性將比程序員編寫代碼的速度增長得快得多。
糟糕的測試計劃
有些程序員喜歡大量編寫新代碼。每一行都是一個真實的創作，一個關於比特的藝術陳述，將被轉換成其他的一些比特集合。從前黑暗的地方，現在有了光明。這是一種美妙的感覺，但這只是其中的一部分。僅僅構建軟件是不夠的，我們需要了解它何時可以正確運行，這樣我們才能夠了解它何時會失敗。
一個好的測試計劃應該向後看，而不是向前看，檢查是否一切正常。這並不是能夠憑空變出來的能夠讓人覺得興奮和刺激的東西。它只是充滿了嘮叨和提醒，敦促你回去把事情做好。測試通常並不是愉快的。
但是測試和構建代碼一樣是一門藝術。有太多需要進行測試的東西了，你永遠不可能結束它。但如果太少，代碼就可能無法正常工作。如果一個軟件項目團隊不能平衡創造的喜悅和測試的繁重工作，他們將走向失敗。
不合理的期望
有些事情對軟件的使用者來說太容易了，以至於運行項目的人常常沒有意識到讓這種神奇的功能發揮作用有多難。許多項目都可以編譯並運行，幾乎沒有錯誤，但是如果它們不能滿足用戶的需求，就會被視為失敗。有時候問題不在於代碼，而在於使用它的人無法實現的夢想。什麼?新的數據庫也不能治療我的禿頂嗎?我還以為它能像《星際迷航》那樣傳送並瞬間移動呢!
軟件開發人員需要保持對項目的控制，以確保大膽的夢想家或大思想家無法指揮項目。如果期望得到合理的控制，項目就有機會實現它們。如果不是，那麼，即使是最出色、無缺陷、低延遲、最先進的應用程序也可能會讓人失望。