在項目開發的過程中，做好項目管理能夠及時解決一些麻煩和突增的需求。本文從項目排期表、項目進度跟進、需求變更、技術因素四個方面，分享關于怎么輕松做好項目進度管理。

經過產品需求評審，UI、研發、測試同事都已經評估了工作量，確定了產品功能提測時間和上線時間，那么對于產品經理來講是不是就可以去分析下個版本的需求，坐等產品上線了呢？

在實際版本開發的過程中，可能會出現這樣的問題，運營同學反饋有一個影響用戶的產品功能馬上需要優化，領導增加了新的需求，已經評審的需求出現了需求變更。技術由于處理線上問題原來的需求計劃有所延遲，研發處理各種線上BUG影響了開發正常工作。本文主要分析項目開發中的影響因素及其對應的解決方法。

1. 項目排期表

項目排期表是進行項目進度管理的重要手段，通過項目排期表可以非常直觀地看到該項目有哪些開發任務要做，這些任務是由誰來做，開始時間和完成時間，完成的前置條件是有哪些。項目排期表確定了該版本要開發的產品功能的范圍，每個功能中需要的開發工作量，也就是本次版本迭代的迭代周期。

由于產品功能的開發一般需要UI設計師，前端開發工程師，后臺開發工程,共同完成，前端開發可能又會分為web、APP-Android、APP-iOS，小程序，h5，那么項目排期表中除了承載任務安排的關系，還代表了一個產品功能下面需要的不同類型研發工程師的關系。

項目排期表也是一個溝通的工具，前端工程師根據排期表和UI設計師進行UI問題的溝通，和后臺工程師進行產品功能的聯調，測試工程師可以針對測試過程中出現的BUG直接指定對應的研發工程師。

在時間安排上，可以很直觀地通過項目排期表看到各個研發人員的時間安排，各個產品功能開發時間端，產品功能開發的先后關系。同時呢，也會從整個版本迭代過程中發現關鍵任務（重點關注進度的產品功能）和關鍵人員（重點關注進度的研發人員），關鍵任務在整個項目排期中至關重要，不允許有延期的情況。

同時也會調整研發人員的排期，對于有空閑時間的研發人員可以安排其他項目或者進行其他產品功能的開發。一份完善的排期表會大大減少開發過程的溝通和需求問題。

在項目啟動開發之后，除了項目排期表之外，可以同步輸出版本范圍列表，產品功能路徑圖會有助于項目團隊中各個人員對本次產品迭代范圍及注意事項的整體理解。

2. 項目進度跟進

在輸出項目排期表和版本需求范圍，確定了關鍵任務和關鍵人員，還需要定期跟進項目進度。在敏捷項目管理中會采用每天站會的方式同步開發進度和需要解決的問題，每天站會顯得比較繁瑣而且至少會占用30分鐘的時間。

采用在線文檔的方式進行項目進度的跟進成了一種不錯的選擇。在原來項目排期表中增加【進度】和【備注】兩列，其中進度用于同步每條任務的完成情況，備注用于增加對該條任務以外情況的描述，比如后臺未提供接口，第三方未提供接口等等。

通過對項目排期表中進度的描述，項目管理人員可以很清楚和直觀地了解到目前項目進行的狀態，正常進行，延期還是提前完成，并且可以了解研發人員的反饋，及時處理開發過程中出現的意外情況。

可以利用project中的報表工具對項目進行的狀態和開發進度進行評估，直觀的了解項目狀態。項目經理每周將需求開發情況，出現的問題及解決情況同步至項目組成員和領導，以便大家及時了解項目最新進展。

3. 需求變更

在理想情況下項目進度會按照項目排期表有條不紊地進行，完成一個個產品功能的提測，完成一個個產品功能的測試，驗收和上線。但是實際情況中，往往會出現各種情況影響正常的開發迭代，其中最常見的就是產品需求變更和技術因素。

