這篇文章，我們來開始講講好的項目管理流程大概是什么樣子的。

大體說來，一個項目管理的流程分為這么幾個階段：

項目啟動——項目計劃——項目執(zhí)行和監(jiān)控——項目收尾

如果用一幅圖來表示的話，大概會是這個樣子的：

在整個項目的運(yùn)轉(zhuǎn)過程中，從最開始的來自領(lǐng)導(dǎo)的戰(zhàn)略規(guī)劃啟動了項目，到前期的項目計劃、需求轉(zhuǎn)化與中期的項目執(zhí)行和跟進(jìn)，以及后期的項目收尾總結(jié)會，每一個環(huán)節(jié)都有產(chǎn)品經(jīng)理的身影。尤其是在初創(chuàng)公司，產(chǎn)品經(jīng)理大多數(shù)的時間也擔(dān)任項目經(jīng)理這樣一個角色。所以對于初創(chuàng)公司的產(chǎn)品們來說，了解項目管理的大致流程，合理分配資源就顯得更加重要了。

我們來一一梳理下，產(chǎn)品經(jīng)理如果來負(fù)責(zé)一個項目的管理，在每一個階段都要做哪些工作。

項目啟動階段

任何一個項目，能夠被啟動，至少從戰(zhàn)略層面是得到公司認(rèn)同和支持的，也就意味著這個項目是要背負(fù)著實現(xiàn)公司的某一個戰(zhàn)略目標(biāo)而存在的。產(chǎn)品經(jīng)理在項目啟動前，有這么幾個問題需要提前去了解和熟悉：

1. 為什么要立項？
2. 項目目標(biāo)是什么？
3. 項目的相關(guān)人員都有哪些？
4. 怎么立項？

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

這個時候，作為產(chǎn)品經(jīng)理的你需要去了解這個項目的來龍去脈，最好的方式是和你的上級或者BOSS溝通，因為他們掌握的信息量遠(yuǎn)遠(yuǎn)比你大且比你多，所以通過和他們溝通再加上自己理解，就能夠?qū)椖苛㈨椀脑蛴幸粋€清晰的認(rèn)知。當(dāng)然，有時候項目立項，可能就是產(chǎn)品版本的定期迭代，這個時候產(chǎn)品經(jīng)理對為什么要立項恐怕是比誰都更清楚了。

第二個問題，項目目標(biāo)是什么？

產(chǎn)品經(jīng)理作為項目的負(fù)責(zé)人，是一定要明白整個項目的目標(biāo)是什么，然后在里面找出最核心的目標(biāo)。例如有的項目是時間（越快越好，花多少錢無所謂），有的項目是錢（做慢點(diǎn)沒關(guān)系，但是要花最少的錢）。這些都可以通過跟你的領(lǐng)導(dǎo)聊一聊聊出這些信息，知道了項目目標(biāo)后你需要把這個目標(biāo)用準(zhǔn)確的文字寫下來。

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

第三個問題，項目的相關(guān)人員都有哪些？

關(guān)于干系人，寶潔的方法論是找出PACE。P是Participant（參與者），A是Approver（審批者），C是Consultant（顧問），E是Executor（執(zhí)行者）。當(dāng)然，產(chǎn)品經(jīng)理（尤其是創(chuàng)業(yè)公司的產(chǎn)品）在日常的項目工作中，恐怕不會有這么繁瑣的流程，所以，也就遵循一切從簡的原則。

項目相關(guān)人員，可以從這幾個角度去考慮下，如哪些人或部門會受到項目結(jié)果的影響，哪些人可為項目提供資源（人、財、物）等。當(dāng)然，在互聯(lián)網(wǎng)公司，常見的相關(guān)人員也就是老板、產(chǎn)品經(jīng)理、項目經(jīng)理、項目團(tuán)隊（包含設(shè)計、開發(fā)、測試、運(yùn)維等）及用戶等。

找到了項目的相關(guān)人員后，現(xiàn)在你要做的就是把團(tuán)隊成員綁到自己的船上。你需要去了解團(tuán)隊里每個成員的核心KPI，也就是他們于這個項目的需求是什么，做這個項目可以給他們帶來什么。如果這個項目沒被囊括在這個成員的工作評價 list 里面，你需要去找他的老板溝通。根據(jù)我的經(jīng)驗，85%出工不出力的情況都是因為你的項目根本不會對這個成員的KPI有什么正向的幫助。當(dāng)然，如果找他的老板溝通無效，還有最后一招，感情投資，請那個成員擼串、吃飯，利用感情讓他幫你做好這個項目。

