從產品需求評審會、項目規劃、每日項目推進、測試以及階段總結會，整個項目的推進工作很好體現了產品經理的執行能力。

看著移動端的小伙伴把項目提交到應用商店后，我便回到自己的工位上，回想起整個項目從需求到這一刻，經歷的“風風雨雨”，著實令人難忘。在這個項目中，印象最深的不是產品、需求方面的工作，而是整個項目的推進工作，也讓我明白了在一個創業團隊中，在團隊資源有限的情況下，產品負責人項目推進能力的重要性。

下面我就項目推進分為以下6個階段：

1. 產品需求評審會
2. 項目規劃
3. 每日早會
4. 測試
5. 上線
6. 階段總結會

下面將會通過在這個過程中踩過的坑，以及如何從坑中跳出來，來說明產品經理該如何根據團隊的情況來進行項目推進。

首先，就是產品需求評審會。

1、產品需求評審會

幾乎每個產品在正式開發前的必經環節。項目的相關人員通過需求評審會對產品經理輸出的需求和解決方案進行合理性、可行性分析，而且還可以通過需求評審會來理解功能邏輯以及業務邏輯。

由于當時項目時間比較緊，會議后沒有給大家太多的時間去理解和思考業務上的邏輯，大家當時也表示沒有明顯的問題，便根據項目規劃進行正式進行開發了。

到了項目的后半段才發現，在項目推進時遺漏了兩個重點，第一是我們當時的團隊剛成立沒多久，大家的關注點都在乎自己的工作；第二是技術小伙伴們不愛看產品需求文檔。這樣就導致了對產品業務和需求理解不透徹，進而導致開發期間效率低下。

這是項目延期很大的原因。不過經過這件事深刻的認識到，產品經理在產品需求評審會（評審前、評審時、評審后）階段，需要重視一下3點：

• 首先是確保需求、業務通過評審，并沒有明顯錯誤
• 確保開發人員對產品需求和業務邏輯有深刻的理解
• 深刻理解產品的需求、業務和功能后，要對項目開發時間做一個精確的評估，并對這個時間負責

產品評審之后就進行項目規劃。

2、項目規劃的粒度

其實這部分是屬于項目經理的工作，但是由于項目的初期階段我們還沒有項目經理，所以這部分工作也就由產品經理來負責了。當時是開發人員通過功能列表各自評估一下每個功能需要的開發時間，并商討確定出主要核心模塊大概的前后端聯調時間，然后我這邊就根據大家反饋的時間來匯總，按照MVP模式來制定以功能為粒度的項目開發計劃，以周為一個里程碑，然后每周按照功能的優先級完成開發，并且每天會通過每日早會以及日報來把控項目的進度。

當時按照上面的規劃進行了兩周的開發后，其弊端慢慢浮現。對于每周需要完成的功能，開發人員都會存在一個或兩個功能未能完成，或是所有功能都做了，但流程卻跑不通。

當時對于這個情況很困惑，問題出在哪里？是不是當前項目規劃存在問題？

如果我是開發人員，這樣的安排我能不能完成？進行了換位思考后，我發現當時的項目規劃執行起來不好下手，雖然每周的目標、優先級都很明確，但是每天的任務卻是不確定的。也就是說，出現問題的關鍵是任務安排的粒度太粗了，需要開發人員有很好的執行力。但是團隊在這方面尚有欠缺，所有才出現的這樣的情況。

既然問題確定了，那就做優化方案，目標是：通過把任務粒度細化來對項目進行推進，從而使項目能按時順利完成。那么該如何細化任務？雖然自身有技術背景，但沒有接觸過后臺開發，所以無法對開發那邊做出很細的任務安排。正在此時，一個前《今日頭條》的項目經理加入了我們團隊，與我共同推進項目。

項目經理的加入，恰恰彌補了我在技術統籌方面的不足。所以項目經理加入后的第一周，我們就針對團隊的當下情況做了一個優化方案，在大的方向上按照之前的安排，就是項目規劃以及以周作為里程碑，而優化的地方就是把每周的目標細化并指定到每天、每人手上，然后通過每日早會來統籌安排當天的工作來把控、推進項目的進度。

雖然每周的進度還是會因為一些不可控的因素導致一些功能的延期，但總體是可控的，整個團隊的工作流程也順暢了很多。

