編輯導讀：一個大型項目從立項到完成會需要多方合作，涉及到很多人員的調(diào)動，工作也會比較的繁瑣。作為一個產(chǎn)品經(jīng)理，如何做好項目管理呢？本文作者根據(jù)自身工作經(jīng)歷，總結(jié)了一些經(jīng)驗，和大家分享。

19年到21年，2年多的時間我和團隊一起搭建了一套BI平臺。我們完成了80多個迭代，1300多個特性，85%以上的迭代未出現(xiàn)任何延期，2年半時間保持穩(wěn)定輸出2周一個迭代。團隊在敏捷項目迭代中成為標桿。

這其中，一套科學有效的敏捷項目管理方法發(fā)揮了至關(guān)重要的作用。

項目管理貫穿于產(chǎn)品的全流程管理，因此我把他分為了5個模塊，分別為需求管理、需求評審、研發(fā)前準備、研發(fā)中、上線后的回顧。接下來，我將從這5個模塊分別描述我們是如何進行高效管理的。

一、 需求管理

產(chǎn)品的需求總是源源不斷的，有的來自于用戶直接的需求反饋，有的則來自于公司對產(chǎn)品的宏觀愿景。這些需求我們究竟要如何進行管理呢？

1. 需求池管理

1）從目標出發(fā)對需求池進行管理

需求池的需求總是超出我們的預(yù)期的，需求不是做的越多越好，需求的目標也不是為了把需求做完。需求的管理指的是在有限的團隊和有限的時間范圍下，找到優(yōu)先級更高的需求，解決用戶最關(guān)心的問題，滿足用戶的最大價值和公司的最大價值。

所以確定產(chǎn)品的愿景和目標，從愿景、目標出發(fā)對需求池進行管理而不是從功能出發(fā)進行管理。

對于目標的確定，首先，我們需要明確產(chǎn)品的愿景，再在產(chǎn)品整體愿景的基礎(chǔ)上確定產(chǎn)品年度目標，產(chǎn)品的roadmap，再將目標拆解為季度和月度目標，進行細化。一方面通過目標確定當年的需求方向，并因此能夠標記出池需求的優(yōu)先級，另一方面，拆解到月度范圍的目標能讓我們有條不紊穩(wěn)步前進。

但同時，雖然我們以目標為導向，大目標一般是穩(wěn)定的，但小周期的目標實際上是允許靈活變動的，需要根據(jù)用戶以及當前環(huán)境的變化做出靈活的應(yīng)對。

目標管理是為了讓團隊和項目有清晰的指引和前進的動力，但目標管理本身并不是我們追求的目標，所以千萬不要覺得目標是不可改動的，就像敏捷宣言中所說：響應(yīng)變化高于遵循計劃才是正確的處理方式。我們需要根據(jù)客戶的影響度適當對目標進行調(diào)整，同時也對需求優(yōu)先級進行調(diào)整。

2）和用戶一起建立溝通和閉環(huán)機制

需求池的管理不僅僅能夠?qū)Ξa(chǎn)品本身的迭代進行管理，同時也能夠和用戶之間建立關(guān)系橋梁。

一份清晰的需求清單表，應(yīng)該包括需求的描述、提出人、提出時間、產(chǎn)品評估結(jié)果，當前進度，優(yōu)先級等字段，這樣就能夠輔助產(chǎn)品對需求進行管理。

同時，如果需求和業(yè)務(wù)方密切合作，也應(yīng)該通過將需求清單共享給用戶查看，不斷更新需求池狀態(tài)，讓用戶和項目組同學知道對于用戶需求的響應(yīng)狀況，建立積極的用戶關(guān)系，和用戶一起建立起溝通和閉環(huán)機制。

2. 迭代需求管理

當我們從需求池撈出需求進入迭代完成原型后，并不是馬上進入需求評審階段。

如果需求較為復(fù)雜或產(chǎn)品無法判斷需求的數(shù)量以及方案的可行性，需要產(chǎn)品在需求評審前拉起主要研發(fā)同學進行小范圍討論，目的是確定需求方案的可落地性和迭代需求范圍。

