產品專案管理的流程

日前聽到同事對產品經理工作的概括“取捨需求，控制進度”，覺得第一個專案做到尾聲，需要總結一下第一個專案關於專案管理的一些思考。接下來小編為大家推薦的是產品專案管理的流程，歡迎閱讀。

專案啟動階段

任何一個專案，能夠被啟動，至少從戰略層面是得到公司認同和支援的，也就意味著這個專案是要揹負著實現公司的某一個戰略目標而存在的。產品經理在專案啟動前，有這麼幾個問題需要提前去了解和熟悉：

1、為什麼要立項？

2、專案目標是什麼？

3、專案的相關人員都有哪些？

4、怎麼立項？

第一個問題，為什麼要立項？

這個時候，作為產品經理的你需要去了解這個專案的來龍去脈，最好的方式是和你的上級或者BOSS溝通，因為他們掌握的資訊量遠遠比你大且比你多，所以通過和他們溝通再加上自己理解，就能夠對專案立項的原因有一個清晰的認知。當然，有時候專案立項，可能就是產品版本的定期迭代，這個時候產品經理對為什麼要立項恐怕是比誰都更清楚了。

第二個問題，專案目標是什麼？

產品經理作為專案的負責人，是一定要明白整個專案的目標是什麼，然後在裡面找出最核心的目標。例如有的專案是時間（越快越好，花多少錢無所謂），有的專案是錢（做慢點沒關係，但是要花最少的錢）。這些都可以通過跟你的領導聊一聊聊出這些資訊，知道了專案目標後你需要把這個目標用準確的文字寫下來。

對，一定要寫下來，因為口說無憑，再一個寫下來的東西才能成為所有人具體執行的方向和準則。

第三個問題，專案的相關人員都有哪些？

關於干係人，寶潔的方法論是找出PACE。P是Participant（參與者），A是Approver（審批者），C是Consultant（顧問），E是Executor（執行者）。當然，產品經理（尤其是創業公司的產品）在日常的專案工作中，恐怕不會有這麼繁瑣的流程，所以，也就遵循一切從簡的原則。

專案相關人員，可以從這幾個角度去考慮下，如哪些人或部門會受到專案結果的影響，哪些人可為專案提供資源（人、財、物）等。當然，在網際網路公司，常見的相關人員也就是老闆、產品經理、專案經理、專案團隊（包含設計、開發、測試、運維等）及使用者等。

找到了專案的相關人員後，現在你要做的就是把團隊成員綁到自己的船上。你需要去了解團隊裡每個成員的核心KPI，也就是他們於這個專案的需求是什麼，做這個專案可以給他們帶來什麼。如果這個專案沒被囊括在這個成員的工作評價 list 裡面，你需要去找他的老闆溝通。根據我的經驗，85%出工不出力的情況都是因為你的專案根本不會對這個成員的KPI有什麼正向的幫助。當然，如果找他的老闆溝通無效，還有最後一招，感情投資，請那個成員擼串、吃飯，利用感情讓他幫你做好這個專案。

第四個問題，怎麼立項？

通常來說，這個時候需要開一個專案啟動大會。這個啟動大會的目的是召集專案團隊成員，成員之間初步認識一下，產品經理主持會議，然後清楚地傳達專案要做什麼，目標是什麼，為什麼要做，怎麼做，誰來做等等。另外，跟所有的啟動大會一樣，專案的啟動大會，也需要給團隊成員來點雞湯、打點雞血。產品經理需要去統一團隊的思想，明確團隊的管理和運作方式，以及團隊的溝通機制等，產品經理需要動員團隊成員積極參與專案，並高質量地完成專案。

這個時候，專案相關的文件其實應該已經完成了，因為只有當詳細的產品需求文件有了之後，開發團隊才能估算專案時間及里程碑等。也有另一種情況，那就是專案本身包括了需求分析階段，所以詳細的需求文件是在立項之後才開始進行調研和撰寫。不管怎麼說，明確的產品需求和詳細的需求文件，都是專案得以順利進行的基本前提保障，所以，產品經理的規劃能力、撰寫文件的能力在這個時候就顯得尤為重要了。

