“聞道有先後，術業有專攻”，一個優秀的專案經理在產品迭代的過程中，有著不可小覷的作用。然而在大部分公司，由於團隊規模的限制，產品經理往往會承擔一定的專案管理職能，那麼產品經理應該如何做好專案管理呢。下面就產品經理如何進行專案管理這一話題給大家帶來分享。

1流程篇

在傳統的專案管理過程中，標誌一個專案開始的事件是專案立項，由專案經理填寫立項申請並提交可行性報告（市場可行性、技術可行性等），如果領導審批透過，則立項結束，專案正式開始。而在網際網路時代，並沒有立項這個過程，產品透過增量迭代的方式釋出，使用者的需求不斷，產品的迭代不停止。在一次產品迭代過程中，大概會經歷以下幾個階段：

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

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

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

（3）此階段的輸入和輸出如下：輸入：需求清單輸出：產品需求文件、互動稿、視覺稿

2、需求評審階段（1）可行性評審專案經理初期，經常會遇到一個情況：開發團隊在實現某個產品需求時，突然發現產品設計上的一些漏洞，於是跟產品經理溝通之後，推翻之前的產品方案重做；產品經理沒有注意到產品或模組間的影響，導致需要臨時調整方案以適應其他產品的節奏。這不僅造成了專案延期，也給團隊的氛圍帶來影響，開發團隊懷疑產品經理的能力，產品經理抱怨開發延期。經過跟幾位技術leader交流，大家一致認為，需要有一個流程在開發之前介入，來幫助團隊發現產品方案上面的一些問題，避免把問題帶到研發階段，所以就推出了可行性評審例會。可行性評審例會一般每週會進行一次，視需求的情況而定，專案經理會邀請評審小組參加例會。可行性評審的目的是主要由技術團隊發現其中可能存在的問題，給出建議。產品經理根據評審小組給出的建議最佳化產品方案，確保進入迭代階段時應該為當時最優的產品方案。

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

（3）此階段的輸入和輸出如下：輸入：產品需求文件輸出：任務清單

3、研發階段

進入研發階段，專案經理需要隨時跟進開發團隊每日完成任務的情況，尤其要確保前後端需求開發進度的同步，以確保前後端順利對接、提測。

另外，比較重要的是，要想做到敏捷迭代，團隊一定要適應每日整合的節奏。有些開發人員的習慣是完成所有的需求再提交程式碼，這不僅給測試團隊造成工作量突增的問題，還有可能導致其他人提交的程式碼無法測試。

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

此階段的輸入和輸出如下：輸入：任務清單輸出：待發布的增量包

4、產品釋出階段

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

此階段的輸入和輸出如下：輸入：迭代的回顧輸出：迭代總結記錄

2工件篇

1、需求清單

①描述：描述是用來記錄需求的詳細資訊，描述中的語言一定不能產生歧義，否則會給開發團隊帶來困擾。②優先順序：優先順序決定了需求調研的先後順序、需求開發的先後順序，我們採用四象限的方式來定義需求的優先順序。③狀態：狀態標記了需求目前所處的情況，需求清單應該是一個公開的清單，任何人都可以檢視清單的資訊，因此狀態一定要跟實際情況一致，及時反映需求的進展。④提出人：提出人資訊是為了方便對需求進行追溯，由誰提出的需求，後續關於該需求的變更都要及時告知提出者。

2、任務清單

任務清單列表是一組當前迭代選出的任務代辦事項列表，該列表由專案組成員維護，並交由測試人員監控。專案組成員根據迭代計劃對需求進行分解，將需求分解為一個個可以獨立部署的任務計劃，測試團隊根據專案組成員給出的任務清單跟蹤任務完成情況並督促開發人員提測，做到持續整合。專案組成員確保把最優資源投入到高優先順序需求上。這裡有兩個難點：

①需求分解：作為產品經理代理專案經理，很難做好需求分解和進度評估工作，需要產品經理有一定的技術功底，能夠大概知道背後的實現邏輯如何；另外你還必須充分信任開發團隊，信任他們所給出的時間節點。②持續整合：持續整合在一定程度上，增加了程式碼合併的工作量，也容易引人其他開發成員帶來的bug，但只有做到持續整合，才能算是敏捷的開發。

3、專案週報

專案週報是對一週專案迭代的情況彙報以及下週專案組的工作計劃，另外對於專案管理過程中出現的一些問題，例如流程上的漏洞、資源的欠缺都要及時向上反饋，以便獲得領導的支援，切忌報喜不報憂。

4、迭代總結

迭代總結是在整個專案管理過程中，比較重要的一個環節。很多產品經理甚至專業的專案經理都容易疏忽這一點。迭代總結的重要性在於，它能如實的反映專案迭代過程中存在的一些問題，並根據這些問題進行跟蹤改進。記錄問題只是其中的一部分，重要的是作為專案經理的你有沒有事後去推動改良這些事情，不然迭代總結只是一個形式主義。