俗話說，計劃就是用來改變的，在互聯網產品開發過程中，產品需求變更往往也是避免不了的。雖然說需求變更備受UI、研發和測試同事的吐槽，但是需求變更來了的時候，還不得不進行需求變更。針對產品功能的變更首先是要了解變更的來源在哪里，是否有必要變更，開發的工作量有多少，是不是一定要在這個版本上線，放在下個版本開發是否可行。

3.1 產品功能補充/小改動

在開發的過程中，產品經理突然發現遺漏了某種場景或特殊情況，對產品需求進行的補充和修訂?？蛻粜枨蟀l生變化，需要產品功能進行對應的更改。這個時候需要產品經理根據最新的需求補充產品文檔，并同步至研發、測試和項目經理，項目經理根據產品需求變更帶來的工作量對項目排期表進行調整。

調整的原則為保證關鍵任務和關鍵人員的進度，對新增需求開發工作量進行評估并增加到項目排期表中，同時根據變更后的項目排期表調整部分需求的提測時間。這部分需求變更的管理有一個前提就是不影響關鍵任務和關鍵人員的安排，或者是對該部分影響較小。

3.2 產品功能的增加

有時候出現大的產品功能的增加，這往往可能來自于業務方面迫切的需求或是領導對整體規劃的調整。這里所說的產品功能的增加指的是增加一個完整的功能，并且會需要較大的工作量，直接加上該功能會對原有項目排期產生重大的影響。

在這種情況下，一般是要確定產品需求，確定產品需求文檔，避免出現后期需求變更的問題，評估整體的工作量，查看新增工作量對于整體迭代周期的影響。然后對版本范圍中為開發的，優先級相對來說比較低的需求安排在下個版本上線。如果時間還是比較緊張，可以向領導說明情況并根據實際情況進行適當延遲。

3.3 產品需求變更流程

在需求變更過程中非常重要的環節就是注意變更流程和變更規范，以保證整體的上線質量和上線效果。首先由需求方（運營/產品）填寫《需求變更申請表》提出需求變更的原因和內容，由產品更改產品PRD，再進行需求評審，如果是小更改可以直接在群聊中解決的就不用再進行需求評審會。

最后項目經理作為統一的歸口同步更新《版本范圍列表》和《項目排期表》，項目組的各項成員統一以最新的產品PRD，《版本范圍列表》，《項目排期表》進行產品功能的開發，測試及驗收。

需求變更的規則還有：

1. 盡量在開發早期提出需求變更；
2. 提測之后不接受需求變更；
3. 變更后的需求一定在產品PRD中標注，并在微信群中@相關人員；
4. 產品上線統一由項目經理做為歸口，以《版本范圍列表》為準；
5. 采用在線文檔或是公司網盤的方式同步文檔，以確保所有人獲得的是最新版本的文檔；
6. 所有文檔如有變更，必須進行記錄。

最后項目經理要對每次項目迭代過程需求變更進行記錄和總結，反應在項目總結當中。如果是在需求理解或是需求設計中出現的問題要吸取教訓，在以后的產品設計中進行改進。

4. 技術因素

隨著產品功能的增加，用戶數量的增加，在實際開發的過程中，技術研發人員往往會在開發新需求的同時修復線上BUG的問題。對于線上BUG的及時響應，及時修復，在占用研發時間中很大一部分用在和運營/產品的溝通中。

那么此時需要對BUG的處理進行優先級和處理時間的分類。對于影響用戶量很大，非常影響用戶體驗的BUG，問題提出當天進行反饋，盡量在當天或第二天上線。

同時BUG處理流程會按照下圖嚴格實施，以減少技術溝通時間，提高研發效率。對于不太緊急的BUG，在開發任務比較緊張的情況下，會在版本上線之后的一周內上線，在開發任務比較寬松的情況下，會在一周之內統一解決，統一驗收，統一上線。

在項目進度管理的過程中做好來自以上幾個方面風險的應對基本能夠控制項目整體進度，保證產品功能上線。在項目進度管理中最核心的內容就是讓項目成員了解項目概況，了解自己的工作內容和上下游關系。當出現不可避免的需求變更時，積極應對，擁抱變化，隨和和團隊同步最新需求和最新進展。

本文由 @Anne 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議