如何避免 IT 項目延期？

12-17

最近收到一個問題，就是當你作為項目管理者，可見到項目必然延期，但是又不能延期的時候，如何處理？

我給出的答案是拆分，把需求拆分細化，然後將一部分主線功能先完成，在時間內講主要功能上線，然後再做二期講其他功能做完。

這是我能想到的最好辦法了。

置於加班，當加班也無法避免延期的時候，談不談加班沒有意義了。

我想問的是，還有沒有更好的辦法控制項目不要延期？

項目延期，一般來說問題就是你按照當前項目需求製作的計劃，因為溝通原因（首要），需求變更，工作量估算偏差，項目的組織管理，突發事件等原因造成了。
先說預防就是如何避免：
溝通管理：和客戶溝通前要制定好溝通管理計劃。基本就是who和誰交流：接洽人員還是最終老闆；when什麼時候交流：每天，還是每周；where在哪裡交流：網上還是線下；what交流什麼內容：需求，進度；how怎麼交流：面對面說人話還是通過互聯網打嗝；另外要按照計劃給客戶展示進度，尤其是那些逆轉成本很高的功能節點一定要及時反映。並且這些節點是要在合同里體現的不然只能吃啞巴虧。
需求變更管理： 需求變更一般都是溝通不當造成的，老闆沒有跟接洽員說明白，接洽人員沒有跟項目負責人說明白，項目負責人沒有跟產品經理說明白，產品經理沒有跟設計和程序員說明白。除此之外還有一些市場因素和異想天開。合同里必須要有變更管理的，變更是有成本和代價的不是你說想變就能變的，這都要加錢加時間，不過賣個人情，多給點時間不麻煩的給變更，麻煩的就再商量吧。
工作量估算偏差：IT項目工作量估算基本靠經驗，具體辦法可以去看《人月神話》，諸如增查刪改等一些常規業務邏輯或者你的IT項目可能是運維方向的，機房布線，伺服器維護等等。這樣常規類的都是可以控制和估計的，但是如果是一些你的開發團隊沒有做過但是設想上是可以實現的業務，估算此類業務肯定是會有偏差的。同時既然是估計的時間那麼合同里一定說明了項目完成時間和項目交付時間。完成時間和交付時間可是兩回事，完成說的是基本業務的完成時間，交付是你驗收和調整的時間。你要是沒說就定一個時間人家說啥都有理。工作量估算的時候一定要給自己留有餘地免得雙方都難受。沒人願意加班。
項目的組織管理：你可以管理不好人，但是不能管理不好死的業務和制度。項目延期也很有可能是你的開發團隊都不好好乾活，不好好乾活的原因很多，利益不和諧啦，公司政治啦，溝通問題啦。這裡溝通問題其實最值得注意，一定要為項目成員建立良好的溝通機制，項目開發過程也要有相關的記錄，不然替換關鍵人員的事情就無從下手了。軟體開發為例子你就可以把你的項目團隊想成一艘海盜船，大家要去干一票買賣，作為船長（項目經理）你得讓船員信服，找到寶物位置和制定好尋寶計劃，碰到寶物的時候你要讓大副（助理）幫你出謀劃策，讓領航員（產品）配置好所有需要的資源控制方向，讓水手長或者舵手（架構師）帶著水手開始幹活。當然這其中有很多重疊工作。千言萬語一句話，沒有金剛鑽，就不要接瓷器活。
突發事件：其實宏觀來說控制好上面3條就可以了，圍觀了講可以寫論文了。突發事件一般就是人員流失，架構師家生孩子，自然災害等項目經理或者公司制度無法控制的情況發生。但是你要在時間上余出你不可抗拒的事情發生的應對時間。