為什么要確定迭代需求范圍呢？因為在敏捷開發(fā)中，迭代的周期是穩(wěn)定的，比如2周一個迭代，通過穩(wěn)定而較短的開發(fā)周期，一方面保證了需求響應(yīng)的及時性，也符合MVP快速市場驗證的理念。同時，通過穩(wěn)定的開發(fā)周期，能夠提高研發(fā)同學對需求評估的精準度（迭代周期穩(wěn)定，需求數(shù)量較為穩(wěn)定，通過越多的相似規(guī)模的需求實際開發(fā)時間作為樣本，對開發(fā)工作量的評估就會越來越接近實際值），以及積極的項目節(jié)奏氛圍。當然，如果不是敏捷開發(fā)，可能就另當別論了。

所以，我們進行迭代范圍的確定，也就是在正式需求評審前，將優(yōu)先級較低的需求砍掉，以免浪費大家的時間。

二、 需求評審

1. 團隊成員了解需求背景了嗎？

現(xiàn)在，我們來做一個測試，問問你的團隊，項目的定位和愿景是什么，有多少人能回答上來？你的成員們真的知道迭代為什么要規(guī)劃這些功能嗎？他們知道目標用戶是誰、場景是什么、解決了用戶什么痛點嗎？

答案是不是有些許扎心？那我有理由懷疑你沒有做好真正的需求評審。

一個好的需求評審，需要告訴團隊項目的目標，迭代的目標，同時，在進行需求講解時，不僅僅需要闡述功能的流程，還需要闡述需求的背景。即什么用戶在什么場景下遇到了什么問題，我們提供的這個功能解決了他什么問題，滿足了用戶什么需求。

在這樣的前提下，研發(fā)同學才會知道產(chǎn)品建設(shè)的意義和價值，也才會對產(chǎn)品有認同感，而不是覺得自己只是來開發(fā)個功能而已。也只有研發(fā)同學對產(chǎn)品有認同感之后，才會有主人翁意識，并去和產(chǎn)品一起思考如何做的更好，現(xiàn)有的方案是不是最優(yōu)的。

記住，一個好的團隊一定是有目標有夢想的，咸魚一樣的團隊是做不出極致的產(chǎn)品的。而這份目標和夢想的植入需要產(chǎn)品在需求評審階段就去努力。

此刻，你還以為需求評審只是為了把要做的功能流程講清楚嗎？

2. 需求的優(yōu)先級

除了講清楚需求的背景，在完成需求評審后，我們還需要對需求優(yōu)先級進行評估。

一方面保證研發(fā)順序按照優(yōu)先級進行，保證高優(yōu)先級需求的交付。另一方，低優(yōu)先級但可能完不成的需求，作為迭代沖刺目標，是可以根據(jù)完成情況移入下迭代，而不影響迭代的。

這里，我們的方法是，除了高中低的優(yōu)先級排序，我們還會把這些需求標上阿拉伯數(shù)字，表明各需求整體的優(yōu)先級排序。

3. 將確定的需求錄入到相應(yīng)的項目管理系統(tǒng)

需求的線上管理我們之前使用jira，市面上也有一些其他的項目管理工具，比如騰訊的tapd 以及很久前我用過一個叫trello的工具。如果沒有，用excel 和便利貼進行管理也是可以的。

需求的拆分，粒度是比較難的一件事兒。

從用戶的角度來說，大小規(guī)模合適的需求，是一個可以滿足某一需要達成某一業(yè)務(wù)目標的故事，比如刪除一條任務(wù)，就是能夠獨立作為一個需求單的需求。而從項目組研發(fā)的角度上來說，一個大小規(guī)模適當?shù)男枨笫强梢栽趲滋鞎r間內(nèi)完成開發(fā)和測試的故事，因此，同樣刪除也是滿足的。

通過拆分這樣的小模塊，對于開發(fā)、測試和最終的發(fā)布上線都是大有裨益的，因為將需求劃分為這樣的小故事，團隊就可以并行開發(fā)各個模塊，而無需彼此等待。也就不會出現(xiàn)需求開發(fā)堆積到后期的風險。因此我們建議將需求拆分為可以在兩三天時間內(nèi)完成開發(fā)和測試的模塊。

拆分完需求后，就需要把需求錄入線上系統(tǒng)。在需求錄入時，需求的標題需要簡單直接，我們一般會采用的描述如下：