從這件事中也讓我明白了：

• 產品經理在未了解技術管理的情況下進行項目推進時存在一定難度的。需要加強對開發流程的了解。
• 在項目推進時，任務安排要根據每個人的能力來制定粒度的粗細，這很重要，會直接影響項目的開發進度。

3、每日早會

每日早會，敏捷開發的一個重要環節。

每日早會的主要形式是把團隊成員都組織在一起，然后根據由產品經理或項目經理來組織，每個成員過一下昨日工作完成的情況（如果未完成，那未完成的原因是什么？），遇到了什么問題以及今日的任務安排，通過這種方式來把控一下當先的項目進度。

每日早會幾乎貫穿了整個項目開發階段，如果把項目開發階段比作一條鏈條的話，那么每日早會就是鏈條中的節點。每日早會不僅可以讓產品經理更好的把控項目的情況以及當前的進度，而且還可以盡早發現問題，對問題進行分析解決。

每日早會是項目推進的有效手段：

• 注重3個方向，昨日完成情況、是否存在問題、今日任務安排
• 早會的時間控制在15分鐘內，不占用大家過多的時間

4、提Bug的方式

項目開發到了后期，便進入測試階段。

從現在來看，當時我們的整個測試模塊安排的不太規范，主要反映在兩個問題上，首先是測試安排的粒度過大，是以MVP中的小版本為單位；第二個問題是我們團隊前期沒有測試人員，只有產品經理進行輔助測試，所以造成測試的深度不夠，后期的版本質量不過關，出現很多細節問題，甚至是流程性的問題。

在項目的后期，我們加入的測試人員，開始著重對產品的第一個版本進行集中測試。對于整個測試的過程，總結下過程中需要注意的地方。

• 項目后期，后臺方面的工作量較少，所以測試出現的bug，如果不是明顯的前端后題，應先把bug指派給后臺，排除是后臺的問題之后再指派給前臺。
• 測試提交的Bug應該置于一個Bug池中，然后由產品經理設置Bug解決的優先級并指派人進行跟進。
• Bug池中的Bug修復后，需要讓測試再次確認后沒問題，才能算正式解決，防止開發因為遺漏，誤以為解決的Bug，導致后期再次出現同樣的問題。
• 移動端每天下班前把Bug修復后，需要發一個新的測試版本到內測管理平臺中，并更新內測版本號以及修復的內容，這個很重要。在我們項目推進時Android開發小哥就沒有這種習慣，導致測試妹子還要去一個個Bug對定位，大大增加了測試的工作量。

5、階段總結會議

經過一個月的開發時間，我們完成了第一個版本的開發，但是僅限于完成開發而已，功能流程勉強跑通，依然存在著很多問題，這時進行階段總結會議尤為重要。

會議首先要明確會議的目的：

• 說明當前情況
• 暴露問題
• 找出問題原因
• 解決問題

然后通過當前版本與計劃版本的對比，拋出問題的嚴重性。把當前存在的主要問題暴露出來，比如說：

• iOS上線審核問題
• xxx模塊未跑通
• xxx功能存在問題
  …

接著引申出：為什么會出現現在這種狀況？

產品經理作為負責人把目前每個模塊存在的問題羅列出來，如下圖，是我在階段總結會議上針對目前團隊列出來的部分模塊問題，并附上一些從產品經理角度出發的建議：

針對每個存在的問題，大家在會議上進行針對性的討論，并尋找出解決的方案，然后在后面的工作中進行優化。接著就著重強調優化方案的執行力（因為經歷過很多，解決方案僅出現在會議上而已），如果遇到同樣的問題，大家就需要馬上反應，不然就需要項目經理、產品經理去輔助執行。

對于階段總結會，最主要的明確幾點：

• 會議目的
• 說明當前情況
• 暴露問題
• 找出問題原因
• 解決問題
• 落實執行

6、總結

從產品需求評審會、項目規劃、每日項目推進、測試以及階段總結會，整個項目的推進工作很好體現了產品經理的執行能力。雖然在大部分公司中這個階段的工作是由項目經理負責的，但是產品經理也需要有把控產品的質量和進程能力，真正做到產品的主人，從需求和項目推進的過程中，做到對產品負責。

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