專案計劃階段

完成了專案的啟動，接下來就要開始進行專案計劃了，所謂的專案計劃，其主要工作就是工作任務分解，任務優先順序安排，資源、工期、成本估算，以及風險計劃和溝通計劃等。

1、工作任務分解

工作任務分解，在專案管理中也有專門的術語叫做“工作分解結構”（WBS），指的是以可交付成果為導向對專案要素進行的分組。它其實歸納和定義了專案的整個工作範圍，從專案目標開始分解，逐層下降，每下降一層，代表對專案工作的更詳細的定義。

產品經理在每一個版本的迭代規劃中，都需要從產品需求池中撈一些比較重要的需求出來放到專案需求裡來，這正好符合敏捷開發的思想，飯是要一口一口吃的，專案也是一樣，不可能一次性把所有需求都搞定。所以，我們需要通過一個版本一個版本來完成，在做版本的工作任務分解的時候，一定要將任務分解到不能再分為止，任務的粒度一定要細，如果太粗，則很有可能會出現一些任務被忽略，從而影響整個專案的進度和計劃。

一般的工作任務分解方法有：按照產品的物理結構分解、按照產品的功能模組進行分解、按照實施過程來進行分解、或者是按照專案的地域分佈等。比較常用的是按功能模組來進行分解，再結合產品的實施過程來進行分解。

這裡需要注意的是，分解任務的過程中，需要將任務給描述清楚，否則團隊成員會不太明確自己究竟要做成什麼樣子或達到什麼樣的目標才算任務完成。

專案的工作任務分解，其實也可以運用我們之前提到過的MECE原則去進行檢查，工作任務必須全面、清晰、細分，任務責任需要到人，每一個子任務都能夠估算工作量和工期。

2、任務優先順序安排

任務分配好了，但總有輕重緩急之分。專案裡的優先順序排序，就是需要產品經理去識別專案任務清單裡的各種任務的相互關聯和依賴關係，並根據自己對需求優先順序的判斷，來對專案裡各項任務的先後順序進行安排和確定。

通俗地來說，產品經理要定義的就是先做哪些任務，後做哪些任務。其實這個時候往往又會用到我們在需求管理中使用到的工具KANO模型，通過明確任務的重要度和緊急度來梳理任務的優先順序，優先處理的是重要又緊急的任務。

在處理任務的優先順序安排時，有另一個非常重要的點需要明白，那就是有些任務與任務之間，存在著前置後置關係，只有在完成了一項任務的時候，我們才能開始下一個任務。所以在規劃優先順序的時候，需要把這種情況給考慮進去。

3、計劃呈現——甘特圖或其它

很多專案管理的書籍都推薦使用甘特圖來進行專案進度計劃的製作和呈現，一般都是通過微軟的Project、OpenProj等專業軟體進行繪製，還可以通過這些專業軟體直接檢視專案的關鍵路徑。也有一些產品經理或專案經理直接使用Excel來製作專案進度計劃表，畢竟他們對於表格的操作熟練程度已經足夠駕馭一個專案的進度計劃製作。

我是個比較注重使用者體驗的人，所以，上面兩種工具其實我都不怎麼使用，一般來說，我更喜歡通過團隊協作軟體中的專案管理功能，來實現專案計劃的呈現。

比如下面這樣的：

4、風險控制

通俗地來說，風險就是發生不幸事件的概率。任何一個專案都有風險，這就好比任何一次手術都有風險一樣，風險其實是無處不在的，是一種不以人的意志為轉移，獨立於人的意識之外而存在的事物。

我們先來看看常見的一些風險來源有哪些：

a、客戶沒有參與專案

如果你們公司的一個專案恰好是給客戶做的一個定製產品，但是在專案啟動、計劃和執行的階段，都沒有客戶的參與，客戶只是在最開始的時候給了一份文件，然後在專案收尾的時候來進行驗收，中間沒有絲毫地參與到專案中來，那麼客戶一旦發現最後的成果和自己當初設想的需求相去甚遠，結果就會變得非常糟糕。客戶有可能因此就不同意驗收專案，要求專案團隊重新返工開發，這個時候造成的工作量及時間的.損失、及對相關事件的影響則是不可估量的。

