為什么IT項目總是延期?
這是 程序員小躍 的第 174 篇原創(chuàng)分享
還在讀大學(xué)的時候，有一門課程叫：軟件工程。里面會提到各種開發(fā)模式，什么瀑布式開發(fā)、敏捷開發(fā)、迭代式開發(fā)、敏捷瀑布模型等等，然后老師也都會提到開發(fā)時間，按期交付的重要性。
哪怕是做畢業(yè)設(shè)計的時候，導(dǎo)師們給了一個deadline，就必須在這個時間點之前完成畢業(yè)設(shè)計，完成答辯，才能畢業(yè)，否則就GG。
圖源：文心一言
但是，自從自己步入職場，貌似自己做的開發(fā)項目，基本多多少少會有延期，一開始也很納悶，怎么學(xué)校里學(xué)的理論和現(xiàn)實中的實際不一樣呢？直到工作多年之后，我才慢慢領(lǐng)悟，原來這不是我的幻覺，是大部分人都遇到的現(xiàn)實問題。
需求不明確或頻繁變動
雖然現(xiàn)在很多公司的項目開發(fā)規(guī)范里，都會有業(yè)務(wù)部門提需求，產(chǎn)品經(jīng)理接需求，然后下達(dá)到開發(fā)人員。這里通過一系列的串講，反串講，反復(fù)確認(rèn)需求，然后進(jìn)行開發(fā)。
但是，哪怕是這么做了，隨著時間的推移，隨著每個人思想上的進(jìn)步，項目開發(fā)進(jìn)行中多多少少會遇到變動。
或者說，一開始的時候都沒有流程規(guī)范，口頭提需求，然后靠各自的理解，這么做就會導(dǎo)致一開始就做不好，跟著不明確的需求做，是真的累。
計劃不充分
在項目開發(fā)中，需求方和接收方各自了解，但是因為不明確，或者頻繁溝通，導(dǎo)致一開始制定的時間計劃不夠準(zhǔn)確。
或者開發(fā)人員因為經(jīng)驗不足，錯誤的估計了自己的能力，導(dǎo)致時間估計不準(zhǔn)確、未考慮依賴關(guān)系或者沒有設(shè)定合理的里程碑，也可能導(dǎo)致項目延遲。
圖源：文心一言
技術(shù)挑戰(zhàn)
如果是簡單的需求，按部就班就可以了。
但是，很多客戶的需求都有一定的難度，然后客戶又想著對標(biāo)一些大廠的產(chǎn)品，比如用戶體驗對標(biāo)蘋果，這就導(dǎo)致一些高難度，高技巧的開發(fā)項參雜在里面。
因為，在項目實施過程中就遇到預(yù)料之外的技術(shù)挑戰(zhàn)或復(fù)雜性，這些問題可能需要額外的時間來解決。
溝通不足
項目開始前期，需求方，和開發(fā)方做了一系列溝通這個挺好的，但是當(dāng)開發(fā)開始的時候，就突然失聯(lián)了。
這樣的事情我不是沒遇到過，是遇到過好多次。
因此，項目團(tuán)隊成員之間以及與利益相關(guān)者之間的溝通偏少可能會導(dǎo)致誤解和錯誤決策。
圖源：文心一言
范圍蔓延
理想的開發(fā)當(dāng)然就是新來一個需求，然后照著這個需求進(jìn)行開發(fā)就完事了。
但是，現(xiàn)實他不和你這么玩呢。因為這個需求，你動了歷史代碼中的一小部分，導(dǎo)致一整塊功能執(zhí)行不了，這就是所謂的牽一發(fā)而動全身。
現(xiàn)在知道為什么會有那么多人叫歷史代碼為：屎山。開發(fā)過程中你都預(yù)想不到會有哪些事情發(fā)生，工作范圍在無意中逐漸擴(kuò)大，沒有相應(yīng)的調(diào)整時間表和資源。
客戶參與度低
這也是我遇到過的場景之一。
業(yè)務(wù)部門只管提出需求，但是人家只管生不管養(yǎng)的樣子，提了需求自己的任務(wù)就算完成了。
殊不知后面還有持續(xù)的溝通，以及測試需要他們參與呢。
很多時候，因為他們參與不足，會導(dǎo)致對于需求的理解不一致，或者統(tǒng)一決策花費更長的時間。
圖源：文心一言
風(fēng)險管理不足
很多時候項目開發(fā)不可能一帆風(fēng)順，在你開發(fā)的過程中，領(lǐng)導(dǎo)們會識別到各種風(fēng)險。
比如版權(quán)風(fēng)險，代碼的安全規(guī)范，或者政策的改變需要進(jìn)行緊急修改等等。
項目中潛在的風(fēng)險可能沒有被恰當(dāng)?shù)刈R別或管理，一旦這些風(fēng)險成為現(xiàn)實，可能會導(dǎo)致延期。
小結(jié)
要有效地避免或減少IT項目的延期，通常需要改進(jìn)項目管理實踐，包括更好的需求管理、風(fēng)險管理、溝通和資源規(guī)劃等。
在這里，躍哥還是推薦使用敏捷方法、持續(xù)集成和持續(xù)部署等現(xiàn)代軟件開發(fā)實踐也可能有助于提高項目適應(yīng)性和減少延期的幾率。
重磅！兩萬字長文總結(jié)，梳理 Java 入門進(jìn)階哪些事（推薦收藏）
