|
來人人都是產品經理【起點學院】,，BAT實戰(zhàn)派產品總監(jiān)手把手系統(tǒng)帶你學產品、學運營,。 
“聞道有先后,，術業(yè)有專攻”，一個優(yōu)秀的項目經理在產品迭代的過程中,，有著不可小覷的作用,。然而在大部分互聯網公司，由于團隊規(guī)模的限制,，產品經理往往會承擔一定的項目管理職能，那么產品經理應該如何做好項目管理呢,。我曾在任職期間以產品經理身份兼任項目經理一職,，就產品經理如何進行項目管理這一話題給大家?guī)矸窒怼?/p>
上一篇講到了項目管理的一些理論知識，這篇文章中給大家?guī)磉@些理論知識如何在整個項目管理過程中實施,。在傳統(tǒng)的項目管理過程中,，標志一個項目開始的事件是項目立項，由項目經理填寫立項申請并提交可行性報告（市場可行性,、技術可行性等）,，如果領導審批通過，則立項結束，項目正式開始,。而在互聯網行業(yè),，并沒有立項這個過程，產品通過增量迭代的方式發(fā)布,，用戶的需求不斷,，產品的迭代不停止。在一次產品迭代過程中,，大概會經歷以下幾個階段：
產品設計階段產品經理從各個渠道收集用戶需求,，這些需求有可能是用戶的真實反饋，有可能是公司的戰(zhàn)略規(guī)劃,，也有可能是某個線上bug的修復,，根據優(yōu)先級的不同，產品經理對這些需求進行優(yōu)先級排序,。有了排序好的需求清單,，產品經理就可以根據優(yōu)先級來進行需求調研和需求分析了，這個過程是伴隨產品迭代過程一起發(fā)生的,。 有了初步的產品方案之后,，我們要進行2個判斷：
此階段的輸入和輸出如下:
需求評審階段可行性評審 在我兼任項目經理初期，經常會遇到一個情況：開發(fā)團隊在實現某個產品需求時,，突然發(fā)現產品設計上的一些漏洞,，于是跟產品經理溝通之后，推翻之前的產品方案重做,；產品經理沒有注意到產品或模塊間的影響,，導致需要臨時調整方案以適應其他產品的節(jié)奏,。這不僅造成了項目延期，也給團隊的氛圍帶來影響,，開發(fā)團隊懷疑產品經理的能力,，產品經理抱怨開發(fā)延期。經過跟幾位技術leader交流,，大家一致認為,，需要有一個流程在開發(fā)之前介入，來幫助團隊發(fā)現產品方案上面的一些問題,，避免把問題帶到研發(fā)階段,，所以就推出了可行性評審例會。 可行性評審例會一般每周會進行一次,，視需求的情況而定,，項目經理會邀請評審小組參加例會?？尚行栽u審的目的是主要由技術團隊發(fā)現其中可能存在的問題,，給出建議。產品經理根據評審小組給出的建議優(yōu)化產品方案,，確保進入迭代階段時應該為當時最優(yōu)的產品方案,。 進度評審 經過前面的準備，產品方案基本定型下來,，伴隨上一期迭代結束,，項目經理組織團隊所有成員參與新一輪迭代的進度評審會議。會議開始先由產品經理給團隊成員解釋需求的背景,，產品方案的設計,，并解答大家的疑惑。接下來開發(fā)團隊的成員將從需求清單中挑選出滿足一次迭代所需要的需求組成當前的迭代計劃,。挑選的過程,，產品經理需要給出建議，產品經理需要從業(yè)務角度出發(fā)判斷當前版本應該主要解決哪些業(yè)務問題,，開發(fā)團隊的成員不能只選擇優(yōu)先級較高的需求,，或者不選擇優(yōu)先級較高的需求。 這里,，我在兼任項目經理期間有一個調整,，在初始時，我要求團隊在會議上能夠給出每個需求需要拆分成幾個任務完成,，每個任務需要花多長時間。后來發(fā)現,，這樣的做法不僅效率不高,，而且在開發(fā)團隊沒有對需求理解透徹的基礎上,，給出的時間往往是不正確的，更別說任務的分解了,。后來進行了調整,，進度評審會議召開完成之后，我會要求開發(fā)團隊不要急于動手,，先仔細消化需求文檔,，然后由leader在下班前把每個需求需要拆解的任務和完成的時間節(jié)點告知我，由我收集整理成任務清單,，通過郵件的方式告知團隊每一個成員,，也標志新的一輪迭代正式開始。 此階段的輸入和輸出如下：
研發(fā)階段進入研發(fā)階段,，項目經理需要隨時跟進開發(fā)團隊每日完成任務的情況,，尤其要確保前后端需求開發(fā)進度的同步，以確保前后端順利對接,、提測,。我在兼任項目經理期間，采用每日站立會的形式,，每天早上固定的時間地點,，跟開發(fā)團隊過一遍任務完成的情況，如果發(fā)現某個需求進度落后了,，則會在會后去了解情況,，做出調整。另外開發(fā)團隊在實現需求時,，一定要按照任務的優(yōu)先級進行,，切不可隨意進行，這也是項目經理需要控制的,。 另外,，比較重要的是，要想做到敏捷迭代,，團隊一定要適應每日集成的節(jié)奏,。有些開發(fā)人員的習慣是完成所有的需求再提交代碼，這不僅給測試團隊造成工作量突增的問題,，還有可能導致其他人提交的代碼無法測試,。另外，在一些互聯網團隊,，喜歡將所有需求開發(fā)完成最后再提交測試,，導致測試團隊前后期工作量不均衡，團隊抱怨測試時間太長,。每日集成要求開發(fā)團隊在完成一個任務清單上的任務時,，確保跟其他任務沒有耦合的情況下,，提交代碼測試，而測試團隊每天需要收集開發(fā)團隊已完成的任務制定第二天的測試計劃,。 在迭代的最后階段,，測試團隊會對本期迭代進行整體回歸，做好上線之前最后的測試,。此階段一般是拒絕任務產品需求的變更的,，項目經理需要跟產品經理明確需求變更帶來的后果，如果產品經理接受后果,，項目經理需要通過郵件的形式告知項目組成員和相關人員,，并說明便跟的原因。 此階段的輸入和輸出如下：
產品發(fā)布階段產品發(fā)布后,，并不代表本期迭代就結束了,，項目經理需要在迭代結束之后，召開迭代總結會議,，一是回顧本次迭代過程中,，出現過什么問題，后續(xù)該怎么解決,；二是回顧上次總結的一些問題有沒有得到解決,，問題是否依然持續(xù)。迭代總結記錄是會議的一個重要產物,，項目經理需要在會議結束后,，協調關聯的人員解決問題。如果沒有解決問題的過程,，迭代總結會議形同虛設,，只是一個形式而已。迭代總結會議不僅能夠幫助團隊發(fā)現問題,，還能夠增強團隊的凝聚力,。 |
|
|