b、需求不明確或不完整

產品經理的需求說明文件出現不明確或不完整的情況，專案出現風險的概率也會比較大，因為專案的開發成員都是圍繞著需求設計文件來進行開發、測試的，如果產品經理能夠隨叫隨到，和開發及時討論清楚需求，則還能挽回一定的損失；而如果是異地開發，則整個專案便會比較悲催。

c、專案計劃的不合理

專案沒有如期完成，很有可能本身專案計劃就是有問題的。比如說，團隊成員的分工不合理、工期安排的也不合理（一般3個月才能完成的任務，非得要求1個月之內要上線）、資源沒有配置到位、工作任務的分解沒有細化沒有責任到人（這樣就會導致專案組的團隊成員對自己的任務不太清晰，即使分解了，沒有指定到人，也會發現影響專案進展）、還有一個就是任務的優先順序安排的不合理，導致後面任務的完成受到影響等。

d、團隊成員的精神狀態

一個專案能不能如期按時按質地完成，其中最主要因素還是人的因素，因此團隊成員的精神狀態也是影響專案成敗的風險之一。如果專案成員都如Scrum敏捷開發中提到的團隊成員一樣，都是自發組織和管理，參與專案的積極性比較高，專案風險就會大大降低。如果專案成員工作態度有問題，互相之間經常推諉任務責任，經常互相埋怨，那麼專案的成果則很令人擔憂。

e、領導變更

這裡的領導變更，主要是指專案開發到中途，領導突然說這個需求不對，應該朝另一個需求方向開發，那麼我們就稱之為領導變更。這裡的變更，大致分為兩種情況，一種是不太傷筋動骨的，也就是隻是小的需求修改，不涉及底層架構的重建；另一種呢，則是產品的規劃和定位不夠清晰，導致修改起來比較傷筋動骨，一個需求方向的改變，就可能讓開發重新搭建後臺架構，前端很多頁面也得跟著修改。當然，有時候產品經理也常常會犯這樣的錯誤，就是中途變更需求，這就要求產品經理在專案策劃的時候就把需求都想清楚，儘量減少專案開發到一半需求突然變更的情況。

f、技術風險

這裡說到的技術風險，指的是專案的開發組成員，他們在用程式碼實施專案的過程中，會發生一系列意想不到的情況，比如開發去做一個從來沒有做過的功能，這個時候可能需要先進行技術調研，可能最後的結果是光光是調研事件就話費了一兩個禮拜，留著開發的時間幾乎僅剩無幾。比如說網站掛了，一處理就一天時間進去了，原先手上的專案就只好拖延一天。

這裡列舉了一些常見的技術風險，產品經理們在做專案管理的過程中，還是稍微瞭解下比較好：

那說了這麼多的風險來源，有沒有什麼比較好的方法來規避這些風險呢？

答案是有，但是依然比較難規避掉所有的風險。

大家有沒有同感：出現專案偏離日程安排的情況，很少是因為工作耗費了比預期更長的時間，更常見的原因是，根本不在計劃中的工作使專案泥足深陷？如果身兼專案經理的你，深有同感，那麼，我們就可以體會到，專案中的風險是可以互通的。昨天的問題就是今天的風險，你的問題很可能就是我的風險。

因此，我們能做的比較好的一個方法就是，在專案初期，對上述風險來源進行逐一參考和排查，看看是否存在什麼問題。當然，更加隱祕的風險，恐怕也不是靠這種逐一排查的方法來發現的，更關鍵的點還是在於對日常專案狀態的洞察，這樣才能把所有的核心風險都呈現出來。

風險管理是一件非常耗費心力的事情，產品經理如果兼職做了專案管理的工作，就必須要做好相關的心理準備，畢竟內心強大也是產品經理必須具備的一個人格特質啊。