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

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

1. 產品需求經常變動

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

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

• 前期思考不到位，把問題想的太簡單以至于好多細節(jié)和邏輯沒有考慮進去，到開發(fā)階段才發(fā)現(xiàn)諸多問題，從而不得不增加需求點或者更改原需求。
• 技術調研不到位，自己認為可以做的功能在基于系統(tǒng)現(xiàn)在的支撐時無法按時間迭代出來，導致只能使用替換方案，變更需求。
• 前期制定的方案對需求的理解有偏差，經過后期的對接和溝通發(fā)現(xiàn)理解錯誤然后變更需求。

2. 需求經常變動將產生什么影響？

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

如果需求經常變動會導致產品設計，開發(fā)邏輯和測試用例的重構或者已完成的工作量作廢清零。

變更需求的次數(shù)越多導致團隊的整體工作量增加，時間卻在減少，自身和團隊的工作壓力就會越大，當壓力過大時，經常變動需求就會很容易使團隊和諧受到沖擊，久而久之會讓團隊質疑產品經理自身的工作能力，降低產品經理在團隊中的公信力，自己也會質疑自身的工作能力，產生不自信的表現(xiàn)，形成惡性循環(huán)。

案例：

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

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

1）使用工具輔助梳理邏輯

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

案例-工具輔助：

2）極值思考

即當產品中的數(shù)據為0或為最大值時處理的邏輯應該是什么。為避免邏輯，頁面和功能的缺失，采用極值條件思考，將產品中產生數(shù)據的地方統(tǒng)計總結并且做出數(shù)據值為0或最大值的假設來校驗需求是否有缺失。

案例-極值思考：

如知乎的稍后答功能，當數(shù)據為0時，展示空頁面，并引導用戶查看推薦的問題。

3）前期技術調研

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

4）需求調研

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

?02 客戶臨時加需求

1. 客戶臨時加需求會產生什么影響？

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

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

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

1）獲取真實需求

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

2）替換需求

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

3）需求閹割

為了將核心需求在一定時間內做到最好的效果，將需求劃分優(yōu)先級并將優(yōu)先級較低的需求暫時放在下一版本中，利用系統(tǒng)現(xiàn)有資源，采用邏輯簡單，較易實現(xiàn)的方案，這樣付出成本小，效果達到了，如果方向正確，后期可進行迭代優(yōu)化。

03 風險預報周期太短

1. 風險預報周期短的原因是什么？

1）重大問題發(fā)現(xiàn)的時間太晚，或者臨近發(fā)版時發(fā)現(xiàn)一堆問題，導致無法及時處理問題從而影響發(fā)版?？赡芤驗樵趫F隊協(xié)作中缺少充分的溝通，比如團隊對需求的理解不清晰，對需求的優(yōu)先級沒有掌握或者是bug堆積，測試打包頻率不夠等等原因都會導致這種情況的發(fā)生。

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

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

2. 在研發(fā)和測試兩個流程中，產品可以驅動的方式有哪些呢？

1）每天跟蹤項目進度

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

2）產品功能驗收

當開發(fā)人員完成一組功能時，產品可以先去驗收這一組功能，如果產品設計有問題時可以及時改正，如果研發(fā)實現(xiàn)有問題時也可以盡早修復bug?？梢詼p少產品質量驗收時的壓力和工作量，bug可以盡早處理，發(fā)現(xiàn)邏輯有問題時也可以盡早改正，對產品的質量和項目的進度都有正向推進的作用。

3）制定需求優(yōu)先級

在測試過程中可以將需要測試的功能模塊分好優(yōu)先級（一般按需求的優(yōu)先級來），先測需求重要和邏輯復雜的模塊，避免發(fā)版前出現(xiàn)較難解決的故障。研發(fā)人員修復bug時，也應評估bug的優(yōu)先程度去修復。

?04 臨近發(fā)版才發(fā)現(xiàn)某一功能與需求不符

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

1. 造成這種問題的原因是什么呢？

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

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

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

2. 產生的影響

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

所以如何避免這種情況的發(fā)生尤為重要？

• 優(yōu)質的需求文檔：將產品文檔寫的詳盡一些，簡單易懂的描述自己想要的是什么，如果語言組織上出現(xiàn)問題時可以參照市面上已有的功能，轉化成口語形式去描述。
• 團隊溝通：和研發(fā)，測試人員充分溝通，確保他們理解你想要的功能是什么樣的，可以用原型輔助演示自己想要達到的效果。
• 產品先驗收后測試：產品經理可以在開發(fā)人員開發(fā)完成后，測試之前，先驗收功能的一致性和邏輯的正確性，保證產品的走向是正確的。如果在錯誤的基礎上進行測試，那么就浪費了員工的精力，時間，最終還沒有達到預期的效果。
• 質量驗收：在測試完成后進行產品的質量驗收，此時的產品應沒有重大，明顯的bug，產品主要是對頁面的美觀度，操作的流暢度進行驗證，驗證無誤后即可進行發(fā)版。

05總結

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

本文由 @菜菜子? 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Pexels，基于CC0協(xié)議