在軟件項目中，有很多都是無法按時交付的，原因可以說是各有千秋，解決方案當然也有多種多樣，今天我根據自己的經驗來分析一下項目延期的一些常見原因以及我能給出的解決方案。
需求理解不清
造成項目延期的最大原因是需求分析階段沒有正確理解客戶需求。技術人員一般都是非常自負的，覺得你說的需求我都理解了，甚至在客戶還沒把需求完全講清楚之前，就已經開始寫代碼了，以顯示他的能力和能耐。我在前面一篇文章中提到了溝通能力對於技術人員的重要性，在這裏就是非常典型的場景。
客戶描述需求是從自身的理解和角度出發的，客戶跟技術人員是完全不同的兩個視角，這就勢必會讓技術人員得到的需求並不是客戶最真實的需求。那麼客戶在什麼時候會發現開發實現的產品跟自己需求有偏差呢，越早發現對項目進展越有幫助，但真實情況是技術沒把產品完全做出來之前，客戶來確認的東西都是不真實的，等客戶發現需求理解不對的時候，要再做調整就已經來不及了，離最初要求的交付時間已經很近很近了，只能接受項目延期的事實，或者接受一個需求不對的產品。
對項目的難度估計不足、工作量估計有偏差
在初步拿到需求的時候，技術人員對需求裏面的邏輯和細節理解是不夠的，往往會對項目的難度估計不足，絕大部分技術人員在對需求評估工作量的時候都是比較樂觀的。例如一個功能他評估出來的時間會是他自己實現的時間，但很少會去考慮如果出現意外需要處理呢？需要跟其他模塊的聯調呢？出現Bug後的多次修復時間呢？可能很多時間他都不會考慮進去的，而僅僅考慮自己獨立實現的工作量。
需求變更
這個也是造成項目延期的重要原因之一，前面講的是需求理解不清楚，而更多的時候是客戶對需求的描述，儘管在需求分析階段都經過再三確認，但隨着時間的推移和環境的變化，客戶的需求也會隨着變化的。一旦需求有變更，對技術人員來說是最麻煩的事情，可能從設計、編碼、測試都需要重新再走一遍，前面做的幾個星期的工作量都白乾了。
溝通不到位
在理清了需求的情況下，整個軟件項目是由一個團隊來完成的，這其中就會涉及到人與人之間的溝通和協作。我們知道一個人自己做事情，所有事情的細節和順序都會在自己腦子裏，基本上不會出錯的。但一個團隊做事情，就要求團隊所有人能像一個大腦那樣幹活，需要長時間的磨合以及各自狀態、進度的隨時暴露，很多團隊很難做到這樣協調的配合。一旦有需要合作的人之間溝通不到位，就會產生不必要的耗費，累計多了對項目按時交付也是有較大影響。
針對以上常見原因，按我自己的經驗，有以下解決方案以供借鑑：
需求反覆溝通確認
跟客戶討論需求的過程要儘可能細緻，寧願前期多花時間進行需求溝通和確認，也不要將需求的溝通放到研發開始之後。一般我會建議按照以下五個步驟進行需求溝通和確認：
1、讓客戶將需求講解出來，詳細講解各個細節；
2、根據客戶的講解，將需求以原型文檔的形式整理出來，在整理過程中及時跟客戶確認疑問點；
3、將原型講解給技術研發人員，確保客戶的需求是在技術上可實現的，同時聽取研發的意見和反饋，調整原型；
4、將調整後的原型跟客戶講解，以便客戶理解原型的方式和所做的更改；
5、讓技術研發人員對原型進行講解，確保研發人員對需求的理解和客戶的需求保持一致。
一般經過這5個步驟後的需求溝通確認，在實施過程中導致需求返工的可能性就比較小了。
正確評估工作量
根據需求進行工作量評估，是所有項目都需要進行的環節，我的經驗是由研發人員對需求進行拆解，儘可能將工作任務拆解到1-2天的工作量，只要你能將任務拆分開，表示你對需求的理解透徹，表示你對工作量的評估相對較準確。類似庖丁解牛，在庖丁眼裏，整條牛已經分成了若干個器官組合，他非常清楚哪塊是什麼器官，該怎麼下刀子，在庖丁眼裏，拆解一條牛需要多少刀、需要多少時間都是非常準確的。同樣，在對需求的理解和工作量評估中，只有你能將需求、任務拆解到1-2天的工作量，那說明你對需求任務的理解纔到位了，評估出來的工作量才相對準確。
另外，有一個業界常用的做法，就是在研發工程師評估出來的時間基礎上，乘以1.5-2倍的係數，得出來的真正工作量時間也是相對靠譜的。
正確管理需求變更
有一句話說：唯一不變的是變化。項目過程中需求變更是非常常見的，而且是一定會存在的。作爲項目管理者，對需求變更這個事情要有正確的認識。有些項目管理者對客戶說，不允許變更，否則項目就延期。這樣的做法可能可以保證項目按時交付，但客戶滿意度就很低了，因爲客戶的需求沒有得到正確的處理和滿足。
我的建議是這樣：跟客戶要從認知上達成一致，項目按時按質量交付是最重要的，相信客戶也一定會認可這個目標。
在這個基礎之上，我們要對需求變更進行管理，根據需求的重要性進行分級。如果某個需求變更不做進去，按時交付的項目版本可能就有瑕疵或者不能使用，那麼我們就必須得把這個變更做到當前版本中。這時我們還需要去分析引起這次變更的原因，如果是我們自身的原因，那可能跟客戶講清楚後我們自己想辦法把它消化掉，如加班啊、加人啊啥的（雖然加人一般是沒用的）。如果是因爲客戶的原因引起的，那我們需要評估這個加進來的任務，對開發進度的影響有多大。需要跟客戶溝通清楚，將這個變更的需求加進來，但爲了保障項目的按時交付，需要從原有功能列表中減掉一部分優先級低的功能需求。
那些從當前需求拿出來的，或者變更部分不影響當前上線的，也需要排一個功能需求優先級，告知客戶在確保這次按時交付後，會根據優先級順序將這些需求功能儘快處理掉。
只要將這些原則性的東西跟客戶溝通清楚，一般客戶都是能理解的。
希望這篇文字能給你的項目帶來一些幫助，能交付的產品永遠都比完美的產品更有價值。