除此還需要標注需求的優(yōu)先級，需求負責人、故事點、開始時間、結(jié)束時間等信息。完整和簡潔的信息有助于后期進行故事墻管理。

三、 研發(fā)前準備

如果需求評審結(jié)束就立即進入研發(fā)，極大可能會出現(xiàn)事倍功半和混亂的局面，所以，研發(fā)前的準備工作是不可忽略的。那研發(fā)前有哪些準備工作呢？

1. 技術(shù)評審會

技術(shù)評審主要由研發(fā)側(cè)發(fā)起和負責，目的是前后端同學對各需求所需要的技術(shù)能力以及風險進行對齊，尤其是當功能復(fù)雜，對應(yīng)技術(shù)復(fù)雜的時候，充分的技術(shù)評審能夠規(guī)避迭代研發(fā)過程中可能出現(xiàn)的技術(shù)風險，確保迭代進度和質(zhì)量。

一般這時候，研發(fā)負責人需要和大家一起確定每一個需求的前后端研發(fā)同學。前后端對各自的需求進行闡述，后端主要是接口文檔的定義（格式和地址待定）。當項目需要引入新組件、新技術(shù)時還需要進行技術(shù)預(yù)演，去熟悉新的技術(shù)，評估怎么整合到系統(tǒng)、有沒有風險等。

2. 拆分研發(fā)任務(wù)和確定需求開發(fā)節(jié)奏

完成技術(shù)評審會之后，研發(fā)同學對于每一個需求的完成需要做哪些工作以及怎么做也就清楚了。這個時候就可以開始進行研發(fā)任務(wù)的拆分了。

研發(fā)任務(wù)的拆分是為了對于每一個需求的跟進提供切實可依的依據(jù)，并在后期的項目故事板進行展示，輔助項目能夠有序穩(wěn)步前進，而不是讓項目管理進入無序的黑盒子。因此，在任務(wù)拆分的時候需要遵循幾個點：

• 研發(fā)任務(wù)需要分別拆分前端、后端研發(fā)任務(wù)，分別確定負責人進行跟進。
• 研發(fā)任務(wù)的粒度盡量小于3 天的開發(fā)周期，否則很難跟進和評估風險。
• 研發(fā)任務(wù)需要標記owner、研發(fā)開始時間、研發(fā)結(jié)束時間、故事點信息。

基于以上，我們又能對需求進行一些信息的補充，包括：

• 根據(jù)單個需求下所屬的全部研發(fā)任務(wù)的開始時間和結(jié)束時間確定需求的提測時間，即需求的研發(fā)開始時間和結(jié)束時間。
• 確定需求的研發(fā)owner ,研發(fā)owner 對需求的開發(fā)周期負責。包括確保需求按時進入聯(lián)調(diào)，按時完成聯(lián)調(diào)，按時提測。

3. 需求反講和計劃會

1）需求反講

我們經(jīng)常會聽到研發(fā)和產(chǎn)品經(jīng)理撕的事情，有些時候我們也會聽到因為前期需求溝通不一致，導致研發(fā)結(jié)果和產(chǎn)品需求出現(xiàn)偏差的事情。為了規(guī)避這樣的問題，我們加入了需求反講環(huán)節(jié)。

所謂的需求反講就是讓研發(fā)同學來講需求，產(chǎn)品同學聽需求。在這個過程中，需求的前后端研發(fā)負責人會先講一講整體的功能流程，同時會闡述自己需要準備什么。如果信息不對稱能夠很快發(fā)現(xiàn)。當然，如果需求很簡單，也可以忽略這一環(huán)節(jié)。

2）計劃會

計劃會的目的主要是和大家一起確定迭代節(jié)奏。包括每一項需求的開始時間和開發(fā)結(jié)束時間（包括聯(lián)調(diào)，也就是開發(fā)結(jié)束就應(yīng)該進入測試），并由此確定全面提測時間，并由測試同學確定測試完成封版的時間以及發(fā)布的時間。

如果前面的任務(wù)拆分都做的很好，每一項任務(wù)前后端都評估了時間，同時大家對需求理解沒有問題，在這樣的前提下，計劃會其實是很快的。

如果考慮會議太多，其實可以將計劃會和需求反講放到一起進行。