其實廢話有點多，讀過項目管理相關書籍的話應該理解，避免項目延期是項目管理意義的一部分，管理的不好肯定延期，項目管理的內容遠不止我說的上面幾點，項目大小不同應用方式也不一樣。
如果已經延期了怎麼辦？
延期這種事情理論上就不應該發生，發生了的話如果客戶沒有需求變更或者溝通問題和財務問題，基本上就是你們開發團隊的問題，這時候你們只有兩種選擇
1.毀約賠錢不幹了。2.跟客戶溝通說明問題緩一緩。
根據我的項目經驗來看一般來說都是第二種，因為你項目延期肯定是開發了一段時間才發現的，這時候客戶已經浪費了一定的時間成本了。如果變更開發團隊成本比較高，為了保持成本只能給你們提供支持。（如果成本比較低大家沒必要還糾結來糾結去或者讓你賠錢什麼的，客戶或者BOSS保本少賠就OK）。如果你們團隊是有實力的。溝通緩一緩使用變通方案（砍功能或者加班）肯定行一般客戶都會理解，你的IT解決方案大家都會理解，像魔獸世界這種版本更新也有延遲上線呢！！！！老闆還能扣運維團隊工資不成？（扣工資讓你分分鐘當機）問題最終解決了就好。當然也可能存在那種毀約收賠金的。至少我沒有遇到過。
如果是因為需求變更這樣的原因延期怎麼辦？
合同里白紙黑字都寫清楚了如果變更怎麼辦？按照合同辦事。如果是公司內部需求，就用公司內部機制解決？什麼？你們單位發項目的時候沒有延期機制？那還是得跟客戶或者領導商量。無非也是兩種辦法。1.加班。2.砍功能二期在上。關鍵問題是加班根本不是解決問題的辦法！！！有木有啊！！！
這個事情很簡單IT軟體開發的話我們都是智力價值輸出，成本給出來了我沒法回收。合同里大家說明白，我給你項目工期時間（時間給不準說實話最好別管項目~）你給我定金，我再給你幹活，完成不了和不熟悉的功能根本不承諾，誰NB能做出來你就找誰去，人命關天的事情我不接，如果不是人命關的事情都好商量，定金都收了反正我不會返還，你急什麼？

延期不是什麼大事，關鍵是你解決不了客戶的問題才是丟單的主要原因。

砍需求。先做重要的，不重要的放到下個版本。理想的做法，但理想和現實往往有一定差距。

Quick and dirty。先讓它看起來能用，以後再改。不得已的做法，現在欠的，以後要加倍償還。大家都知道不好，卻很常見。

加人。最直觀的做法。雖然《人月神話》中說加人沒用，但如果項目文檔好，耦合低，可進一步分解任務，加人還是有相當的作用的。再說，老闆也沒別的辦法。

加班。作為程序員，這顯然是最不人道的做法。但在現實中，這往往是最有效，最安全的做法。所以，很不幸，也是最常見的做法。

還有一個比較另類的做法，PM找出需求中隱含的矛盾，要求客戶明確需求，強調問題嚴重性，以此為籌碼要求延期。

贊同@mu peng的回答。
補充一點：通常遇到延期風險的時候有兩件事情要做：
1.避免項目延期
2.避免承擔不應承擔的延期責任。
* 如果責任不在於你方，這個時候「讓責任方自己承擔延期責任，並提出延期解決方案」就是好辦法。

將你預想的工期延長1.5倍-2倍，我是認真的。

1.梳理需要實現的每個功能點，是否存在誤解或者盲點
很多時候，對功能或業務流程的錯誤的理解是最終導致在開發上花費過多時間的根本原因。Coding最大的敵人是：自己認為自己懂了，然後死命按照自己的思路去實現，也許一切本不該如此。在這點上，盡情的和PM溝通，明確每一個需求。了解後，最好能用自己的理解在口述回去，以達到雙重確認。

2.明確現有進度，重新安排優先順序
PM需要考慮，客戶/用戶最想在這個版本看到什麼，最想體驗哪些功能。按照模塊重新排定優先順序，然後用剩下的時間全力去滿足客戶最關心的功能點需求。另外，個人建議可以通過在UI上展現一定的專業性和產品價值，用於彌補功能上的缺失。另外，做好空白或者屋內的默認頁面，也會另人感到專業許多。

3.了解各模塊進度慢的原因
是否因為非必要的10%功能而導致了90%功能的延誤；或者存在功能的誤解（同1），是否在實現中發現了更好的解決方案？是否是實力所致？是否有生活中消極的因素影響？找到真正的原因，才有助於問題的解決。

