專案延期在產品經理的工作生涯中是再常見不過的問題，但延期意味著某項環節出現問題，對後續的運營等動作也會有影響。如何能儘量避免專案延期呢？本文作者對此進行了分析，希望對你有幫助。

一、專案為什麼容易延期？

1. 軟體研發是一項創造性工作

專案延期是一種普遍現象，管理者最為頭疼的一個問題。但是外人並不理解。明明是你們自己做的計劃，怎麼總會出現這麼多問題。說到底，這是由於我們的工作特性決定的。我們做的是一個創造性的工作，他不像建房子，有特定的步驟。我們實現一個功能，怎麼寫，有多少行程式碼，我們在寫之前是不知道的。

基於我自己的經驗，我覺得專案延期還有以下兩個方面的原因：

2. 工作中的突發事件多

我們在評估工作量的時候，都是基於過往的經驗。這種經驗性評估在真實環境中並不可靠，你無法應對突發問題，而我們真實開發的過程中突發問題太多了。

3. 協作之間的耦合性高

技術人員工作的耦合性太高。從最開始產品經理提出需求、UI設計原型、UE設計體驗、程式設計師做系統設計，寫程式碼、測試人員編寫測試用例。環環相扣，其中一個環節出了“意外”，時間就得往後延。

二、工作中常見的延期原因

我這裡列了工作中常見的延期原因：

需求變更，一般指新增需求或者需求細節一直在變；

需求評估的工作量不足，低估了功能實現的難度；

需求理解不對，功能做錯了。等最後測試或對接的時候才發現；

有臨時需求插入。比如線上突然出現了一個bug，需要修復；

新需求本身存在邏輯問題，做之前都沒發現，在做的過程中才發現。

自測不仔細，測試發現問題太多，bug越改越多；

臨時人員變動；

偏離計劃後沒有做好應對措施；

技術難點調研出了問題，實現方案得改；

……

那是不是我們就沒辦法了呢？也並不是。方法總比問題多，只要所有出現的問題都有應對方案，準時上線也是可能的。當然面對複雜問題，想一次性解決很難，但好在我們可以迭代。每一次專案結束都應該對專案做一次覆盤。

三、如何解決專案延期問題？

這是我應對專案延期的解決方案：覆盤 —— 找問題 —— 拆解問題 —— 制定解決方案 —— 迭代 —— 覆盤。

1. 覆盤，找問題

覆盤：上一次我們延期的原因是什麼？把問題原因找出來。比如上次是需求變動導致的。

2. 拆解問題，制定解決方案

接著就是拆解問題。為什麼需要變動？因為這個功能更重要。這是答案是真的嗎？這個功能真的很重要嗎？好，是真的。那麼評判標準是什麼？如果沒有。那麼我需要制定出來。有了標準，下次遇到新增需求，我們就能很快決定是否加入到這個版本里。好，我們還可以繼續拆，是新增需求導致的延期？對，因為新增需求而且並沒有修改上線時間。那我們下一次面對新增需求是不是可以對外爭取更長一點的開發時間？

這個方法的優點是，每次進步都能感受的到。缺點是，時間週期太長。但好在，我們別人的經驗是可以學習的。別人趟過的坑，我們沒有必要再趟一次。

四、解決專案延期的關鍵三要素

基於我多年的專案管理經驗，我認為要解決專案延期問題，必須做好三件事。

1. 專案開始前：需求管理

專案開始前的需求管理有四個關鍵步驟。

1）達成需求優先順序排序的共識

首先，我們要達成給需求優先順序排序的一個共識。什麼樣的需求是最重要的，一定要完成的？每個公司可能不一樣。我自己是基於商業價值和使用者價值兩個維度來排序的。

商業價值，就是那些直接給公司帶來利潤，能夠降低運營成本、完成公司長期戰略目標等功能。而使用者價值是，那些能夠提升使用者體驗、提高使用者使用效率，解決使用者痛點問題的功能。

