淺談專案中需求變更和拖延的問題

摘要： 站在移動端開發人員的角度，談談專案開發中產品經理該如何更合理地處理需求變更和專案拖延的問題。 引子：當開發人員說“技術無法實現”的時候，是想表達什麼？ 需求太傻了，完全沒必要做； 比如那種根據手機殼顏色變換主題顏色的...

站在移動端開發人員的角度，談談專案開發中產品經理該如何更合理地處理需求變更和專案拖延的問題。

引子：當開發人員說“技術無法實現”的時候，是想表達什麼？

• 需求太傻了，完全沒必要做；

  比如那種根據手機殼顏色變換主題顏色的功能。

• 時間和資源不夠，成本太高，不想去做；

  比如專案週期就兩個月，自研 IM 的功能根本完成不了，而且實現的效果未必有第三方IM功能好。

• 從專案程式碼上改動太大，開發人員不願做；

  比如，之前遇到一個需求：應用所有頁面除了以下兩種情況其餘都可以調起搖一搖客服彈窗：已經有彈窗出現的時候，不能調起搖一搖客服彈窗；在客服頁面或引導蒙層頁面，不能調起。按照常規的實現方式，需要每個頁面和每個對話方塊都去實現一遍是否啟動搖一搖客服的邏輯，這樣程式碼改動會很大；如果之前的頁面邏輯時每個頁面或對話方塊都是繼承一個 Base 類，那實現起來就簡單很多。

• 不理解這個需求的價值，認為實現這個功能沒有價值；

  開發不是程式碼機器，要交代清楚產品的需求價值。

• 自己的技術能力有限，無法實現；

• 從技術角度看，根本無法實現；

如何和開發談需求變更？

首先思考一個問題：為什麼會有需求變更？

原因可能有以下幾點：

1.自己原來沒想清楚，現在想明白了，需要變更需求；

2.需求方或老闆的需求變了；

3.當前的市場環境變了；

4.需求文件或原型寫得不清晰，或團隊間的理解不統一，以為需求變了；

對於1和4是自身主觀原因導致的需求變更，需要提升自身的產品能力，完善需求文件或原型；對於2和3環境的客觀原因，不可控；

在自己想清楚確實需要變更需求時，需要做好以下幾點，和開發溝通需求變更：

• 1. 更新需求文件或產品原型

  口頭溝通的需求，很容易被忘記，必須記錄在案，方便後續撕逼，或測試做測試用例；而且開發一般也是根據需求文件或原型做開發的；

• 2. 闡明需求變更的原因

  不管是主觀還是客觀原因造成的需求變更，都應該主動背鍋，詳細說明需求變更的意義，同時要尊重開發，不要以一種“指揮”的口氣下發你的需求，然後讓他們幹活 。產品經理通常不是開發人員的老大，不能直接指揮他們，而是要說服、激勵他們，讓他們發揮能動性去做事，和他們溝通遇到分歧，切忌跋扈專橫地做決定，要尊重他們的想法，並說出自己的設計初衷，好好商量。

• 3.在變更需求時，一定要及時同步相關的開發人員和測試人員，避免資訊不對稱，出現做無用功和不必要溝通的情況；

  不要出現iOS實現了新需求，而Android還是按照老需求去做；或是測試人員按照原有需求邏輯去測試新需求的情況；

• 4. 明確好需求變更後的排期

  大的需求變更，影響到專案上線時間，產品經理最好能協調延遲上線，畢竟大家按照原有專案進度都有心理預期。如果排期實在無法改變，需要大家加班時，也要提前打預防針，避免臨近上線才加班趕進度，同時，加班時最好能夠陪同，避免出現需求的疑問，無人解答；

如何應對專案的拖延

通常情況下工程師一般不會偷懶的，如果需要催，一般是專案流程或安排不太合理，造成拖延。專案拖延的原因以及解決辦法：

• 1.需求的變更。產品的需求或者由於前期準備不充足或新的使用者反饋需要修改，從而增加了開發時間。

  解決：參考前面所說的需求變更的問題；

• 2.開發時間的前期預估不準確。本來需要幾個星期才可以完成的事情，之前過於樂觀地估計了更短的時間。

開發時間預估，我見過幾種：

a. 產品經理直接給開發一個截止時間；

b. 產品經理和各端(前後端、設計)組長商討一個開發時間；

c. 產品經理和開發人員過完需求會議後，各端組長分配任務，然後讓各個開發人員預估自己負責模組的開發時間，最終綜合給出一個預估時間；

第1種，完全是對開發人員的不尊重，產品經理太強勢，往往最終只能被迫加班趕進度；

第2種，雖然是開發時間是和各端人員商討的，但畢竟分配任務時，不是組長去完成任務，所以開發時間肯定和實際的時間不太一致；

第3中，給足開發者以尊重，可以自己預估開發時間，而不是隻能接受任務，這樣的主觀能動性也會強一點，一旦出現按照規定的時間完成不了任務，也就只能自覺加班了，往往最終能夠按照預期完成任務；（對於加班，作為開發的角度，我覺得還是按照這種，每天規定好自己的任務和進度，不完成就自覺加班，比盲目的加班容易接受點）

所以，對於開發時間的預估，最好能夠讓開發人員的自己根據任務預估每項的工作量，和截止時間，這樣最終如果完成不了，他們也會自覺加班。

問題：開發人員預估時間過高的怎麼辦？

當然會有這種可能的出現，這是就需要和小組組長協商，適量壓縮時間，或者在預估時間前，先給個預期的時間，然後讓他們根據需求優選級排序來預估時間。

• 3.溝通遇到了問題，當工程師發現某個功能其實難度非常高， 執行壓力大的時候，沒有儘早溝通，deadline 快到了才說，耽誤了工期；

  產品經理需要時刻跟進專案進度，瞭解開發情況；

• 4.產品功能的設計過於煩瑣，本來可以簡化的功能，卻花費了大量的時間，其實這個功能根本不需要浪費這麼長的時間。

產品經理在開發前就應該和開發討論需求的合理性，避免出現功能設計的過於繁雜；

• 5.過多無謂的會議佔用了開發的時間

  不要頻繁開會，開會盡量要小，會議儘量要短，避免低效會議，每個參會的人都是與專案相關的，要保證“非直接負責人不參會” 的原則；沒必要每天站會，一週開會2-3次彙報進度即可。

• 6.不要臨近上線增加需求，或準備上線那天，才去驗收產品

開發最討厭的就是臨近上線更改需求，有些需求不是特別緊急，沒必要趕在上線的節骨眼去完成；同時，產品有個提前3-4天驗收產品，避免出現突發意外影響上線進度。

總結

產品經理首先要提高自己的專業度，儘量減少需求的變更，更改需求，一定要說明原因；並給予開發人員足夠的尊重，才能提高與開發人員協作的效率。