第四個問題，怎么立項？

通常來說，這個時候需要開一個項目啟動大會。這個啟動大會的目的是召集項目團(tuán)隊成員，成員之間初步認(rèn)識一下，產(chǎn)品經(jīng)理主持會議，然后清楚地傳達(dá)項目要做什么，目標(biāo)是什么，為什么要做，怎么做，誰來做等等。另外，跟所有的啟動大會一樣，項目的啟動大會，也需要給團(tuán)隊成員來點(diǎn)雞湯、打點(diǎn)雞血。產(chǎn)品經(jīng)理需要去統(tǒng)一團(tuán)隊的思想，明確團(tuán)隊的管理和運(yùn)作方式，以及團(tuán)隊的溝通機(jī)制等，產(chǎn)品經(jīng)理需要動員團(tuán)隊成員積極參與項目，并高質(zhì)量地完成項目。

這個時候，項目相關(guān)的文檔其實應(yīng)該已經(jīng)完成了，因為只有當(dāng)詳細(xì)的產(chǎn)品需求文檔有了之后，開發(fā)團(tuán)隊才能估算項目時間及里程碑等。也有另一種情況，那就是項目本身包括了需求分析階段，所以詳細(xì)的需求文檔是在立項之后才開始進(jìn)行調(diào)研和撰寫。不管怎么說，明確的產(chǎn)品需求和詳細(xì)的需求文檔，都是項目得以順利進(jìn)行的基本前提保障，所以，產(chǎn)品經(jīng)理的規(guī)劃能力、撰寫文檔的能力在這個時候就顯得尤為重要了。

項目計劃階段

完成了項目的啟動，接下來就要開始進(jìn)行項目計劃了，所謂的項目計劃，其主要工作就是工作任務(wù)分解，任務(wù)優(yōu)先級安排，資源、工期、成本估算，以及風(fēng)險計劃和溝通計劃等。

1、工作任務(wù)分解

工作任務(wù)分解，在項目管理中也有專門的術(shù)語叫做“工作分解結(jié)構(gòu)”（WBS），指的是以可交付成果為導(dǎo)向?qū)椖恳剡M(jìn)行的分組。它其實歸納和定義了項目的整個工作范圍，從項目目標(biāo)開始分解，逐層下降，每下降一層，代表對項目工作的更詳細(xì)的定義。

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

一般的工作任務(wù)分解方法有：按照產(chǎn)品的物理結(jié)構(gòu)分解、按照產(chǎn)品的功能模塊進(jìn)行分解、按照實施過程來進(jìn)行分解、或者是按照項目的地域分布等。比較常用的是按功能模塊來進(jìn)行分解，再結(jié)合產(chǎn)品的實施過程來進(jìn)行分解。

以微信公眾號的開發(fā)為例，微信公眾號的開發(fā)就涉及微信端開發(fā)和PC管理后臺的開發(fā)，這個時候如果進(jìn)行任務(wù)分解，最基本的方向就要分為微信端任務(wù)開發(fā)、PC管理端任務(wù)開發(fā)。而微信端任務(wù)開發(fā)，又可細(xì)分為需求梳理、產(chǎn)品設(shè)計、前端頁面實現(xiàn)、后臺接口支持、測試任務(wù)等；PC管理端的任務(wù)開發(fā)也是如此，也細(xì)分為需求梳理、產(chǎn)品設(shè)計、前端頁面實現(xiàn)、后臺接口支持、測試任務(wù)等，如果再細(xì)分功能模塊，則可分為“群發(fā)消息”、“自動回復(fù)”、“用戶管理”、“消息管理”等功能模塊的需求梳理、產(chǎn)品設(shè)計、前端頁面實現(xiàn)、后臺接口支持、測試任務(wù)等；

這里需要注意的是，分解任務(wù)的過程中，需要將任務(wù)給描述清楚，否則團(tuán)隊成員會不太明確自己究竟要做成什么樣子或達(dá)到什么樣的目標(biāo)才算任務(wù)完成。

項目的工作任務(wù)分解，其實也可以運(yùn)用我們之前提到過的MECE原則去進(jìn)行檢查，工作任務(wù)必須全面、清晰、細(xì)分，任務(wù)責(zé)任需要到人，每一個子任務(wù)都能夠估算工作量和工期。

2、任務(wù)優(yōu)先級安排

