前面幾篇文章講了從市場需求到功能的過程和如何把功能落地，本篇文章主要講項目管理中一些需要注意的細(xì)節(jié)，與大家分享。

實戰(zhàn)第五步：項目管理的白與黑（項目管理的三個核心步驟）

消失了1年，文章很有沒有更新，很多讀者和好友期待我的后續(xù)文章，說實話很感動，寫作的目的就是幫助產(chǎn)品新人，很多與我溝通的PM覺得文章很受用。所以我下定決心繼續(xù)寫下去。你們的熱愛是我寫作的動力。肉麻的話就說到這里，咋們繼續(xù)續(xù)寫前幾篇干貨文章后續(xù)。

其實本篇章本不應(yīng)該寫的，因為項目把控是PMO（項目經(jīng)理）的事情，產(chǎn)品在輸出相關(guān)交付物后，本應(yīng)該就是在開發(fā)過程中解答技術(shù)的需求疑問和驗收就行。

但是絕大部分中小型公司未設(shè)立項目經(jīng)理崗位（估計覺得PM應(yīng)該兼任），這個時候產(chǎn)品經(jīng)理就需要充當(dāng)PMO去把控項目的開發(fā)進(jìn)度。

本次文章內(nèi)容基本寫的大白話（主要是語文差），希望能幫到各位。

一、什么是項目管理？

項目管理：項目的管理者，在有限的資源約束下，運用系統(tǒng)的觀點、方法和理論，對項目涉及的全部工作進(jìn)行有效地管理。即從項目的投資決策開始到項目結(jié)束的全過程進(jìn)行計劃、組織、指揮、協(xié)調(diào)、控制和評價，以實現(xiàn)項目的目標(biāo)。（來源：百度百科）

讀起來頭頭是道，用詞專業(yè)、文字簡練。但是理解起來很有困難。

我覺得可以用大白話這么翻譯，各位看一下對不對：“和一群人在有限的時間和資源下，完成一件目標(biāo)明確的事情?！?/p>

二、核心工具

項目計劃表

實戰(zhàn)第五步：項目管理的白與黑（項目管理的三個核心步驟）

合格且規(guī)范項目會擁有一張項目計劃表（如上圖），項目經(jīng)理按照預(yù)期設(shè)定的時間推進(jìn)項目成員完成每階段事宜。

本文這次介紹其中一個階段：如何在研發(fā)階段把控進(jìn)度。

那如何做到項目進(jìn)度的清晰把控？知道項目在開發(fā)階段會不會存在延期風(fēng)險。有人會說，會不會延期開發(fā)不是很清楚嗎？

這個時候需要糾正一下，當(dāng)一個項目團隊幾十上百人的時候，每個人的分工和所負(fù)責(zé)的模塊不同。他們基本不清楚所負(fù)責(zé)的模塊對其他關(guān)聯(lián)模塊的影響有大多，所以這個時候如何管理就變得很重要。

三、核心能力

1. 拆解項目節(jié)點

實戰(zhàn)第五步：項目管理的白與黑（項目管理的三個核心步驟）

2. 把控核心：任務(wù)—人—時間

根據(jù)項目整體維度，拆分成更細(xì)的維度更好把控。

任務(wù)：按模塊分類（一級、二級模塊），層及分類（前端、后臺）；
人員：拆解任務(wù)具體誰負(fù)責(zé)完成，根據(jù)項目程度是否需要加上直屬領(lǐng)導(dǎo)；
時間：計劃開發(fā)完成時間、實際開發(fā)完成時間、聯(lián)調(diào)進(jìn)度、聯(lián)調(diào)完成時間、移交測試時間。

把上面這些節(jié)點字段組合在一起，就是完整開發(fā)進(jìn)度管控表?？梢跃烷L這樣：

3. 系統(tǒng)拆分

這個是什么意思，上面不是已經(jīng)說得按模塊分類了嗎？

此模塊更可以理解為系統(tǒng)。主要是用于一些大系統(tǒng)升級改造，拆分成多個子項目，這個時候就需要按照每個子系統(tǒng)去列。