基於這兩個維度，我們可以畫一個四象限圖，把我們所有的需求按照商業價值、使用者價值兩個維度給歸類到不同象限裡。對於商業價值高、使用者價值高的產品。我們應該馬上去做。至於優先順序排第二的是商業價值高、使用者價值低的需求；還是商業價值低、使用者價值高的需求，要根據公司實際情況來定。

為什麼要給需求分優先順序？時間有限，要做的功能太多。如果根據商業價值和使用者價值拆解後，還有很多需求，我們還可以繼續用重要緊急兩個維度來拆。

2）弄清楚需求的目的

達成了共識後，第二步就是在需求評審時，要求產品先講解需求的目的。不只是說明我們要做什麼，還要說明我們要達到什麼目標。這樣做有兩個好處。

讓所有人參與其中，發揮團隊所有人的價值，透過集體共創可以獲得更好的解決方案。

在事後，我們可以很清晰的看到，我們做的功能是不是往目標更前進了一步。如果沒有。那麼覆盤的時候，能更有指向性的去找問題的原因。

3）弄清楚需求細節

第三步，就是開發者需要弄清楚需求細節。每一個開發人員都應該養成這樣一個看透細節的能力。

程式碼的世界裡只有0和1，沒有隨便。產品在給我們講需求的時候，並不知道系統的具體實現。有些細節他也不知道。這會導致很多需求在做的過程中有很多細節需要反覆確認，如果做的不好，很多細節問題都會在測試的時候體現出來。

舉個例子，當產品說我們這次做一個活動，使用者下單滿29包郵。看起來很簡單的一個需求，但如果你係統足夠複雜，開發人員應該要想到，跨店的情況怎麼辦？含虛擬商品怎麼辦？如果店家設定了其他活動，衝突了怎麼辦？需求後期會不會變成49包郵？如果這些在評審的時候沒有想到，那麼在做的過程中一定要和產品保持溝通。有些新人剛來的時候不好意思問，其實沒啥，每個人都是這麼過來的。這種能力是需要時間積累的。

需求理清了也有兩個好處：

4）輸出完整的專案上線計劃表

第四步，就是上下同步需求，生成需求計劃表。首先我們拆解需求，大需求變成小需求。然後評估小需求的工作量。輸出自己的個人計劃表。然後部門內部整合需求，輸出部門的計劃完成表。最後是與團隊其他成員生成整體的專案計劃表。一般會做成甘特圖。這樣在做的過程中更容易發現問題。

異常情況：

這四個關鍵步驟，說起來簡單，但要真正做好不容易。如果能做到，那需求管理基本不會存在大的問題了。當然也會有一些異常情況。比如需求確定後，能不能變動？一般需求確定下來後，最好不要做臨時變動。除非特殊情況。

那什麼是特殊情況？這就是制定需求優先順序規則的好處了，如果確實有更緊急、成本低的高商業價值、高使用者價值的需求。我們可以變動。只要團隊內成員都認可這個規則，做需求變動就會比較好實施。

那如果是領導不按規則變動需求怎麼辦？

誰擔責誰決策。因為站的角度不一樣，我們認為的高價值任務不一定對。這是一條職場通用原則，在需求確定做不做之前，作為專案組成員，你可以表達自己的建議，但如果最終負責人拍板要做，那就堅決執行。

2. 專案開始中：過程管理

過程管理的關鍵是要解決資訊不同步的問題。我的解決方案是：

1）每天都開站立晨會

很多人說早上開晨會沒有用，是管理者沒有其他辦法，只能透過會議來推進工作的一種表現。我倒不覺得，晨會並不複雜，也不會花費很多時間，但正是因為有了這樣一個固定”溝通“事項，每個人心裡都會想著這件事，自然會把當下的工作按計劃推進。這裡我介紹一下我公司開站立晨會的具體步驟：

首先團隊之間達成共識。明確晨會的目的是協同，而非彙報。每個人時間就2分鐘。控制發言時間。

