項目管理：如何避免項目延期

在項目的整個週期中每個流程都有可能導致項目延期，所以把控好每個環節，找到自己在每個環節中的驅動力才是產品經理解決項目延期問題的根本。文章將圍繞以下4點原因展開討論如何避免項目延期。

哪些原因會導致項目延期？

1. 產品需求經常變動

對於產品需求經常變動，我們要問自己3個問題，產品需求為什麼會經常變動？需求經常變動會產生什麼樣的負面影響？我們要採用什麼樣的處理方法才能避免需求經常變動？

產品需求為什麼經常變動

產品需求經常變動的原因：

1、前期思考不到位，把問題想的太簡單以至於好多細節和邏輯沒有考慮進去，到開發階段才發現諸多問題，從而不得不增加需求點或者更改原需求。

2、技術調研不到位，自己認為可以做的功能在基於系統現在的支撐時無法按時間迭代出來，導致只能使用替換方案，變更需求。

3、前期制定的方案對需求的理解有偏差，經過後期的對接和溝通發現理解錯誤然後變更需求。

需求經常變動將產生什麼影響？

需求是為了解決產品或者市場中某些問題和漏洞而產生的，所以所有的需求對整個產品而言一定是有正向意義的。在產品的生命週期中，需求的確定是第一流程。

如果需求經常變動會導致產品設計，開發邏輯和測試用例的重構或者已完成的工作量作廢清零。變更需求的次數越多導致團隊的整體工作量增加，時間卻在減少，自身和團隊的工作壓力就會越大，當壓力過大時，經常變動需求就會很容易使團隊和諧受到衝擊，久而久之會讓團隊質疑產品經理自身的工作能力，降低產品經理在團隊中的公信力，自己也會質疑自身的工作能力，產生不自信的表現，形成惡性循環。

案例：

之前在觸摸屏終端做了一個橫向版不可滑動的時間軸功能，任務時間段接近時會導致文字顯示不全，但還是堅持把這個需求做了下來，時間軸的展示邏輯，前端開發和測試都投入了很多精力。但是後來用戶反饋說那個時間軸完全用不上還是做成列表更實用一些。覆盤的時候總結了問題最根本的原因是臆想了用戶的使用場景，沒有和用戶充分溝通，導致需求重做，工作量增加，和前端同學也產生了一些摩擦。

我們如何避免需求經常變動？

1、使用工具輔助梳理邏輯：當面對邏輯複雜的模塊時可以使用腦圖和流程圖輔助梳理邏輯，以安防應用其中一個小模塊為例，可以使用腦圖和流程圖輔助梳理邏輯，避免有遺漏的數據，功能和邏輯。

案例-工具輔助：

2、極值思考：即當產品中的數據為0或為最大值時處理的邏輯應該是什麼。為避免邏輯，頁面和功能的缺失，採用極值條件思考，將產品中產生數據的地方統計總結並且做出數據值為0或最大值的假設來校驗需求是否有缺失。

案例-極值思考：

如知乎的稍後答功能，當數據為0時，展示空頁面，並引導用戶查看推薦的問題。

3、前期技術調研：為了避免已經制定的需求因為現有資源和特定時間段內不能完成的情況，需求、方案要和團隊進行充分的技術調研和溝通，可以上網查看相關的資料，和技術人員多討論多溝通，確保方案基於現有的技術實力和可控的時間範圍內是可行的。

4、需求調研：對比競品，做市場調研和客戶進行充分的溝通，可以先和客戶講解自己的設計方案，確保需求是真實的，並且能夠解決用戶面臨的問題和痛點，保證自己對需求的理解是正確的。

2. 客戶臨時加需求

客戶臨時加需求會產生什麼影響？

當客戶臨時提出增加需求時，若人員數量不變，則時間成本增加，或者是增加項目人員數量。無論哪種方案無疑會使項目的成本增加，團隊壓力變大，當項目收入大於支出時會造成項目的資金虧損。

接手過一個類似的項目，為快速滿足客戶提出的需求而投入過多人員，導致項目接近完成後大批量的裁員，而根本原因就是項目的投入和產出比例失調，為保證項目的收益只能縮減人員。

何如對待客戶臨時增加的需求？

1、獲取真實需求：為了避免後期需求變動或者大家加班加點做出的功能不符合預期，被全盤否掉的情況發生，當遇到客戶臨時增加需求時更加需要和客戶確定好他的真實需求。和客戶盡行充分的溝通，為便於客戶能夠直觀理解設計方案，可使用圖文並茂的講解方式。如果有條件最好處於客戶的使用場景中，體驗客戶使用的痛點從而挖掘出客戶想要的功能。

2、替換需求：在保證客戶正常使用產品功能的前提下，為了更加合理化的分配項目資源，可以基於產品現有邏輯和功能合理的替換客戶提出的需求並提供原因和解決方案。瞭解客戶想解決的究竟是什麼問題，綜合系統現有資源比對哪幾種方案可行，並提供出性價比最高的解決方案。

