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

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

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

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

一、 需求管理

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

1. 需求池管理

1）從目標出發對需求池進行管理

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

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

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

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

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

2）和用戶一起建立溝通和閉環機制

需求池的管理不僅僅能夠對產品本身的迭代進行管理，同時也能夠和用戶之間建立關系橋梁。

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

同時，如果需求和業務方密切合作，也應該通過將需求清單共享給用戶查看，不斷更新需求池狀態，讓用戶和項目組同學知道對于用戶需求的響應狀況，建立積極的用戶關系，和用戶一起建立起溝通和閉環機制。

2. 迭代需求管理

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

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

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

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

二、 需求評審

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

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

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

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

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

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

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

2. 需求的優先級

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

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

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

3. 將確定的需求錄入到相應的項目管理系統

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

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

從用戶的角度來說，大小規模合適的需求，是一個可以滿足某一需要達成某一業務目標的故事，比如刪除一條任務，就是能夠獨立作為一個需求單的需求。而從項目組研發的角度上來說，一個大小規模適當的需求是可以在幾天時間內完成開發和測試的故事，因此，同樣刪除也是滿足的。

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

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

• 作為：who
• 我希望：what
• 以便： why

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

三、 研發前準備

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

1. 技術評審會

技術評審主要由研發側發起和負責，目的是前后端同學對各需求所需要的技術能力以及風險進行對齊，尤其是當功能復雜，對應技術復雜的時候，充分的技術評審能夠規避迭代研發過程中可能出現的技術風險，確保迭代進度和質量。

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

2. 拆分研發任務和確定需求開發節奏

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

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

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

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

• 根據單個需求下所屬的全部研發任務的開始時間和結束時間確定需求的提測時間，即需求的研發開始時間和結束時間。
• 確定需求的研發owner ,研發owner 對需求的開發周期負責。包括確保需求按時進入聯調，按時完成聯調，按時提測。

3. 需求反講和計劃會

1）需求反講

我們經常會聽到研發和產品經理撕的事情，有些時候我們也會聽到因為前期需求溝通不一致，導致研發結果和產品需求出現偏差的事情。為了規避這樣的問題，我們加入了需求反講環節。

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

2）計劃會

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

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

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

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

4. 完成故事墻

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

1）故事墻的結構

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

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

我們把所有規劃到迭代中的需求以及對應的研發任務放到規劃中，分兩列放置。

當需求下的任務啟動開發后，就可以將任務拖動到實現中，當任務狀態進入聯調中時，我們就需要把需求和任務一起拖動到聯調中狀態。為了方便查看，進入聯調后會建議大家把需求和對應任務放到一起開始進行拖動，如果你的故事墻是便簽紙制作，這個時候你可以把需求和任務疊到一起進行拖動。

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

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

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

2）故事卡片

故事墻由一個個的需求和任務卡片組成，對于故事卡片來講，需要包括如下內容：故事標題、故事描述、優先級、負責人、開始時間、結束時間、狀態

而對于任務來說則需要包括：

任務標題，依賴的需求、負責人、開始時間、結束時間、狀態、故事點信息。

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

四、 研發階段的項目推進

1. 站立會

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

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

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

成員在同步的同時，需要同步拖動卡片的位置改變卡片狀態。這樣，站立會結束，目前各個需求以及任務對應的開發狀態和進度也就一目了然了。

2. 需求的驗收

隨著需求不斷被交付，產品逐漸進入測試階段。在這個過程中，除了研發要做好開發和自測，測試同學要做好功能測試，也需要產品經理在各個環節深度參與，把控質量。

為了從源頭上阻斷功能開發和產品理解不一致，我們一般會在研發完成聯調后先讓產品經理先做功能測試，這個過程中主要看功能主流程是否跑通，是否和需求開發一致。產品測試通過，則可轉測試狀態，并知會測試同學開始功能測試。

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

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

測試同學在收到測試單以后開始進行測試，并將發現的問題和對應研發同學溝通后提單bug。修改并測試完成后將需求改為待發布狀態。

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

3. 迭代發布

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

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

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

五、上線后的回顧會

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

1. 關注上線后產品的質量

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

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

2. 回顧和關注工作計劃是否合理。

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

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

迭代完成率指的是，迭代實際完成的需求數或故事點數占規劃需求數或故事點數的比率。度量研發團隊在核定的時間內穩定交付需求的能力。

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

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

3. 關注過程是否有序

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

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

六、誰對項目管理負責

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

一方面，產品經理和項目經理需要進行配合管理，同時，研發端也需要有一個研發經理能夠協助產品和項目經理一起進行管理。

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

項目經理需要積極推動項目有序進行，遇到阻礙需要及時同步產品，督促或幫助團隊解決問題。甚至在遇到資源問題時項目經理也需要幫助進行協調，始終為團隊的穩定產出，凝聚力而努力。

研發經理作為研發端的負責人，需要對研發過程及交付負責，因此需要帶領研發團隊一起完成各節點事項，配合項目經理工作。否則也可能導致研發側的無序。

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

七、小結

根據我們上面的整體的流程總結，可以用一張流程圖做一下整體的描述，供大家參考。每一個環節我已經在上面分開細講。

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

同時，流程是死的，人是活的。我們始終要學會擁抱變化，高效靈活的溝通永遠高于死板的流程，應變和解決業務的態度永遠高于對流程的遵守。時時刻刻為用戶、為產品著想，發揮出人的能動性，是我們始終要去倡導的。

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

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

本文由 @糖糖是老壇酸菜女王 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。