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

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

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

1. 項目排期表

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

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

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

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

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

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

2. 項目進度跟進

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

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

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

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

3. 需求變更

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

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

3.1 產(chǎn)品功能補充/小改動

在開發(fā)的過程中，產(chǎn)品經(jīng)理突然發(fā)現(xiàn)遺漏了某種場景或特殊情況，對產(chǎn)品需求進行的補充和修訂。客戶需求發(fā)生變化，需要產(chǎn)品功能進行對應的更改。這個時候需要產(chǎn)品經(jīng)理根據(jù)最新的需求補充產(chǎn)品文檔，并同步至研發(fā)、測試和項目經(jīng)理，項目經(jīng)理根據(jù)產(chǎn)品需求變更帶來的工作量對項目排期表進行調整。

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

3.2 產(chǎn)品功能的增加

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

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

3.3 產(chǎn)品需求變更流程

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

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

需求變更的規(guī)則還有：

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

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

4. 技術因素

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

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

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

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

本文由 @Anne 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

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