3、需求閹割：為了將核心需求在一定時間內做到最好的效果，將需求劃分優先級並將優先級較低的需求暫時放在下一版本中，利用系統現有資源，採用邏輯簡單，較易實現的方案，這樣付出成本小，效果達到了，如果方向正確，後期可進行迭代優化。

3. 風險預報週期太短

風險預報週期短的原因是什麼？

1、重大問題發現的時間太晚，或者臨近發版時發現一堆問題，導致無法及時處理問題從而影響發版。可能因為在團隊協作中缺少充分的溝通，比如團隊對需求的理解不清晰，對需求的優先級沒有掌握或者是bug堆積，測試打包頻率不夠等等原因都會導致這種情況的發生。

2、需求沒有分優先級,研發進度沒有安排好，將所有的需求按照相同優先級去處理，導致優先級高的任務沒有按時完成。

3、工作流程出現問題，缺少有效的處理機制，同一問題經常發生時很可能是流程上出了問題，這時應該自下而上去完善缺少的處理機制。

可以思考一下在研發和測試兩個流程中，產品可以驅動的方式有哪些呢？

1、每天跟蹤項目進度：為了及時掌握和處理項目在開發階段遇到的問題，在研發過程中，可以將需求按照前後端的分工拆成小的功能點，定好開發的人員和時間，每天跟蹤進展。當一個小的任務有延期時可以一起評估延期風險，有必要時可以重新調整人員分配，如開發人員遇到技術難題可以開會討論最優解，當實際任務量和預計任務量有很大差距時可以及時調整。

2、產品功能驗收：當開發人員完成一組功能時，產品可以先去驗收這一組功能，如果產品設計有問題時可以及時改正，如果研發實現有問題時也可以儘早修復bug。可以減少產品質量驗收時的壓力和工作量，bug可以儘早處理，發現邏輯有問題時也可以儘早改正，對產品的質量和項目的進度都有正向推進的作用。

3、制定需求優先級：在測試過程中可以將需要測試的功能模塊分好優先級（一般按需求的優先級來），先測需求重要和邏輯複雜的模塊，避免發版前出現較難解決的故障。研發人員修復bug時，也應評估bug的優先程度去修復。

4. 臨近發版才發現某一功能與需求不符

這點和第三點-【風險預報週期太短】有重合的地方，在發版前發現功能實現或邏輯和需求不符這種情況雖不常出現，但是一旦發生，那麼項目面臨延期的風險將大大提高，所以單獨把他列為第四點討論解決方案。

造成這種問題的原因是：

1、文檔闡述不清晰或者不詳細，導致不同人理解之間的偏差，比如文檔說明支持拖動排序，但沒有寫具體的排序方法是替換排序還是順序排列，導致有A，B兩種實現方式，產品認為使用方案A，開發理解的是方案B，產生理解偏差而且問題還不容易被發現。

2、產品，研發和測試人員沒有充分的溝通，各自都以自己的理解去想問題，是第一點的衍生情況，當文檔已經產生歧義時，又沒有線下的充分溝通才會導致需求和實現的功能不符。

3、沒有功能驗收，功能完成後，產品同學沒有去驗證是否和自己要求一致，可能是公司沒有設置這一流程，但是產品同學做好功能驗收可以把最嚴重的問題在第一時間暴露出來從而可以及時改正。

產生的影響

這種重大的失誤不僅會導致項目延期，還因為涉及的人員過多導致相互甩鍋影響團隊和諧，引發團隊矛盾。因為功能不能按時準確的完成，往往需要其他的方案或者更多的時間來補救。

所以如何避免這種情況的發生尤為重要

1、優質的需求文檔：將產品文檔寫的詳盡一些，簡單易懂的描述自己想要的是什麼，如果語言組織上出現問題時可以參照市面上已有的功能，轉化成口語形式去描述。

2、團隊溝通：和研發，測試人員充分溝通，確保他們理解你想要的功能是什麼樣的，可以用原型輔助演示自己想要達到的效果。

3、產品先驗收後測試：產品經理可以在開發人員開發完成後，測試之前，先驗收功能的一致性和邏輯的正確性，保證產品的走向是正確的。如果在錯誤的基礎上進行測試，那麼就浪費了員工的精力，時間，最終還沒有達到預期的效果。

4、質量驗收：在測試完成後進行產品的質量驗收，此時的產品應沒有重大，明顯的bug，產品主要是對頁面的美觀度，操作的流暢度進行驗證，驗證無誤後即可進行發版。

總結

希望產品同學多以自身為驅動力，找到自己在每個環節中的問題才能找到自己能做的解決方案。

本文由作者@The big brother 在PMCAFF社區發佈，轉載請註明作者及出處。