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

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

其實本篇章本不應該寫的，因為項目把控是PMO（項目經理）的事情，產品在輸出相關交付物后，本應該就是在開發過程中解答技術的需求疑問和驗收就行。

但是絕大部分中小型公司未設立項目經理崗位（估計覺得PM應該兼任），這個時候產品經理就需要充當PMO去把控項目的開發進度。

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

一、什么是項目管理？

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

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

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

二、核心工具

項目計劃表

合格且規范項目會擁有一張項目計劃表（如上圖），項目經理按照預期設定的時間推進項目成員完成每階段事宜。

本文這次介紹其中一個階段：如何在研發階段把控進度。

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

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

三、核心能力

1. 拆解項目節點

2. 把控核心：任務—人—時間

根據項目整體維度，拆分成更細的維度更好把控。

1. 任務：按模塊分類（一級、二級模塊），層及分類（前端、后臺）；
2. 人員：拆解任務具體誰負責完成，根據項目程度是否需要加上直屬領導；
3. 時間：計劃開發完成時間、實際開發完成時間、 聯調進度、 聯調完成時間、移交測試時間。

把上面這些節點字段組合在一起，就是完整開發進度管控表?？梢跃烷L這樣：

3. 系統拆分

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

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

4. 組織進度會議

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

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

5. 干系人進度同步

定期通過郵件同步項目進展，內容包括：

1. 當前項目進度；
2. 當前阻塞（如有）；
3. 待支持（如有）；
4. 待領導決策（如有）。

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

其他

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

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

• H5前端A：微笑，你這個地方設計的不合理啊，我覺得按照用戶操作行為應該這么設計。
• IOS前端B：微笑，你這邏輯是不是有問題，感覺怪怪的。
• JAVA后臺C：微笑，你這樣設計，我后臺又要增加臨時表，這表關聯的好亂，后期沒辦法維護。能不能調整一下方案。
• 設計師D：……
• 某干系領導：……
• 某干系運營：……

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

列了一些常見的點：

1. 需求調整：細節微調、方案微調
2. 需求變更：流程變更、功能變更
3. 其他：方案大調整、合作方跑路，急需備用方案

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

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

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

1. 分析問題的真偽性（假需求，該怎么辦你懂得）；
2. 及時提出解決方案；
3. 與干系人確定修改后方案的合理性與可行性；
4. 同步項目成員及干系人、領導方案結果。

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

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

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

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

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

在我修改完后怎么辦？直接發給技術？NO！NO！

記?。涸陧椖窟^程中，一定要保持信息同步，同步給項目成員及干系人。

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

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

{日期}需求變更：

1. 登錄機制由賬號密碼變更為手機號+驗證碼，同時支持第三方登錄（微信、QQ）……需求，文檔已更新，位置（4.3.2）
2. 效果圖已同步更新……

望各位熟知。

@具體負責開發的技術人員。

上面只是一個很簡單的例子，項目過程中，有很多比這個復雜、繁瑣、難以抉擇、突發是事情發生。我們需要抓住管理的本質（人-事-時）去進行靈活的變通，這樣才能更好的掌握項目管理的技巧而熟練運用。

最后祝各位PM正在負責的項目順利上線，沒有重大BUG，數據biu biu biu的撐爆服務器。

#相關閱讀#

實戰第一步：市場調研

實戰第二步：如何做一份有針對性的競品分析

實戰第三步：從需求池到確認需求的全過程

實戰第四步：新項目之十大輸出產物

本文由 @微丶笑 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議