任務(wù)分配好了，但總有輕重緩急之分。項目里的優(yōu)先級排序，就是需要產(chǎn)品經(jīng)理去識別項目任務(wù)清單里的各種任務(wù)的相互關(guān)聯(lián)和依賴關(guān)系，并根據(jù)自己對需求優(yōu)先級的判斷，來對項目里各項任務(wù)的先后順序進(jìn)行安排和確定。

通俗地來說，產(chǎn)品經(jīng)理要定義的就是先做哪些任務(wù)，后做哪些任務(wù)。其實這個時候往往又會用到我們在需求管理中使用到的工具KANO模型，通過明確任務(wù)的重要度和緊急度來梳理任務(wù)的優(yōu)先級，優(yōu)先處理的是重要又緊急的任務(wù)。

在處理任務(wù)的優(yōu)先級安排時，有另一個非常重要的點(diǎn)需要明白，那就是有些任務(wù)與任務(wù)之間，存在著前置后置關(guān)系，只有在完成了一項任務(wù)的時候，我們才能開始下一個任務(wù)。所以在規(guī)劃優(yōu)先級的時候，需要把這種情況給考慮進(jìn)去。

3、計劃呈現(xiàn)——甘特圖或其它

很多項目管理的書籍都推薦使用甘特圖來進(jìn)行項目進(jìn)度計劃的制作和呈現(xiàn)，一般都是通過微軟的Project、OpenProj等專業(yè)軟件進(jìn)行繪制，還可以通過這些專業(yè)軟件直接查看項目的關(guān)鍵路徑。也有一些產(chǎn)品經(jīng)理或項目經(jīng)理直接使用Excel來制作項目進(jìn)度計劃表，畢竟他們對于表格的操作熟練程度已經(jīng)足夠駕馭一個項目的進(jìn)度計劃制作。

我是個比較注重用戶體驗的人，所以，上面兩種工具其實我都不怎么使用，一般來說，我更喜歡通過團(tuán)隊協(xié)作軟件中的項目管理功能，來實現(xiàn)項目計劃的呈現(xiàn)。

比如下面這樣的：

tower的項目管理界面

4、風(fēng)險控制

通俗地來說，風(fēng)險就是發(fā)生不幸事件的概率。任何一個項目都有風(fēng)險，這就好比任何一次手術(shù)都有風(fēng)險一樣，風(fēng)險其實是無處不在的，是一種不以人的意志為轉(zhuǎn)移，獨(dú)立于人的意識之外而存在的事物。

我們先來看看常見的一些風(fēng)險來源有哪些：

a、客戶沒有參與項目

如果你們公司的一個項目恰好是給客戶做的一個定制產(chǎn)品，但是在項目啟動、計劃和執(zhí)行的階段，都沒有客戶的參與，客戶只是在最開始的時候給了一份文檔，然后在項目收尾的時候來進(jìn)行驗收，中間沒有絲毫地參與到項目中來，那么客戶一旦發(fā)現(xiàn)最后的成果和自己當(dāng)初設(shè)想的需求相去甚遠(yuǎn)，結(jié)果就會變得非常糟糕。客戶有可能因此就不同意驗收項目，要求項目團(tuán)隊重新返工開發(fā)，這個時候造成的工作量及時間的損失、及對相關(guān)事件的影響則是不可估量的。

b、需求不明確或不完整

產(chǎn)品經(jīng)理的需求說明文檔出現(xiàn)不明確或不完整的情況，項目出現(xiàn)風(fēng)險的概率也會比較大，因為項目的開發(fā)成員都是圍繞著需求設(shè)計文檔來進(jìn)行開發(fā)、測試的，如果產(chǎn)品經(jīng)理能夠隨叫隨到，和開發(fā)及時討論清楚需求，則還能挽回一定的損失；而如果是異地開發(fā)，則整個項目便會比較悲催。

c、項目計劃的不合理

項目沒有如期完成，很有可能本身項目計劃就是有問題的。比如說，團(tuán)隊成員的分工不合理、工期安排的也不合理（一般3個月才能完成的任務(wù)，非得要求1個月之內(nèi)要上線）、資源沒有配置到位、工作任務(wù)的分解沒有細(xì)化沒有責(zé)任到人（這樣就會導(dǎo)致項目組的團(tuán)隊成員對自己的任務(wù)不太清晰，即使分解了，沒有指定到人，也會發(fā)現(xiàn)影響項目進(jìn)展）、還有一個就是任務(wù)的優(yōu)先級安排的不合理，導(dǎo)致后面任務(wù)的完成受到影響等。

d、團(tuán)隊成員的精神狀態(tài)