計劃會結(jié)束后，整體迭代中的需求節(jié)奏，迭代發(fā)布節(jié)奏基本也就確定了。這時候作為項目經(jīng)理，可以整理郵件，將迭代目標，計劃發(fā)送知會全員。

4. 完成故事墻

故事墻顧名思義是一面墻或者白板，線上或線下都可以。而墻上則是迭代中的用戶故事以及研發(fā)任務(wù)，項目管理中通過把這些故事和任務(wù)貼到故事墻上并根據(jù)進度挪動，從而實現(xiàn)項目中的進度管理。

1）故事墻的結(jié)構(gòu)

頂部是項目進度的敘事主線，通過一個個的活動階段將故事和任務(wù)組織起來。并通過對正常狀態(tài)和風險項的細分，有效的反映出故事和人物的變化性，讓項目成員對項目進度能夠有效把控。

迭代目標的展示是為了讓項目組同學目標一致前進，也能明白大家做的事情的意義和價值。

我們把所有規(guī)劃到迭代中的需求以及對應(yīng)的研發(fā)任務(wù)放到規(guī)劃中，分兩列放置。

當需求下的任務(wù)啟動開發(fā)后，就可以將任務(wù)拖動到實現(xiàn)中，當任務(wù)狀態(tài)進入聯(lián)調(diào)中時，我們就需要把需求和任務(wù)一起拖動到聯(lián)調(diào)中狀態(tài)。為了方便查看，進入聯(lián)調(diào)后會建議大家把需求和對應(yīng)任務(wù)放到一起開始進行拖動，如果你的故事墻是便簽紙制作，這個時候你可以把需求和任務(wù)疊到一起進行拖動。

接著需求進入到測試、待發(fā)布的流程，并最終隨版本全部發(fā)布上線。

在實際操作中我們發(fā)現(xiàn)在進程中部分需求可能出現(xiàn)風險延遲，因此我們在縱向上又將需求劃分為正常進度和風險項，一旦需求或任務(wù)出現(xiàn)風險就需要將需求和任務(wù)拖入到風險項一行，解除后可回到正常一行。

當然，根據(jù)需要你也可以增加更多的狀態(tài)欄來輔助管理，比如我們之前的故事墻是這樣的。敏捷教練甚至會在頂部打印出大家的頭像，來讓大家有更明確的團隊歸屬感。

2）故事卡片

故事墻由一個個的需求和任務(wù)卡片組成，對于故事卡片來講，需要包括如下內(nèi)容：故事標題、故事描述、優(yōu)先級、負責人、開始時間、結(jié)束時間、狀態(tài)

而對于任務(wù)來說則需要包括：

任務(wù)標題，依賴的需求、負責人、開始時間、結(jié)束時間、狀態(tài)、故事點信息。

通過這些信息，我們能夠清晰的看到每一天應(yīng)該做哪些需求，哪些需求應(yīng)該進入測試，哪些需求出現(xiàn)延期，需求的負責人是誰。從而對需求的完成進度，項目的節(jié)奏能夠有較強的把控力。

四、 研發(fā)階段的項目推進

1. 站立會

研發(fā)正式開始后，為了正常推進項目進度，我們會進行每日站立會。

站立會階段主要需要明確每一個成員的進度和計劃，以及同步風險。即項目成員昨天完成了什么，今日要做什么，當前是否有風險項或項目阻塞，每人不會超過1分鐘。

站立會上若遇到需要解決的問題，我們會督促大家會議結(jié)束后立馬小范圍拉上相關(guān)人員討論解決，而不會在站立會上直接解決，因為如果在站立會上解決，會讓整個站立會的時間拉的特別長，耽誤其他同學的時間。

成員在同步的同時，需要同步拖動卡片的位置改變卡片狀態(tài)。這樣，站立會結(jié)束，目前各個需求以及任務(wù)對應(yīng)的開發(fā)狀態(tài)和進度也就一目了然了。

2. 需求的驗收

隨著需求不斷被交付，產(chǎn)品逐漸進入測試階段。在這個過程中，除了研發(fā)要做好開發(fā)和自測，測試同學要做好功能測試，也需要產(chǎn)品經(jīng)理在各個環(huán)節(jié)深度參與，把控質(zhì)量。

