從產(chǎn)品需求評審會、項目規(guī)劃、每日項目推進、測試以及階段總結(jié)會，整個項目的推進工作很好體現(xiàn)了產(chǎn)品經(jīng)理的執(zhí)行能力。

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

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

1. 產(chǎn)品需求評審會
2. 項目規(guī)劃
3. 每日早會
4. 測試
5. 上線
6. 階段總結(jié)會

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

首先，就是產(chǎn)品需求評審會。

1、產(chǎn)品需求評審會

幾乎每個產(chǎn)品在正式開發(fā)前的必經(jīng)環(huán)節(jié)。項目的相關(guān)人員通過需求評審會對產(chǎn)品經(jīng)理輸出的需求和解決方案進行合理性、可行性分析，而且還可以通過需求評審會來理解功能邏輯以及業(yè)務邏輯。

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

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

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

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

產(chǎn)品評審之后就進行項目規(guī)劃。

2、項目規(guī)劃的粒度

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

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

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

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

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

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

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

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

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

3、每日早會

每日早會，敏捷開發(fā)的一個重要環(huán)節(jié)。

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

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

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

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

4、提Bug的方式

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

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

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

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

5、階段總結(jié)會議

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

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

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

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

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

接著引申出：為什么會出現(xiàn)現(xiàn)在這種狀況？

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

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

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

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

6、總結(jié)

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

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