一個項目能不能如期按時按質(zhì)地完成，其中最主要因素還是人的因素，因此團(tuán)隊成員的精神狀態(tài)也是影響項目成敗的風(fēng)險之一。如果項目成員都如Scrum敏捷開發(fā)中提到的團(tuán)隊成員一樣，都是自發(fā)組織和管理，參與項目的積極性比較高，項目風(fēng)險就會大大降低。如果項目成員工作態(tài)度有問題，互相之間經(jīng)常推諉任務(wù)責(zé)任，經(jīng)常互相埋怨，那么項目的成果則很令人擔(dān)憂。

e、領(lǐng)導(dǎo)變更

這里的領(lǐng)導(dǎo)變更，主要是指項目開發(fā)到中途，領(lǐng)導(dǎo)突然說這個需求不對，應(yīng)該朝另一個需求方向開發(fā)，那么我們就稱之為領(lǐng)導(dǎo)變更。這里的變更，大致分為兩種情況，一種是不太傷筋動骨的，也就是只是小的需求修改，不涉及底層架構(gòu)的重建；另一種呢，則是產(chǎn)品的規(guī)劃和定位不夠清晰，導(dǎo)致修改起來比較傷筋動骨，一個需求方向的改變，就可能讓開發(fā)重新搭建后臺架構(gòu)，前端很多頁面也得跟著修改。當(dāng)然，有時候產(chǎn)品經(jīng)理也常常會犯這樣的錯誤，就是中途變更需求，這就要求產(chǎn)品經(jīng)理在項目策劃的時候就把需求都想清楚，盡量減少項目開發(fā)到一半需求突然變更的情況。

f、技術(shù)風(fēng)險

這里說到的技術(shù)風(fēng)險，指的是項目的開發(fā)組成員，他們在用代碼實施項目的過程中，會發(fā)生一系列意想不到的情況，比如開發(fā)去做一個從來沒有做過的功能，這個時候可能需要先進(jìn)行技術(shù)調(diào)研，可能最后的結(jié)果是光光是調(diào)研事件就話費(fèi)了一兩個禮拜，留著開發(fā)的時間幾乎僅剩無幾。比如說網(wǎng)站掛了，一處理就一天時間進(jìn)去了，原先手上的項目就只好拖延一天。

這里列舉了一些常見的技術(shù)風(fēng)險，產(chǎn)品經(jīng)理們在做項目管理的過程中，還是稍微了解下比較好：

那說了這么多的風(fēng)險來源，有沒有什么比較好的方法來規(guī)避這些風(fēng)險呢？

答案是有，但是依然比較難規(guī)避掉所有的風(fēng)險。

大家有沒有同感：出現(xiàn)項目偏離日程安排的情況，很少是因為工作耗費(fèi)了比預(yù)期更長的時間，更常見的原因是，根本不在計劃中的工作使項目泥足深陷？如果身兼項目經(jīng)理的你，深有同感，那么，我們就可以體會到，項目中的風(fēng)險是可以互通的。昨天的問題就是今天的風(fēng)險，你的問題很可能就是我的風(fēng)險。

因此，我們能做的比較好的一個方法就是，在項目初期，對上述風(fēng)險來源進(jìn)行逐一參考和排查，看看是否存在什么問題。當(dāng)然，更加隱秘的風(fēng)險，恐怕也不是靠這種逐一排查的方法來發(fā)現(xiàn)的，更關(guān)鍵的點(diǎn)還是在于對日常項目狀態(tài)的洞察，這樣才能把所有的核心風(fēng)險都呈現(xiàn)出來。

風(fēng)險管理是一件非常耗費(fèi)心力的事情，產(chǎn)品經(jīng)理如果兼職做了項目管理的工作，就必須要做好相關(guān)的心理準(zhǔn)備，畢竟內(nèi)心強(qiáng)大也是產(chǎn)品經(jīng)理必須具備的一個人格特質(zhì)啊。

ps：這個系列由于內(nèi)容較多，我分為三篇文章來逐步講解，對項目管理內(nèi)容有興趣的朋友可以通過留言與我進(jìn)行溝通交流。

#專欄作家#

壹百度，微信公眾號：倒退集，人人都是產(chǎn)品經(jīng)理專欄作家。在線教育企業(yè)服務(wù)領(lǐng)域產(chǎn)品經(jīng)理，創(chuàng)業(yè)公司Team Leader。曾主導(dǎo)多款重量級產(chǎn)品的產(chǎn)品策劃和設(shè)計工作。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。