3管理篇

任何管理，從本質上來講，都是管人。專案管理也不例外，一個專案能否順利完成，要看專案組的成員是否有一致的目標，並且願意為這個目標主動去付出，直至專案完成。太多的專案管理的乾貨在教大家如何進行專案管理，要用哪些工具，使用哪些方法，很少有從對人的管理的角度去說如何進行專案管理的。

1、專案開始要樹立目標

給團隊樹立一個可以達到的目標，這個目標不一定是多麼的遠大，可以是一個產品的細節的改動能夠帶來多少轉化率的提升，可以是一個模組的重構能夠帶來整個流程上更順暢的體驗，也可以是一個新的功能給公司帶來成本的節約，這樣的目標能夠幫助團隊統一思想意識，讓團隊每個人對目標認可，融小我於大我，從而增強團隊凝聚力，提高生產效率。

2、佈置工作要明確要求

當你要佈置工作時，你要詳細的告知任務的背景，有助於其理解他所做的事情；要告知驗收的標準，有助於其不偏差的完成任務；要告知完成的時候，以便於其做好工作計劃。有時候一項任務有可能會涉及到多人，這時你還要明確每個人的分工和主要的責任人。有時候你覺得團隊沒有執行力的時候，先反問自己有沒有做到上述的這些事情。

3、做一個主動推動事情的人

很多人嘗試把方法論運用到專案管理去，卻怎麼做也做不好，他們糾結於用實體形式的看板還是軟體形式的看板；看板上的貼條是不是格式不對；專案週報的格式應該是怎樣的，然後指望透過這些工具和方法論就能夠把專案管理做好，實際上專案管理遠遠不止如此。

專案迭代開始後，不要指望開發人員每天會自動的更新任務進度，事實上，你往往會看到，他們總在迭代的最後階段一下子變更了好幾個需求的狀態；你也不要指望透過專案週報來掌握專案迭代的進度，當你一週之後才發現專案存在延期的風險時，已經來不及了。你需要經常詢問專案成員需求完成的請問，一方面是根據成員完成的情況及時做好前後端的對接或任務調整；一方面當你發現專案存在風險時，提前規避或提前說明；最後，對專案組成員已經完成的需求給予肯定，對專案組成員在工作上遇到的問題給予幫助，掃清迭代中的障礙。

除了主動的去了解專案成員完成任務的情況，在專案管理過程中，還要善於去發現問題，發現流程上的不足，不斷的改進改善流程，把例外變成例內。方法論再好，需求分解的再詳細，專案迭代都不會自動實現，做專案管理不是做甩手掌櫃。

4、互相尊重

在專案管理過程中，你可能會遇到在專案進行到某一階段，遇到了突發情況，專案無法正常進行下去。此時，某些專案管理者可能會使用自己的職能，直接提出解決方案，讓專案成員執行。敏捷迭代的方法論中有說，團隊要自組織，要尊重團隊每個人員的專業能力。專案經理代表的不是他的專業能力，而是代表他所管理的這個群體的整體利益，這種情況你唯一要做的事情，就是幫他排除障礙，如果他需要討論，你就幫助他召集相關人員討論；如果他需要查閱資料，你就幫他準備好相關的材料。當你尊重了別人的能力，你也會收穫更多的尊重和領導力。

5、開放交流做專案管理，除了需要管理專案迭代，還需要管理人。員工處於什麼狀態，你心理是否有數，那個誰誰誰最新為什麼情緒這麼低落，那個誰誰誰最近為什麼這麼消極，那個誰誰誰最近表現還可以，那個誰誰誰最近實現的需求老是出嚴重bug是不是遇到了什麼事情。不良的風氣很容易影響團隊的價值傾向。

6、幫助團隊成員成長專案經理所代表的是團隊整體的利益，對外是無線專案組的專案經理，別人認可你是因為你的團隊是執行力最強的團隊，而別人的對你的認可來自於團隊成員每一個人的付出，你無法居功自傲的說是因為你自己很牛逼。

為了幫助團隊成員成長，你需要做的事情是把成員付出的努力及時的讓上級知曉，做到這一點並不難，只需要在週報中，時不時的告知上級，誰誰誰在這次迭代中，花了多少心思，為專案付出了多大努力，為其爭取儘可能的福利。另外，鼓勵成員互相分享心得，把自己的經驗與他人共享，共同成長。最後，當團隊遇到問題時，你要作為第一責任人主動思考原因，而不是直接責問他人為什麼沒有把事做好。除了這些，幫團隊爭取福利，組織好的拓展活動，加強團隊成員之間的凝聚力，這些都是作為專案經理力所能及的。

這個問題在國內非常普遍，我們接觸到的很多企業都存在和你說的類似的情況

坦率地說這不是說上一個什麼PM，ERP軟體就能解決的問題。

關鍵還是在你所在企業的管理方法上面，軟體是一種使能技術。因此在上系統前必須先要有專案管理思想。