4.勇於砍砍砍
放棄一次性打造完美產品的念頭。要勇於扔下阻止前進甚至關乎生存的一件件「貨物」。在做這個艱難的決定前，至少你已經通過第2點裡面提出的方式有了明確的優先順序排期，大膽的「砍掉」那些優先順序不高的功能吧。

5.保持文檔/代碼的一致性
世界上最遺憾的事情，就是在Coder按照功能大幹數個小時候卻被告知，這個功能已經改變/取消了。此時出現「人命」也不足為奇了。保持步調和戰略的統一，是走向勝利的基本要素。各種文件版本的變動一定要保持一致，並且最好有更新記錄。Coding中利用Git可以很容易做到這一點，但文檔的更新恐怕就要多費一些功夫和口舌了。

6.和客戶真誠的溝通
不要瞞到最後一天，項目預警機制的存在不能是擺設。良好的商務合作前提是彼此尊重和理解，在當今社會各種情況導致項目延期其實都是可被接受的。客戶可以接受延期，但不可接受遙遙無期的延期和臨近末尾的恍然大悟。及時的溝通可以始終讓客戶和自己站在一起。當然，預警也要講究方式方法，只說壞消息也會讓客戶崩潰，一定要給出明確的時間節點和解決方案，讓客戶心中有數。要讓人給耐心，先給耐心一個落腳點。

目標：進度可控，質量保證，內部評審

大概思路：
第一步，找出最核心的需求，排序並分解之，採用合適的單位，量化之。

第二步，測試出一個適合團隊的開發進度，定期評審之，盡量提高。
- 持續輸出，是指有一個可靠、穩定的成果輸出。需要合理的機制來保證輸出的不是垃圾，比如，代碼要評審，版本管理要科學，加強內部的知識共享，迭代的第一個版本就要基於實際的使用環境。。。
- 團隊成長，我們是在搬磚，但希望能搬的更好一點。要平衡成長與輸出。
- 合理評估，基於工作量的量化，基本能合理評估團隊成員的工作。

第三步，儘早拿出一個可以用的版本，用迭代的方式，不斷添加實現的功能。定期跟客戶評審溝通，擁抱需求變更。

如果有人感興趣，再展開來詳細談。。。

稍微複雜一點的項目都避免不了。
回想一下我參與過的項目，一個月內的小項目不多說，自然大部分都能按時完成。但是三月以上的項目，只有兩個按時了：1是搜狐奧運，那是沒辦法，8月8日之前必須上線，全員不睡覺都得上。2是淘寶旺店，帶著bug上線，邊收錢邊打補丁。

項目管理不是單方面的執行，而是多方訴求的協調平衡；凡是計劃都可能存在與實際偏離的情況；計劃是標杆，但不是結果。

項目進度成功執行的一些因素：
1、客戶提出的需求與研發團隊理解的建設目標一致；
2、研發團隊成員穩定；
3、不修改或者增加額外功能；
這樣的理想狀態，對於研發團隊來說才能稱之為計劃；任何一項的變動，都會引起項目計劃的修訂。

項目進度延誤的一些原因：
1、需求偏差；項目參與人員，無論是哪個角色對系統建設理解出現偏差，都可能會將帶來軟體災難。尤其是想法不固定的甲方，今天拍腦袋想一個方法，明天又要改另外一個流程；針對這樣業務不成熟的項目建設，建議多耗點時間在需求論證上，梳理清晰了再動手也不遲。當然，如果資源允許的話，迭代開發會是適合的方式。
2、成員的不穩定；一般的開發公司不是負責一個項目，研發團隊成員個個都是身兼多職的多面手，今天哪個項目借調一下，明天哪個功能模塊bug需要處理一下，開發時間就難以保證了。
3、未來是未知的；如何應對需求的變化，每個人都有自己的見解吧。建議多和用戶溝通，把握核心用戶需求，逐步滿足功能建設。但需求變更對進度的影響一定要和客戶溝通清楚，達成一致意見。

收藏，慢慢答。
脫離具體項目目標談如何避免延期都是耍流氓。