為了從源頭上阻斷功能開發(fā)和產(chǎn)品理解不一致，我們一般會在研發(fā)完成聯(lián)調(diào)后先讓產(chǎn)品經(jīng)理先做功能測試，這個過程中主要看功能主流程是否跑通，是否和需求開發(fā)一致。產(chǎn)品測試通過，則可轉(zhuǎn)測試狀態(tài)，并知會測試同學開始功能測試。

為了保證各流轉(zhuǎn)環(huán)節(jié)的無縫銜接。我們采用的方式是群知會，比如研發(fā)完成聯(lián)調(diào)后群里@產(chǎn)品進行開發(fā)環(huán)境測試，產(chǎn)品測試通過后群里立馬@測試同學可開始測試，以保證流程的順暢。雖然我們通過jira或者郵件都可以實現(xiàn)轉(zhuǎn)單以及通知，但從溝通的實效性以及流程的完整性上，我們更建議通過群通知方式進行。

如果因為開發(fā)群消息太多會淹沒消息，甚至可以單獨開一個測試群，專門周知測試流程周轉(zhuǎn)。

測試同學在收到測試單以后開始進行測試，并將發(fā)現(xiàn)的問題和對應(yīng)研發(fā)同學溝通后提單bug。修改并測試完成后將需求改為待發(fā)布狀態(tài)。

進入全面提測階段后，還需要邀請UED同學進行交互、視覺還原度測試，并及時將發(fā)現(xiàn)的問題反饋給項目組。

3. 迭代發(fā)布

迭代發(fā)布代表著產(chǎn)品研發(fā)完成終于可以上線了，但一旦功能存在問題，上線就會給用戶造成較為糟糕的體驗和印象，因此迭代正式發(fā)布前的驗收也至關(guān)重要。

一般情況下，測試同學按照封版時間完成測試后發(fā)出測試驗收郵件，產(chǎn)品在收到郵件后開始進行全局產(chǎn)品驗收。驗收無誤則可知會大家產(chǎn)品驗收通過，進入發(fā)布狀態(tài)。

此時，研發(fā)同學需要召集運維同學進行發(fā)布評審，各研發(fā)同學報備準備無誤，各項準備就緒，運維同學確定發(fā)布的具體時間點，即可發(fā)布。

五、上線后的回顧會

在項目迭代中，并不是產(chǎn)品上線后就大功告成可以撒手不管了，產(chǎn)品上線后我們需要去進行回顧和持續(xù)跟進，回顧的目的不是為了糾錯，還是為了從過程中不斷的學習和進步。

1. 關(guān)注上線后產(chǎn)品的質(zhì)量

首先，需要關(guān)注產(chǎn)品的質(zhì)量和用戶反饋，第一時間去觀察用戶的行為和反饋，并將用戶反饋納入需求池進行管理。

同時，也需要通過指標客觀進行觀測，看看用戶對新功能的使用情況。

2. 回顧和關(guān)注工作計劃是否合理。

工作計劃的合理有序是保證項目推進有序的必要條件，如果不合理是哪里不合理，就需要考慮如何在下一個迭代中進行調(diào)整。針對這一塊我們可以看的包括需求燃盡圖、迭代需求完成率、需求變更率等報表。

需求燃盡圖反映了在迭代下需求完成的趨勢。正常情況下，需求完成數(shù)是勻速上升的，如果出現(xiàn)前期上升緩慢，則表明需求極有可能堆積在后期交付，故事和任務(wù)可能都拆的過大，項目存在極大風險。若前期上升速度過快，則可能是需求評估不準，導致需求提前完成，或前期堆積的都是小需求。

迭代完成率指的是，迭代實際完成的需求數(shù)或故事點數(shù)占規(guī)劃需求數(shù)或故事點數(shù)的比率。度量研發(fā)團隊在核定的時間內(nèi)穩(wěn)定交付需求的能力。

需求變更率則主要指由于前期考慮不周導致需求的大變更，或研發(fā)中臨時撤換需求。在客戶需求變更或特殊情況下，我們允許一定情況的需求變更，擁抱變化，但同時，頻繁的需求變更也會對研發(fā)團隊帶來交付和資源上的壓力，因此并不建議這樣的操作。

