這篇文章，我們來開始講講好的項目管理流程大概是什么樣子的。
大體說來，一個項目管理的流程分為這么幾個階段：
項目啟動——項目計劃——項目執行和監控——項目收尾
如果用一幅圖來表示的話，大概會是這個樣子的：
在整個項目的運轉過程中，從最開始的來自領導的戰略規劃啟動了項目，到前期的項目計劃、需求轉化與中期的項目執行和跟進，以及后期的項目收尾總結會，每一個環節都有產品經理的身影。尤其是在初創公司，產品經理大多數的時間也擔任項目經理這樣一個角色。所以對于初創公司的產品們來說，了解項目管理的大致流程，合理分配資源就顯得更加重要了。
我們來一一梳理下，產品經理如果來負責一個項目的管理，在每一個階段都要做哪些工作。
項目啟動階段
任何一個項目，能夠被啟動，至少從戰略層面是得到公司認同和支持的，也就意味著這個項目是要背負著實現公司的某一個戰略目標而存在的。產品經理在項目啟動前，有這么幾個問題需要提前去了解和熟悉：
1、為什么要立項？
2、項目目標是什么？
3、項目的相關人員都有哪些？
4、怎么立項？
第一個問題，為什么要立項？
這個時候，作為產品經理的你需要去了解這個項目的來龍去脈，最好的方式是和你的上級或者BOSS溝通，因為他們掌握的信息量遠遠比你大且比你多，所以通過和他們溝通再加上自己理解，就能夠對項目立項的原因有一個清晰的認知。當然，有時候項目立項，可能就是產品版本的定期迭代，這個時候產品經理對為什么要立項恐怕是比誰都更清楚了。
第二個問題，項目目標是什么？
產品經理作為項目的負責人，是一定要明白整個項目的目標是什么，然后在里面找出最核心的目標。例如有的項目是時間（越快越好，花多少錢無所謂），有的項目是錢（做慢點沒關系，但是要花最少的錢）。這些都可以通過跟你的領導聊一聊聊出這些信息，知道了項目目標后你需要把這個目標用準確的文字寫下來。
對，一定要寫下來，因為口說無憑，再一個寫下來的東西才能成為所有人具體執行的方向和準則。
第三個問題，項目的相關人員都有哪些？
關于干系人，寶潔的方法論是找出PACE。P是Participant（參與者），A是Approver（審批者），C是Consultant（顧問），E是Executor（執行者）。當然，產品經理（尤其是創業公司的產品）在日常的項目工作中，恐怕不會有這么繁瑣的流程，所以，也就遵循一切從簡的原則。
項目相關人員，可以從這幾個角度去考慮下，如哪些人或部門會受到項目結果的影響，哪些人可為項目提供資源（人、財、物）等。當然，在互聯網公司，常見的相關人員也就是老板、產品經理、項目經理、項目團隊（包含設計、開發、測試、運維等）及用戶等。
找到了項目的相關人員后，現在你要做的就是把團隊成員綁到自己的船上。你需要去了解團隊里每個成員的核心KPI，也就是他們于這個項目的需求是什么，做這個項目可以給他們帶來什么。如果這個項目沒被囊括在這個成員的工作評價 list 里面，你需要去找他的老板溝通。根據我的經驗，85%出工不出力的情況都是因為你的項目根本不會對這個成員的KPI有什么正向的幫助。當然，如果找他的老板溝通無效，還有最后一招，感情投資，請那個成員擼串、吃飯，利用感情讓他幫你做好這個項目。
第四個問題，怎么立項？
通常來說，這個時候需要開一個項目啟動大會。這個啟動大會的目的是召集項目團隊成員，成員之間初步認識一下，產品經理主持會議，然后清楚地傳達項目要做什么，目標是什么，為什么要做，怎么做，誰來做等等。另外，跟所有的啟動大會一樣，項目的啟動大會，也需要給團隊成員來點雞湯、打點雞血。產品經理需要去統一團隊的思想，明確團隊的管理和運作方式，以及團隊的溝通機制等，產品經理需要動員團隊成員積極參與項目，并高質量地完成項目。
這個時候，項目相關的文檔其實應該已經完成了，因為只有當詳細的產品需求文檔有了之后，開發團隊才能估算項目時間及里程碑等。也有另一種情況，那就是項目本身包括了需求分析階段，所以詳細的需求文檔是在立項之后才開始進行調研和撰寫。不管怎么說，明確的產品需求和詳細的需求文檔，都是項目得以順利進行的基本前提保障，所以，產品經理的規劃能力、撰寫文檔的能力在這個時候就顯得尤為重要了。
項目計劃階段
完成了項目的啟動，接下來就要開始進行項目計劃了，所謂的項目計劃，其主要工作就是工作任務分解，任務優先級安排，資源、工期、成本估算，以及風險計劃和溝通計劃等。
1、工作任務分解
工作任務分解，在項目管理中也有專門的術語叫做“工作分解結構”（WBS），指的是以可交付成果為導向對項目要素進行的分組。它其實歸納和定義了項目的整個工作范圍，從項目目標開始分解，逐層下降，每下降一層，代表對項目工作的更詳細的定義。
產品經理在每一個版本的迭代規劃中，都需要從產品需求池中撈一些比較重要的需求出來放到項目需求里來，這正好符合敏捷開發的思想，飯是要一口一口吃的，項目也是一樣，不可能一次性把所有需求都搞定。所以，我們需要通過一個版本一個版本來完成，在做版本的工作任務分解的時候，一定要將任務分解到不能再分為止，任務的粒度一定要細，如果太粗，則很有可能會出現一些任務被忽略，從而影響整個項目的進度和計劃。
一般的工作任務分解方法有：按照產品的物理結構分解、按照產品的功能模塊進行分解、按照實施過程來進行分解、或者是按照項目的地域分布等。比較常用的是按功能模塊來進行分解，再結合產品的實施過程來進行分解。
以微信公眾號的開發為例，微信公眾號的開發就涉及微信端開發和PC管理后臺的開發，這個時候如果進行任務分解，最基本的方向就要分為微信端任務開發、PC管理端任務開發。而微信端任務開發，又可細分為需求梳理、產品設計、前端頁面實現、后臺接口支持、測試任務等；PC管理端的任務開發也是如此，也細分為需求梳理、產品設計、前端頁面實現、后臺接口支持、測試任務等，如果再細分功能模塊，則可分為“群發消息”、“自動回復”、“用戶管理”、“消息管理”等功能模塊的需求梳理、產品設計、前端頁面實現、后臺接口支持、測試任務等；
這里需要注意的是，分解任務的過程中，需要將任務給描述清楚，否則團隊成員會不太明確自己究竟要做成什么樣子或達到什么樣的目標才算任務完成。
項目的工作任務分解，其實也可以運用我們之前提到過的MECE原則去進行檢查，工作任務必須全面、清晰、細分，任務責任需要到人，每一個子任務都能夠估算工作量和工期。
2、任務優先級安排
任務分配好了，但總有輕重緩急之分。項目里的優先級排序，就是需要產品經理去識別項目任務清單里的各種任務的相互關聯和依賴關系，并根據自己對需求優先級的判斷，來對項目里各項任務的先后順序進行安排和確定。
通俗地來說，產品經理要定義的就是先做哪些任務，后做哪些任務。其實這個時候往往又會用到我們在需求管理中使用到的工具KANO模型，通過明確任務的重要度和緊急度來梳理任務的優先級，優先處理的是重要又緊急的任務。
在處理任務的優先級安排時，有另一個非常重要的點需要明白，那就是有些任務與任務之間，存在著前置后置關系，只有在完成了一項任務的時候，我們才能開始下一個任務。所以在規劃優先級的時候，需要把這種情況給考慮進去。
3、計劃呈現——甘特圖或其它
很多項目管理的書籍都推薦使用甘特圖來進行項目進度計劃的制作和呈現，一般都是通過微軟的Project、OpenProj等專業軟件進行繪制，還可以通過這些專業軟件直接查看項目的關鍵路徑。也有一些產品經理或項目經理直接使用Excel來制作項目進度計劃表，畢竟他們對于表格的操作熟練程度已經足夠駕馭一個項目的進度計劃制作。
我是個比較注重用戶體驗的人，所以，上面兩種工具其實我都不怎么使用，一般來說，我更喜歡通過團隊協作軟件中的項目管理功能，來實現項目計劃的呈現。
比如下面這樣的：
4、風險控制
通俗地來說，風險就是發生不幸事件的概率。任何一個項目都有風險，這就好比任何一次手術都有風險一樣，風險其實是無處不在的，是一種不以人的意志為轉移，獨立于人的意識之外而存在的事物。
我們先來看看常見的一些風險來源有哪些：
a、客戶沒有參與項目
如果你們公司的一個項目恰好是給客戶做的一個定制產品，但是在項目啟動、計劃和執行的階段，都沒有客戶的參與，客戶只是在最開始的時候給了一份文檔，然后在項目收尾的時候來進行驗收，中間沒有絲毫地參與到項目中來，那么客戶一旦發現最后的成果和自己當初設想的需求相去甚遠，結果就會變得非常糟糕。客戶有可能因此就不同意驗收項目，要求項目團隊重新返工開發，這個時候造成的工作量及時間的損失、及對相關事件的影響則是不可估量的。
b、需求不明確或不完整
產品經理的需求說明文檔出現不明確或不完整的情況，項目出現風險的概率也會比較大，因為項目的開發成員都是圍繞著需求設計文檔來進行開發、測試的，如果產品經理能夠隨叫隨到，和開發及時討論清楚需求，則還能挽回一定的損失；而如果是異地開發，則整個項目便會比較悲催。
c、項目計劃的不合理
項目沒有如期完成，很有可能本身項目計劃就是有問題的。比如說，團隊成員的分工不合理、工期安排的也不合理（一般3個月才能完成的任務，非得要求1個月之內要上線）、資源沒有配置到位、工作任務的分解沒有細化沒有責任到人（這樣就會導致項目組的團隊成員對自己的任務不太清晰，即使分解了，沒有指定到人，也會發現影響項目進展）、還有一個就是任務的優先級安排的不合理，導致后面任務的完成受到影響等。
d、團隊成員的精神狀態
一個項目能不能如期按時按質地完成，其中最主要因素還是人的因素，因此團隊成員的精神狀態也是影響項目成敗的風險之一。如果項目成員都如Scrum敏捷開發中提到的團隊成員一樣，都是自發組織和管理，參與項目的積極性比較高，項目風險就會大大降低。如果項目成員工作態度有問題，互相之間經常推諉任務責任，經常互相埋怨，那么項目的成果則很令人擔憂。
e、領導變更
這里的領導變更，主要是指項目開發到中途，領導突然說這個需求不對，應該朝另一個需求方向開發，那么我們就稱之為領導變更。這里的變更，大致分為兩種情況，一種是不太傷筋動骨的，也就是只是小的需求修改，不涉及底層架構的重建；另一種呢，則是產品的規劃和定位不夠清晰，導致修改起來比較傷筋動骨，一個需求方向的改變，就可能讓開發重新搭建后臺架構，前端很多頁面也得跟著修改。當然，有時候產品經理也常常會犯這樣的錯誤，就是中途變更需求，這就要求產品經理在項目策劃的時候就把需求都想清楚，盡量減少項目開發到一半需求突然變更的情況。
f、技術風險
這里說到的技術風險，指的是項目的開發組成員，他們在用代碼實施項目的過程中，會發生一系列意想不到的情況，比如開發去做一個從來沒有做過的功能，這個時候可能需要先進行技術調研，可能最后的結果是光光是調研事件就話費了一兩個禮拜，留著開發的時間幾乎僅剩無幾。比如說網站掛了，一處理就一天時間進去了，原先手上的項目就只好拖延一天。
這里列舉了一些常見的技術風險，產品經理們在做項目管理的過程中，還是稍微了解下比較好：
那說了這么多的風險來源，有沒有什么比較好的方法來規避這些風險呢？
答案是有，但是依然比較難規避掉所有的風險。
大家有沒有同感：出現項目偏離日程安排的情況，很少是因為工作耗費了比預期更長的時間，更常見的原因是，根本不在計劃中的工作使項目泥足深陷？如果身兼項目經理的你，深有同感，那么，我們就可以體會到，項目中的風險是可以互通的。昨天的問題就是今天的風險，你的問題很可能就是我的風險。
因此，我們能做的比較好的一個方法就是，在項目初期，對上述風險來源進行逐一參考和排查，看看是否存在什么問題。當然，更加隱秘的風險，恐怕也不是靠這種逐一排查的方法來發現的，更關鍵的點還是在于對日常項目狀態的洞察，這樣才能把所有的核心風險都呈現出來。
風險管理是一件非常耗費心力的事情，產品經理如果兼職做了項目管理的工作，就必須要做好相關的心理準備，畢竟內心強大也是產品經理必須具備的一個人格特質啊。
