項目型產品的PM做事流程

1 人贊了文章

雖然很多大型公司都會有對應的產品經理和項目經理的崗位，但是一些互聯網公司，由於團隊規模的限制，產品經理往往也會承擔一定的項目管理職能。項目型產品經理為了保證產品每個版本如期上線，更關注產品的進度、質量管理、迭代計劃（如何正確的做事）以及對產品研發的資源調配，等等。

在傳統項目管理過程中，標誌一個項目開始的事件是項目立項，由項目經理填寫立項申請並提交可行性報告（市場可行性、技術可行性等），經過流程審批通過，則立項結束，項目正式開始。而在互聯網行業，並沒有立項這個過程，產品通過增量迭代的方式發布，用戶的需求不斷，產品的迭代不停止。在一次產品迭代過程中，大概會經歷以下幾個階段：

產品設計階段

產品經理從各個渠道收集用戶需求，這些需求有可能是用戶的真實反饋，有可能是公司的戰略規劃，也有可能是某個線上bug的修復，根據優先順序的不同，產品經理對這些需求進行優先順序排序。有了排序好的需求清單，產品經理就可以根據優先順序來進行需求調研和需求分析了，這個過程是伴隨產品迭代過程一起發生的。

有了初步的產品方案之後，我們要進行2個判斷：

• 我的方案是否對其他的產品或模塊有影響，很多產品經理容易忽略這一點，導致開發團隊在做到一半的時候發現問題導致項目延期甚至返工。如果涉及到其他產品或模塊，需要及時跟對應的產品經理進行溝通，提前判斷影響的點，補充自己的產品方案。
• 我的方案技術是否能夠實現，有一些產品經理天馬行空的想出一些能夠改變世界的idea，結果開發團隊一盆冷水告訴你技術實現不了。確定自己的方案技術是否能夠實現最好的辦法是跟項目經理溝通，如果項目經理不能確定，則由項目經理找對應的技術leader溝通。這裡千萬不要直接找技術leader，你的無意打斷會降低別人的工作效率。

此階段的輸入和輸出如下:

• 輸入：需求清單
• 輸出：產品需求文檔、交互稿、視覺稿

需求評審階段

• 可行性評審

初期，經常會遇到一個情況：開發團隊在實現某個產品需求時，突然發現產品設計上的一些漏洞，於是跟產品經理溝通之後，推翻之前的產品方案重做；產品經理沒有注意到產品或模塊間的影響，導致需要臨時調整方案以適應其他產品的節奏。這不僅造成了項目延期，也給團隊的氛圍帶來影響，開發團隊懷疑產品經理的能力，產品經理抱怨開發延期。經過跟幾位技術leader交流，大家一致認為，需要有一個流程在開發之前介入，來幫助團隊發現產品方案上面的一些問題，避免把問題帶到研發階段，所以就推出了可行性評審例會。

可行性評審例會一般每周會進行一次，視需求的情況而定，負責人會邀請評審小組參加例會。可行性評審的目的是主要由技術團隊發現其中可能存在的問題，給出建議。產品經理根據評審小組給出的建議優化產品方案，確保進入迭代階段時應該為當時最優的產品方案。

• 進度評審

經過前面的準備，產品方案基本定型下來，伴隨上一期迭代結束，項目經理組織團隊所有成員參與新一輪迭代的進度評審會議。會議開始先由產品經理給團隊成員解釋需求的背景，產品方案的設計，並解答大家的疑惑。接下來開發團隊的成員將從需求清單中挑選出滿足一次迭代所需要的需求組成當前的迭代計劃。挑選的過程，產品經理需要給出建議，產品經理需要從業務角度出發判斷當前版本應該主要解決哪些業務問題，開發團隊的成員不能只選擇優先順序較高的需求，或者不選擇優先順序較高的需求。

這裡，有一個調整，在初始時，團隊在會議上能夠給出每個需求需要拆分成幾個任務完成，每個任務需要花多長時間。後來發現，這樣的做法不僅效率不高，而且在開發團隊沒有對需求理解透徹的基礎上，給出的時間往往是不正確的，更別說任務的分解了。後來進行了調整，進度評審會議召開完成之後，我會要求開發團隊不要急於動手，先仔細消化需求文檔，然後由leader在下班前把每個需求需要拆解的任務和完成的時間節點告知我，由我收集整理成任務清單，通過郵件的方式告知團隊每一個成員，也標誌新的一輪迭代正式開始。

此階段的輸入和輸出如下：

• 輸入：產品需求文檔
• 輸出：任務清單

研發階段

進入研發階段，負責人需要隨時跟進開發團隊每日完成任務的情況，尤其要確保前後端需求開發進度的同步，以確保前後端順利對接、提測。可採用每日站立會的形式，每天早上固定的時間地點，跟開發團隊過一遍任務完成的情況，如果發現某個需求進度落後了，則會在會後去了解情況，做出調整。另外開發團隊在實現需求時，一定要按照任務的優先順序進行，切不可隨意進行，這也是負責人需要控制的。

另外，比較重要的是，要想做到敏捷迭代，團隊一定要適應每日集成的節奏。有些開發人員的習慣是完成所有的需求再提交代碼，這不僅給測試團隊造成工作量突增的問題，還有可能導致其他人提交的代碼無法測試。另外，在一些互聯網團隊，喜歡將所有需求開發完成最後再提交測試，導致測試團隊前後期工作量不均衡，團隊抱怨測試時間太長。每日集成要求開發團隊在完成一個任務清單上的任務時，確保跟其他任務沒有耦合的情況下，提交代碼測試，而測試團隊每天需要收集開發團隊已完成的任務制定第二天的測試計劃。

在迭代的最後階段，測試團隊會對本期迭代進行整體回歸，做好上線之前最後的測試。此階段一般是拒絕任務產品需求的變更的，負責人需要跟產品經理明確需求變更帶來的後果，如果產品經理接受後果，負責人需要通過郵件的形式告知項目組成員和相關人員，並說明便跟的原因。

此階段的輸入和輸出如下：

• 輸入：任務清單
• 輸出：待發布的增量包

產品發布階段

產品發布後，並不代表本期迭代就結束了，負責人需要在迭代結束之後，召開迭代總結會議，一是回顧本次迭代過程中，出現過什麼問題，後續該怎麼解決；二是回顧上次總結的一些問題有沒有得到解決，問題是否依然持續。迭代總結記錄是會議的一個重要產物，項目經理需要在會議結束後，協調關聯的人員解決問題。如果沒有解決問題的過程，迭代總結會議形同虛設，只是一個形式而已。迭代總結會議不僅能夠幫助團隊發現問題，還能夠增強團隊的凝聚力。

此階段的輸入和輸出如下：

• 輸入：迭代的回顧
• 輸出：迭代總結記錄

推薦閱讀：