先說題主的辦法，先上關鍵重要功能，其他第二次再上。相信現實項目上用這種方法的估計也很多吧，根據我個人的經歷，一般都被虐的很慘。必須上的一般都是政治任務，過了那個節點，你以為客戶還會那麼配合你。

至於其他的砍需求、加人加班什麼的。因為辦法本來就只有這些，聽完之後還是不知道怎麼辦。

我個人的理解，延不延期不是主要問題。話說，我們真的不知道延期到底是怎麼來的嗎？

談需求的時候，沒人說得清楚。確認需求的時候，找不到人。申請開評審會，人老是湊不齊。一般什麼時候才能搞清楚客戶的真實需求，測試的時候。上線前還說某個功能可以換個方式做。有些甲方，真的是夠了。

再看我們自己這邊，一個項目經理帶著幾個兩年經驗的，再帶一群生瓜蛋子。承諾的業務專家不過是蜻蜓點水，是在沒有多少時間可以給項目上一些具體的指導。就這，老闆還老是覺得人太多，幹活太少。

這樣的情況，不延期才怪。你以為客戶不知道這一點嗎，老闆不知道嗎。naive。如果不嚴格要求，更不知道延期到哪去了。他們理解的管理，不過是矯枉過正罷了。事實上，最終每個人都不滿意。老闆覺得預算超了，客戶覺得項目延了，項目員工覺得累的要死了。

回到項目目標上。一般乙方目標主要有兩個：（1）借著這個項目打磨產品或者團隊。這種情況並不多見。（2）結項收款。

再看題主的辦法。第二次啥時候才能上線，客戶在第一次上線後悔提出多少修改。根據我個人的經驗，這些東西一般都會卡住收款，尤其是收項目驗收和結項的款。

這時候，不管你延期沒延期，老闆肯定是對你沒好臉色了。

反觀客戶方的目標，也主要有兩個：（1）推動管理升級，提升競爭力。這個也不多見。（2）如果項目在考核任務里，不要影響績效。

為啥給的政治任務一般都能完成，績效卡著呢，或者高層實時關注著。辦法都是人想出來的。完成也是必須得。

綜合甲乙雙方的目標，如果能夠很好的結合起來，雙方都使勁，那就是良性的。否則扯皮的事肯定也不斷。

所以，和老闆就談結項、收款，要求資源。

對客戶，要在他緊急的時候，請他幫忙妥協一些需求或者簡化流程。在著急的時候，都不願意實質性幫我一把，那平時就更不要想了。這個也是檢驗你們關係到底有多牢靠的時候，是面子之交，還是別人願意幫你。

至於怎麼談，一看公司地位。小公司，求客戶吃飯的那種，就比較難談。而看顧問層次，沒辦法和客戶中高層溝通的，一般也不好談。小鬼難纏，而且做不了主。

把產品經理其中一個職能獨立出來，項目管控，專門負責把控項目質量和時間的，強人在此站樁，效果一定明顯。

項目延期的情況在很多開發團隊都會發生，所有人都想避開，然而經常是發現怎麼都避不開。
從理論上來講，其實無外乎這幾個關鍵因素：總任務量、人數、人效、截止時間點，和需求把控。

總任務量不用過多解釋，就是一塊大蛋糕。
人數是吃蛋糕的一共多少人。
人效是有的人吃得多，有的人吃得少，這種差異也不要忽略。
截止時間就是5秒鐘吃完還是5分鐘吃完。

理論條件大家都懂，但很多時候就是沒有辦法很理想：
除了上述條件，還有很多意外情況：
1，蛋糕是不是大家看上去那樣？也許裡頭是「實心又難咬的壓縮餅乾」呢，這時候評估工作量既要考慮時間長度也要考慮複雜度。
2，也許兩個壯漢可以迅速吃完一塊大蛋糕，但突然有人牙疼吃不動了....所以開始評估項目時候也要考慮人員的動蕩程度，有沒有人要提前請假、人員家中最近有事情，請假幾率較高等，提前預見，可以增加一些後備人選降低這種風險。
3，曾有做飛行員的朋友說過，最要命的是組織上給立不可能完成的任務，很多軍事飛行事故大都是因為立不可能完成的任務而產生的。所以定蛋糕2秒吃完的人簡直就是可恥，直接答應的人相信心裡也已經做好各種咬舌頭的準備了吧。
4，這點的比喻可能會噁心一點，有時候吃蛋糕吃一半，會被要求吐出來重新吃；有木有，需求頻繁變更，會讓之前做的很多事情變得反覆而沒意義。所以需求把控這塊很重要。