4. 組織進(jìn)度會議

PM對這種會議都不陌生（誰還沒開過會啊，沒組織過，也參加過）。

這種會議的特點：又短又快：短（會議間用時短，5~20分鐘）、快（會議頻率快，部分項目/關(guān)鍵節(jié)點天天開）。

5. 干系人進(jìn)度同步

定期通過郵件同步項目進(jìn)展，內(nèi)容包括：

當(dāng)前項目進(jìn)度；
當(dāng)前阻塞（如有）；
待支持（如有）；
待領(lǐng)導(dǎo)決策（如有）。

說明：干系人指提需求人員或項目Leader

其他

讀到這里，是不是感覺好像本篇的內(nèi)容已經(jīng)講完了。是不是有一種錯覺項目管理其實挺簡單的，不好意思，項目管理真這么簡單的話，那不是人人都已做PMO了（畢竟這崗位薪酬還不低）

其實在我們正常的工作中，上面的那部分所占用的時間可能只有20%，我們更多的時間在與項目干系人、技術(shù)同事撕逼或被他們打臉。

H5前端A：微笑，你這個地方設(shè)計的不合理啊，我覺得按照用戶操作行為應(yīng)該這么設(shè)計。
IOS前端B：微笑，你這邏輯是不是有問題，感覺怪怪的。
JAVA后臺C：微笑，你這樣設(shè)計，我后臺又要增加臨時表，這表關(guān)聯(lián)的好亂，后期沒辦法維護(hù)。能不能調(diào)整一下方案。
設(shè)計師D：……
某干系領(lǐng)導(dǎo)：……
某干系運營：……

這才是實際項目管理的真實情況。而且項目過程中出的不確定性因素太多，所以很難去統(tǒng)一化、規(guī)范化。（核心點是不變：人-事-時）

列了一些常見的點：

需求調(diào)整：細(xì)節(jié)微調(diào)、方案微調(diào)
需求變更：流程變更、功能變更
其他：方案大調(diào)整、合作方跑路，急需備用方案

上面這些在項目管理過程中基本占據(jù)我們60%以上的時間，在處理這些問題的方式或者方法上可能大家的存在很大的差異，或者有部分初級PM在遇到棘手的問題，甚至不知如何處理。

問題的本質(zhì)最后也會回歸到人上面，出現(xiàn)問題就去解決它，解決不了問題，就解決提出問題的人（開玩笑啦）。

處理項目過程中遇到問題的方法步驟：

分析問題的真?zhèn)涡裕傩枨?，該怎么辦你懂得）；
及時提出解決方案；
與干系人確定修改后方案的合理性與可行性；
同步項目成員及干系人、領(lǐng)導(dǎo)方案結(jié)果。

可能讀完還是沒有太大感觸。舉個簡單的例子：

lowB微笑在設(shè)計登錄機制時采用賬號密碼登錄，開開心心碼完需求文檔：注冊包含大小寫字母-密碼不少于8位；

到需求評審的時候，前端/后臺技術(shù)就開始展示他們的專業(yè)性（批斗產(chǎn)品的機會來了）：

H5技術(shù)：微笑，你這注冊機制是不是太low了哦，現(xiàn)在都采用手機號驗證碼登錄，方便用戶登錄（順帶還會提一下用戶體驗）；
java后臺：你需要考慮一下用戶體系，如果一開始不考慮這個，后面再去搭建用戶體系，針對系統(tǒng)改造很大，你可以考慮一下使用手機號 UID，這樣……（os：大牛，講的真好）
ios前端：……

再經(jīng)過一番被教育后，覺得技術(shù)同事給的意見很在理，那么我就只能去修改，按照手機號驗證碼的機制去設(shè)計。

在我修改完后怎么辦？直接發(fā)給技術(shù)？NO！NO！

記住：在項目過程中，一定要保持信息同步，同步給項目成員及干系人。

同步信息時一定要想清楚，那些人是必須要知道的，那些人是需要知悉。同步方式根據(jù)自己公司的實際情況去同步：郵件、項目群或者二者同時使用。

例如我剛剛的那個例子，我會這么寫：