在很多互聯(lián)網(wǎng)公司內(nèi)部，并沒有專門項目經(jīng)理這個崗位，通常是由產(chǎn)品經(jīng)理兼任，在這種情況下，產(chǎn)品經(jīng)理懂得一部分項目管理技能就顯得非常重要。
項目管理現(xiàn)如今也是一個熱門的學科，因為無論公司大小，或多或少都需要做項目，所以優(yōu)秀的項目經(jīng)理也就顯得炙手可熱。那么作為互聯(lián)網(wǎng)公司的產(chǎn)品經(jīng)理，如何才能做好項目管理呢？筆者不才，有幸拜讀過項目管理的專業(yè)指南 PMBOK， 并通過PMP認證，因為本身也是產(chǎn)品汪，所以力圖將互聯(lián)網(wǎng)產(chǎn)品經(jīng)理和項目經(jīng)理這兩個崗位結(jié)合并闡述工作流程與方法，不足之處、歡迎斧正。
需要說明的是，產(chǎn)品經(jīng)理和項目經(jīng)理的英文簡稱雖然都是PM，但是這兩者有著本質(zhì)的區(qū)別，說嚴重點，如果不是因為沒有常設(shè)項目經(jīng)理崗的原因，這兩個職位其實是互相對立的。我所理解的產(chǎn)品經(jīng)理與項目經(jīng)理，他們有如下區(qū)別：
1. 說高大上一點：產(chǎn)品經(jīng)理關(guān)注的是市場、用戶和需求，他是一款產(chǎn)品升級迭代的驅(qū)動者；是憑借敏銳的市場嗅覺、高效的用戶需求洞察能力帶領(lǐng)團隊始終向前的指引者...等等。 說通俗一點產(chǎn)品經(jīng)理就是會上吹牛逼，私底下求爹告奶說要改需求的產(chǎn)品汪 :(...
2. 項目經(jīng)理：項目經(jīng)理的核心工作或者說最高目標是確保項目在預(yù)定的項目預(yù)算范圍內(nèi)，準時、保質(zhì)、保量地完成項目并交付。項目經(jīng)理是最痛恨需求變更的，因為一旦需求變更將造成項目范圍、成本、進度的變化，也就會導(dǎo)致項目無法在預(yù)定的時間內(nèi)完成。
所以說，產(chǎn)品經(jīng)理和項目經(jīng)理是一對與生俱來的冤家對頭，但是互聯(lián)網(wǎng)的產(chǎn)品經(jīng)理卻需要很好的將這兩個水火不容的的角色融會貫通，拿捏有度。所以，不得不佩服當下的產(chǎn)品汪們，真的得多喂點口糧，衷心道一句："趕緊吃吧，吃完這頓指不定有沒有下一頓呢，殺紅眼的程序猿們正拿刀等著你呢..."
言歸正傳，筆者就試圖將這兩者結(jié)合起來，并闡述互聯(lián)網(wǎng)產(chǎn)品經(jīng)理在實際項目管理中可以遵循的工作流程。
項目管理的5大過程組：啟動、規(guī)劃、執(zhí)行、監(jiān)控和收尾，下面將以一個App開發(fā)項目為例：
一、啟動階段
按照PMBOK的描述，啟動階段要做的的事情是：制定項目章程、確立項目經(jīng)理、識別干系人；在互聯(lián)網(wǎng)項目管理實踐中，最顯著的標志就是項目立項，項目立項意味著項目組的正式成立并在公司層面承認項目的合理、合法性，同時也為項目經(jīng)理（產(chǎn)品經(jīng)理）有效推動項目進程提供保障。
在這個階段，產(chǎn)品經(jīng)理對需要做的產(chǎn)品得有一個大概的輪廓，并做到如下：
1. 面對老板：能講故事，縱向?qū)Ρ龋嬖V老板前面有多大一塊蛋糕，及這塊蛋糕可以花很少的錢就能吃到，并且你有信心比競爭對手出手更快。
2. 面對上級：能吹牛逼，橫向?qū)Ρ?，告訴上級，這個產(chǎn)品如果做成了，它將在公司如何在眾多產(chǎn)品線中脫穎而出，以后升職加薪都是so easy的了！
3. 面對團隊：能畫餅，你要想做出一款優(yōu)秀產(chǎn)品，激發(fā)團隊的激情是最少不了的，所以如何畫好一張餅，就顯得非常重要。這不是整天吹牛逼能夠做到的，要的是以身作則，用數(shù)據(jù)說話，要求別人的同時，更要嚴格要求自己，這體現(xiàn)在輸出高質(zhì)量的原型和需求文檔，關(guān)于原型和需求文檔，本節(jié)不做詳述。請參考產(chǎn)品經(jīng)理能力模型的需求收集文章。
說服上面三個角色的人物才能保證項目的順利立項，從而開始實現(xiàn)自己用產(chǎn)品改（ji）變（xu）世（ban）界（zhuan）的夢想。
二、規(guī)劃階段
PMBOK指南中，對于規(guī)劃階段的主要內(nèi)容定義很復(fù)雜，需要制定項目管理、范圍、進度、成本、風險、溝通、干系人等13個管理計劃，在互聯(lián)網(wǎng)項目管理實踐中，可能并不需要涉及如此廣泛的內(nèi)容，所以筆者取其中重要的進行闡述。
按照重要緊急程度進行排序：
2.1. 項目范圍管理計劃
項目范圍管理計劃，就是輸出高質(zhì)量的產(chǎn)品需求文檔和原型，這點請參考：需求收集方法
2.2. 項目進度管理計劃
項目進度管理計劃的核心是創(chuàng)建WBS(工作分解結(jié)構(gòu))和WBS詞典（工作分解結(jié)構(gòu)說明書）
在這個階段，產(chǎn)品經(jīng)理需要召開項目需求分解會議，在這期間項目組核心成員（產(chǎn)品經(jīng)理、UI/UE/UX，iOS、安卓、后臺）必須將理解產(chǎn)品需求列為最高等級（重要且緊急）的工作，由產(chǎn)品經(jīng)理將產(chǎn)品原型（最好是已經(jīng)完成UI設(shè)計的原型）展示給所有項目組成員，并詳細講述產(chǎn)品的核心流程、功能架構(gòu)、信息架構(gòu)，最好的需求分解會議，應(yīng)該是產(chǎn)品經(jīng)理結(jié)合用戶使用場景進行闡述，務(wù)求讓UI/UE/UX 理解用戶使用場景從而設(shè)計出符合用戶習慣的界面和交互風格；讓前端（iOS、安卓、web）開發(fā)出用戶符合要求的交互和產(chǎn)品界面；讓后端主動思考相應(yīng)場景下應(yīng)該如何更好處理數(shù)據(jù)，例如：何時采用文字呈現(xiàn)合適采用圖文呈現(xiàn)；為減輕手機電池壓力，何時向app發(fā)送網(wǎng)絡(luò)請求才能既不浪費手機電量又保證服務(wù)器正常運轉(zhuǎn)等等。
2.2.1 創(chuàng)建WBS(工作分解結(jié)構(gòu))
保證需求被充分理解之后，需要將需求分解成單個的工作包，工作包的要求是盡可能細，最好能夠做到每個工作包的完成時間都不得超過一個工作日，超過的必須再次分解，直到分解成能夠在一個工作日內(nèi)完成工作包，撰寫格式如下：
2.2.2 繪制項目進度網(wǎng)絡(luò)圖
在所有核心成員根據(jù)PRD和產(chǎn)品原型，提交各自的工作分解結(jié)構(gòu)之后，產(chǎn)品經(jīng)理需要將其匯總，并繪制項目進度網(wǎng)絡(luò)圖，樣例如下：
繪制項目進度網(wǎng)絡(luò)圖的意義：讓項目經(jīng)理從整體上把控項目進度
如何繪制這張圖？它就是根據(jù)團隊成員提交的WBS工作包的前置任務(wù)和工期得出的。例如這張圖的工作包B，它的前置任務(wù)是A，也就是說，任務(wù)B開始必須依賴于A才能啟動否則無法進行。根據(jù)這些工作包的依賴關(guān)系，我們可以就可以繪制這張項目進度網(wǎng)絡(luò)圖。我們再根據(jù)每個工作包的工期，可以計算出整個項目的關(guān)鍵路徑。比如這張圖，假如每個工作包的工期都是 1 個工作日，那么這個項目的關(guān)鍵路徑就是：“開始->H->C->D->E->結(jié)束”。關(guān)鍵路徑是什么鬼？它是項目從開始到結(jié)束的耗時最長的一條工作流程，它決定了項目的工期。所以說繪制項目進度網(wǎng)絡(luò)圖的意義在于：
1. 他可以讓產(chǎn)品經(jīng)理清楚的知道項目將在何時完工，這時你可以拍著胸脯跟老板說我保證能完成任務(wù)或者拿出數(shù)據(jù)告訴老板，你說半個月就要完成，你怎么不去屎呢。
2. 產(chǎn)品經(jīng)理應(yīng)該重點關(guān)注關(guān)鍵路徑上的工作包完成和反饋情況，因為它們中的任何一個工作延期都將導(dǎo)致項目延期
3. 項目如果需要提前完成，那也必須是對關(guān)鍵路徑的工作進行趕工才能達成效果
2.2.3 繪制項目進度計劃表（甘特圖）
項目進度網(wǎng)絡(luò)圖它能告訴你項目將在什么時候完工，但是卻不能有效的管理項目進度。因為我無法從項目網(wǎng)絡(luò)圖中獲悉現(xiàn)在項目進展到何種程度，哪些工作完成哪些還沒有開始。這時，我們就需要用到項目進度計劃表（甘特圖）來呈現(xiàn)了。
項目進度計劃表詳細記錄了每項工作的任務(wù)順序和完成情況。通過它，產(chǎn)品經(jīng)理可以實時了解項目的進展情況。
三、執(zhí)行階段
項目執(zhí)行階段就意味著項目正式進入開發(fā)實施工作。這個階段，產(chǎn)品經(jīng)理的主要工作將圍繞把控項目進度，確保產(chǎn)品按時交付上了。對于執(zhí)行階段的工作，建議給項目組成員每人分發(fā)一張項目進度計劃，時刻提醒自己什么時間將要完成什么事情。
這里解釋一下之前為什么說要讓每位核心成員將工作包分解到1個工作日以內(nèi)，因為項目組正常每天早晨都會召開晨會，那么這就意味著每位成員在每天都有工作被完成，這對于激勵/監(jiān)督項目組成員來說是非常有利的。對于項目組成員來說：他們每天看到有工作被完成，會自然而然的產(chǎn)生滿足感并且激勵他們保持高度緊張感。如果一個工作任務(wù)安排時間過長，那么工作被延誤將是必然的事情。對于產(chǎn)品經(jīng)理來說：高度細分的工作任務(wù)，將極大的提高項目進度估算的準確性，同時督促未完成的工作及時完成。因為對比每天應(yīng)該完成的事情和每周應(yīng)該完成的事情，前者的緊迫感無疑更強烈。
3.1 項目晨會
對于項目組晨會，建議緊緊圍繞以下議題展開：
1. 每位成員更新昨天完成什么任務(wù)？用了多少時間？未完成的話，估計還要多久？
2. 每位成員更新今天將做哪些工作？
3. 有哪些工作需要其他同事配合？
注：晨會必須避免討論問題，只用來更新狀態(tài)，保證在15分鐘內(nèi)結(jié)束。即使必須討論也應(yīng)該是晨會結(jié)束后單獨溝通，防止浪費團隊其他成員時間。
產(chǎn)品經(jīng)理需將上述信息記錄并更新到項目進度計劃表內(nèi)，實時把控項目進度進展。預(yù)測項目是否延期并采取相應(yīng)措施（增加資源或趕工）。
3.2 開發(fā)/測試階段
通常一個項目組就是iOS、android、后臺、UI、測試和產(chǎn)品經(jīng)理（項目經(jīng)理）。針對app產(chǎn)品，后臺和app的交互都是通過api來完成，所以應(yīng)該先讓后臺寫好相應(yīng)的api并編寫假數(shù)據(jù)，這樣可以方便app端順利開展工作。
測試的工作應(yīng)該深入到開發(fā)的整個過程，必須要求開發(fā)設(shè)定好里程碑，而且里程碑設(shè)定的原則最好不能超過一周，每發(fā)布一個里程碑，測試必須開始介入并完成測試用例，同時反饋給相應(yīng)開發(fā)人員，避免因為開發(fā)周期過長導(dǎo)致對代碼的熟悉程度降低，修改bug的效率下降。
3.3 需求變更
一旦涉及需求變更，這時候PM的角色應(yīng)轉(zhuǎn)變?yōu)楫a(chǎn)品經(jīng)理，需求的變更應(yīng)按照嚴格的需求變更流程來管理，由產(chǎn)品經(jīng)理提出并提交正式的變更申請，項目組評審，評審?fù)ㄟ^后修改產(chǎn)品需求文檔和產(chǎn)品原型，進入開發(fā)執(zhí)行階段。
3.4 評審會議
在項目執(zhí)行階段，需要召開眾多會議，除了每天晨會和周會，每完成一個項目里程碑時，需要由產(chǎn)品經(jīng)理召開里程碑會議。由負責完成里程碑主要工作內(nèi)容的負責人展示交付物，并由團隊成員評審是否達到里程碑規(guī)定的要求。未完成的則計入下一階段工作內(nèi)容。demo的展示方法有多種，iOS端可以使用Airplay完成投影，方便團隊成員觀看。
在每個里程碑評審會議上，每個團隊成員都應(yīng)發(fā)言并闡述本階段的做的好與不足的地方，只對事不對人，目的在于時刻提醒團隊分析總結(jié)經(jīng)驗教訓，這樣才能更快、更好的成長。
四、項目收尾
項目收尾階段意味著項目結(jié)束，但并不意味著這部分工作不需要做。相反，項目收尾的工作的重要性不亞于項目的規(guī)劃階段。在整個項目階段過程中，不可避免會遇到眾多的問題，如：風險、變更、失誤、溝通不暢、合作不順等等問題，這就需要項目組在項目收尾時做項目總結(jié)，總結(jié)整個項目過程中的經(jīng)驗、教訓、不足和值得學習的地方。
項目總結(jié)如果僅停留在形式上和流程上，那真的是非?？上У模驗檫@其中的成長和經(jīng)歷是一筆不可多得的財富，如果不記錄下來并在今后的工作中加以改正，就將永遠的失去。同時，總結(jié)也是整個團隊成員系統(tǒng)性整理思路的過程，可以在更高的層面上看待這個項目。而不是僅限于自己的工作內(nèi)容。這樣也有利于項目團隊成員成長和提高。
同時，項目的總結(jié)也不應(yīng)該局限于項目收尾階段，筆者的建議是把項目分為若干個階段（可以使用里程碑），在階段結(jié)束時就應(yīng)該做一次階段性的總結(jié)，以免在項目收尾時發(fā)生遺忘。