同時，由于前期需求考慮不充分導致的頻繁需求變更，還會讓研發(fā)團隊對產(chǎn)品產(chǎn)生不信任感，降低項目的凝聚力。

3. 關(guān)注過程是否有序

比如開發(fā)的節(jié)奏是否根據(jù)大家估算的開始時間、結(jié)束時間進行推進，是否及時提測，整體需求的延遲交付率是怎樣的等等。

產(chǎn)品從需求到上線，整體是多方協(xié)作共同的結(jié)果，如果一方在過程中無序，就會形成多米諾連鎖反應(yīng)，造成項目的混亂。經(jīng)?？吹接行╉椖康默F(xiàn)象是，研發(fā)團隊延遲提測，壓縮測試時間，導致測試不充分情況下上線，測試不充分又導致產(chǎn)品問題沒有被發(fā)現(xiàn)而影響用戶體驗，最終，用戶體驗受損，產(chǎn)品品牌受損，造成不可挽回的損失。

六、誰對項目管理負責

項目管理是一件繁瑣而專業(yè)的工作，一般稍微大型的公司和團隊都會配有專業(yè)的項目經(jīng)理，如果是敏捷開發(fā)還會配置敏捷教練。但無論如何，項目管理一定不是某一個人的事情，而是需要團隊一起努力的結(jié)果。

一方面，產(chǎn)品經(jīng)理和項目經(jīng)理需要進行配合管理，同時，研發(fā)端也需要有一個研發(fā)經(jīng)理能夠協(xié)助產(chǎn)品和項目經(jīng)理一起進行管理。

產(chǎn)品經(jīng)理對產(chǎn)品全流程最終交付負責，因此，產(chǎn)品經(jīng)理其實需要時刻關(guān)注團隊，同時配合項目經(jīng)理的一切推進工作。

項目經(jīng)理需要積極推動項目有序進行，遇到阻礙需要及時同步產(chǎn)品，督促或幫助團隊解決問題。甚至在遇到資源問題時項目經(jīng)理也需要幫助進行協(xié)調(diào)，始終為團隊的穩(wěn)定產(chǎn)出，凝聚力而努力。

研發(fā)經(jīng)理作為研發(fā)端的負責人，需要對研發(fā)過程及交付負責，因此需要帶領(lǐng)研發(fā)團隊一起完成各節(jié)點事項，配合項目經(jīng)理工作。否則也可能導致研發(fā)側(cè)的無序。

而因每個團隊特點和配置都不一樣，為了明確成員的角色和職責，便于管理的順利進行。所以需要公開明確團隊各角色及職責范圍，并作為項目約定之一執(zhí)行下去。

七、小結(jié)

根據(jù)我們上面的整體的流程總結(jié)，可以用一張流程圖做一下整體的描述，供大家參考。每一個環(huán)節(jié)我已經(jīng)在上面分開細講。

主體流程是穩(wěn)定的，但我們始終要記住，流程的制定是為了服務(wù)于項目、服務(wù)于人，因此，并沒有一成不變的流程，也沒有萬能的解藥，而需要我們在項目管理中不斷的調(diào)整、優(yōu)化、回顧和學習，并摸索出一套適合自己項目的管理方法。

同時，流程是死的，人是活的。我們始終要學會擁抱變化，高效靈活的溝通永遠高于死板的流程，應(yīng)變和解決業(yè)務(wù)的態(tài)度永遠高于對流程的遵守。時時刻刻為用戶、為產(chǎn)品著想，發(fā)揮出人的能動性，是我們始終要去倡導的。

最后，特別感謝一下這個項目中我們最可愛的敏捷教練萍姐姐，為我們的敏捷開發(fā)保駕護航，她同時也指導了我的總結(jié)文章；感謝原研發(fā)負責人彪哥，以產(chǎn)品結(jié)果為導向，帶領(lǐng)研發(fā)的兄弟們團結(jié)一致，才讓我們的項目組更加團結(jié)產(chǎn)品做的更好；也感謝團隊的 每一個小伙伴，每一個人都是積極、努力、富有主人翁意識的配合我們工作，才讓我們的項目推進更加有序。

感謝每一個小伙伴的認真、努力和團結(jié)，讓我有一段愉快的旅程。

本文由 @糖糖是老壇酸菜女王 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

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