#yyds幹貨盤點#如何減少項目延期

項目為什麼容易延期？

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

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

基于我自己的經驗，我覺得項目延期還有以下兩個方面的原因：

‍2、工作中的突發事件多

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

3、協作之間的耦合性高

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

工作中常見的延期原因

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

需求變更，一般指新增需求或者需求細節一直在變；
需求評估的工作量不足，低估了功能實作的難度；
需求了解不對，功能做錯了。等最後測試或對接的時候才發現；
有臨時需求插入。比如線上突然出現了一個bug，需要修複；
新需求本身存在邏輯問題，做之前都沒發現，在做的過程中才發現。
自測不仔細，測試發現問題太多，bug越改越多；
臨時人員變動；
偏離計劃後沒有做好應對措施；
技術難點調研出了問題，實作方案得改；

......

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

如何解決項目延期問題？

這是我應對項目延期的解決方案：複盤 —— 找問題 —— 拆解問題 —— 制定解決方案 —— 疊代 —— 複盤

1、複盤，找問題

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

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

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

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

解決項目延期的關鍵三要素

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

一、項目開始前：需求管理

項目開始前的需求管理有四個關鍵步驟

1、達成需求優先級排序的共識

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

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

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

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

2、弄清楚需求的目的

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

讓所有人參與其中，發揮團隊所有人的價值，通過集體共創可以獲得更好的解決方案。
在事後，我們可以很清晰的看到，我們做的功能是不是往目标更前進了一步。如果沒有。那麼複盤的時候，能更有指向性的去找問題的原因。

3、弄清楚需求細節

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

代碼的世界裡隻有0和1，沒有随便。産品在給我們講需求的時候，并不知道系統的具體實作。有些細節他也不知道。這會導緻很多需求在做的過程中有很多細節需要反複确認，如果做的不好，很多細節問題都會在測試的時候展現出來。舉個例子，當産品說我們這次做一個活動，使用者下單滿29包郵。看起來很簡單的一個需求，但如果你系統足夠複雜，開發人員應該要想到，跨店的情況怎麼辦？含虛拟商品怎麼辦？如果店家設定了其他活動，沖突了怎麼辦？需求後期會不會變成49包郵？如果這些在評審的時候沒有想到，那麼在做的過程中一定要和産品保持溝通。有些新人剛來的時候不好意思問，其實沒啥，每個人都是這麼過來的。這種能力是需要時間積累的。

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

評估的工作量會跟精準。
更早的發現需求裡潛藏的問題。

4、輸出完整的項目上線計劃表

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

異常情況

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

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

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

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

二、項目開始中：過程管理

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

1、每天都開站立晨會。

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

首先團隊之間達成共識。明确晨會的目的是協同，而非彙報。每個人時間就2分鐘。控制發言時間。
确定彙報的内容。每個人講講當天的計劃和實際進度是否一緻。是否遇到了什麼問題，是否需要什麼支援。
固定發言順序，發言過程中，其他人不評論，不解答。具體的問題等到會後在找相關人員一起讨論。
晨會的主持人很關鍵，他需要控制流程和時間，對于偏離主題的發言要給予提醒。
最後就是要做會議紀要，隻記錄某人遇到的問題或請求以及整個項目的進度是否正常。

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

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

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

2、如果是跨部門協作，每日要進行"對表"

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

3、關鍵節點的跟進。

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

4、制定異常問題的處理機制。

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

5、建立自己的問題清單庫。

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

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

三、項目結束後：對項目做複盤。

複盤會：全員參與

做的好的，要想辦法将其标準化、可複制。

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

防止項目延期的幾個方案

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

1、大項目要分階段轉測試。

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

2、預留測試時間

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

3、制定常見異常情況的處理标準。

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