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

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 和便利貼進行管理也是可以的。

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

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

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

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

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

三、 研發前準備

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

1. 技術評審會

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

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

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

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

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

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

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

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

3. 需求反講和計劃會

1）需求反講

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

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

2）計劃會

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

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

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

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

4. 完成故事牆

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

1）故事牆的結構

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

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

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

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

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

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

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

2）故事卡片

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

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

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

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

四、 研發階段的項目推進

1. 站立會

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

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

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

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

2. 需求的驗收

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

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

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

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

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

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

3. 疊代發布

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

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

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

五、上線後的回顧會

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

1. 關注上線後産品的質量

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

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

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

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

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

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

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

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

3. 關注過程是否有序

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

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

六、誰對項目管理負責

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

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

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

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

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

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

七、小結

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

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

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

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

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

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

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部