確定彙報的內容。每個人講講當天的計劃和實際進度是否一致。是否遇到了什麼問題，是否需要什麼支援。

固定發言順序，發言過程中，其他人不評論，不解答。具體的問題等到會後在找相關人員一起討論。

晨會的主持人很關鍵，他需要控制流程和時間，對於偏離主題的發言要給予提醒。

最後就是要做會議紀要，只記錄某人遇到的問題或請求以及整個專案的進度是否正常。

開會時間推薦在正式上班時間30分鐘後，比如9點上班。9點30開始。10點前結束。備註：我公司彈性上班可以9點半到公司。

晨會能很好的解決團隊內部資訊不對稱的問題，大家能更好地瞭解到彼此的專案進度並做好配合。而且人都要面子的，如果自己制定的計劃未完成，還要自己當眾說出來沒按計劃完成的原因，是很有壓力的，這種壓力會在潛意識裡影響到自己每天任務的完成度以及專注度。

很多公司把晨會開成了彙報會，最後就變成了一個沒有太多資訊量的務虛會議。並不是這個工具不好用，而是你沒有用對方法。記住上面我說的幾個原則，相信你能組織好一場適合團隊的晨會。

2）如果是跨部門協作，每日要進行“對錶”

如果是跨部門協作。我們每天也要進行”對錶“，也就是同步資訊。

3）關鍵節點的跟進

千萬不要等到上線了在來看專案進展，這樣即使發現問題，你也沒有時間來解決。

4）制定異常問題的處理機制

所有的異常情況，都需要設計一個應對的應對方案，有了應對方案，至少解決問題的流程有了，心理就不會慌。解決起來就容易很多。

5）建立自己的問題清單庫

很多大公司都有這樣一個產品問題清單庫。客服同事在處理使用者問題時候，透過關鍵字搜尋就能找到通用的解決方案。這極大地提高了客服處理問題的效率。同樣的方式其實也可以用在開發上。也許很久之前某個同事遇到的問題，其他同事也能遇到。這種情況下，透過關鍵字搜尋，原來要花半天才能解決的問題，可能一分鐘就給解決了。需要注意的是在做這個問題清單庫的時候，一定要先定義好格式。這樣才好管理。

那是不是做到上面這些就能保證專案能準時上線了？也不一定。因為這裡面最關鍵的是執行的人。人的管理是一門藝術。這裡以後再詳細講。

3. 專案結束後：對專案做覆盤

覆盤會：全員參與。

做的好的，要想辦法將其標準化、可複製。

做的不好的，要想辦法制定應對的方案。

五、防止專案延期的幾個方案

最後，說一下我在防止專案延期上的個人經驗。

1. 大專案要分階段轉測試

不要把測試和設計工作都集中在一個時間段。版本迭代的時長也不要超過一個月。

2. 預留測試時間

開發人員每次做完一個任務後，都要預留測試時間。同時和開發人員要達成一個共識，如果開過程中出現延期，要自己透過加班時間趕上進度，不能影響其他同事的進度。

3. 制定常見異常情況的處理標準

也就是最開始講到的，如果真的有需求變更，那麼就一定要做好變更需求的標準。需求可以變，變了之後如何處理。這個也需要明確。有些是可以直接放到版本里透過加班解決，有些可以捨棄掉一些需求。儘量不在要釋出的時候做變更。

4. 做好PLAN B計劃

遇到一些突發時間的預案是什麼。比如有人員臨時請求，怎麼辦？有技術難點攻克不了怎麼辦？作為管理者需要提前想好備選方案。

5. 制定兩個釋出計劃

一個計劃是對內的，根據大家工作計劃整合之後的釋出時間，還有一個是對外上線的計劃。我們團隊要追求對內時間上線。但如果出現問題，預留出的時間就是我們的緩衝帶。當然也可以對外給出一個模糊的上線時間，比如對內9月10號上線，對外9月中旬上線。

以上，是我應對專案延期的一些經驗。希望給大家帶來一些啟發。

本文由 @石雲升 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。