中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

“聞道有先后，術業有專攻”，一個優秀的項目經理在產品迭代的過程中，有著不可小覷的作用。然而在大部分互聯網公司，由于團隊規模的限制，產品經理往往會承擔一定的項目管理職能，那么產品經理應該如何做好項目管理呢。我曾在任職期間以產品經理身份兼任項目經理一職，就產品經理如何進行項目管理這一話題給大家帶來分享。

上一篇講到了項目管理的一些理論知識，這篇文章中給大家帶來這些理論知識如何在整個項目管理過程中實施。在傳統的項目管理過程中，標志一個項目開始的事件是項目立項，由項目經理填寫立項申請并提交可行性報告（市場可行性、技術可行性等），如果領導審批通過，則立項結束，項目正式開始。而在互聯網行業，并沒有立項這個過程，產品通過增量迭代的方式發布，用戶的需求不斷，產品的迭代不停止。在一次產品迭代過程中，大概會經歷以下幾個階段：

產品設計階段

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

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

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

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

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

需求評審階段

可行性評審

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

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

進度評審

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

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

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

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

研發階段

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

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

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

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

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

產品發布階段

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

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

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

作者：周沛沛（微信號nyyzpp），點我吧產品經理。文能寫文檔，武能改BUG。

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