可以影響一個項目的延期的因素還是蠻多的。隨著閱歷的增加，更多的做好前期的plan，對後面的執行會十分高效有幫助，前期可以做的事情包括：
與stakeholder溝通好時間（多要一些時間）
與業務部門確定好意境梳理完成的需求（提前發現冰山更大的一角）
與團隊里成員溝通好整個計劃，明確責任（不要出現做不完也無所謂的態度，增強大家緊迫感、提前溝通請假情況）
切分任務，根據不同人員能力分配不同的任務

在執行過程中做好：
項目進度把控
有亮點的彙報（不要覺得悶頭做事就行，很多時候老闆前期對吃蛋糕信心滿滿，做著做著也會有懷疑態度閃爍）有亮點的彙報不僅可以增強老闆的信心，也會減少老闆因為不自信而引發的需求變更。

希望能對提問有所幫助^_^

做項目延期很正常，我們先分析一下延期的理由

1：時間充沛：根據技術和測試評估的時間合理安排項目規劃，時間不夠的時候，就排優先順序；

2：考核制度，懲罰有度；（強烈反對將項目按時完成作為技術團隊的 KPI，這是最傻的做法之一——絕大多數情況下，都不會有好效果！！)

3：持續跟進；（其實天天在開會跟進好吧，每次都說按照計劃在走，沒有任何問題）

其實我覺得忽略一點：就是那些能力有問題，態度還有問題的人，這種人我也聽身邊的管理朋友抱怨過，但是這種問題肯定會出現在很多公司。

我們通過很長時間的磨合總結出這樣這套實踐方法，目前來說還是是很有效的！

1. 縮小項目粒度（目標細化，細化，細化）

早期我們產品排期基本上一立項就是長達兩個多月的大項目，但往往發現時間非常不好控制。因為項目周期越長，想不清楚的東西就會越多，中間的變化也越多，失控的可能性就越大。所以我們做的第一件事是試圖控制時間長度，讓每期項目的粒度儘可能地小一點。小到什麼程度呢？慢慢地去摸索

2.通過看板和每日立會溝通

立項的時候要有一次全面溝通，項目過程中則通過每日例會溝通項目進展。例會花不了多長時間，但是起的作用很大。一方面可以避免有些同事在項目過程中沉浸在自己的世界裡，方向走偏了自己沒有發現。另外一個作用是能幫助大家克服人性上的懶惰因素，在每天彙報工作進度中給大家形成適度的壓力。另外看板也是非常好用的一個，可以使用Teamin或者很簡單地在玻璃上貼任務便利貼，每天對著它開會。

3. 平和應對搗蛋鬼「緊急事項」：評估、推遲 / 立即處理

項目中總會不可避免地遇到緊急事項，比如說網站掛了，一處理就一天時間進去了，原先手上的項目就只好拖延一天。這樣的緊急情況，如果不加以控制的話會出現非常多。一個簡單的原則就是凡事先評估，判斷是可以先推遲還是必須要立即處理。

從原理上說，項目實施是一個不斷平衡（banlance）的過程，平衡什麼呢？基本上是四個方面：範圍、時間、人員、質量。固定時間、人員、質量三要素。

在立項時就固定項目時間長度

固定項目質量要求：給測試工程師留足夠的時間

固定項目成員：「外科手術式」的精幹團隊，人員固定，分工固定，協作方式也固定

只留範圍一個可變的要素：立項時確定開發的範圍

同時做好裁剪準備，底線要開發完成的 feature 是幾個，如果時間失控要砍掉的是哪一項。

」睡你麻痹，起來幹活」

加班加點。少睡覺