起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識實戰第五步：項目管理的白與黑
前面幾篇文章講了從市場需求到功能的過程和如何把功能落地，本篇文章主要講項目管理中一些需要注意的細節，與大家分享。
消失了1年，文章很有沒有更新，很多讀者和好友期待我的后續文章，說實話很感動，寫作的目的就是幫助產品新人，很多與我溝通的PM覺得文章很受用。所以我下定決心繼續寫下去。你們的熱愛是我寫作的動力。肉麻的話就說到這里，咋們繼續續寫前幾篇干貨文章后續。
其實本篇章本不應該寫的，因為項目把控是PMO（項目經理）的事情，產品在輸出相關交付物后，本應該就是在開發過程中解答技術的需求疑問和驗收就行。
但是絕大部分中小型公司未設立項目經理崗位（估計覺得PM應該兼任），這個時候產品經理就需要充當PMO去把控項目的開發進度。
本次文章內容基本寫的大白話（主要是語文差），希望能幫到各位。
一、什么是項目管理？
項目管理：項目的管理者，在有限的資源約束下，運用系統的觀點、方法和理論，對項目涉及的全部工作進行有效地管理。即從項目的投資決策開始到項目結束的全過程進行計劃、組織、指揮、協調、控制和評價，以實現項目的目標。（來源：百度百科）
讀起來頭頭是道，用詞專業、文字簡練。但是理解起來很有困難。
我覺得可以用大白話這么翻譯，各位看一下對不對：“和一群人在有限的時間和資源下，完成一件目標明確的事情?！?/p>
二、核心工具
項目計劃表
合格且規范項目會擁有一張項目計劃表（如上圖），項目經理按照預期設定的時間推進項目成員完成每階段事宜。
本文這次介紹其中一個階段：如何在研發階段把控進度。
那如何做到項目進度的清晰把控？知道項目在開發階段會不會存在延期風險。有人會說，會不會延期 開發不是很清楚嗎？
這個時候需要糾正一下，當一個項目團隊幾十上百人的時候，每個人的分工和所負責的模塊不同。他們基本不清楚所負責的模塊對其他關聯模塊的影響有大多，所以這個時候如何管理就變得很重要。
三、核心能力
1. 拆解項目節點
2. 把控核心：任務—人—時間
根據項目整體維度，拆分成更細的維度更好把控。
- 任務：按模塊分類（一級、二級模塊），層及分類（前端、后臺）；
- 人員：拆解任務具體誰負責完成，根據項目程度是否需要加上直屬領導；
- 時間：計劃開發完成時間、實際開發完成時間、 聯調進度、 聯調完成時間、移交測試時間。
把上面這些節點字段組合在一起，就是完整開發進度管控表?？梢跃烷L這樣：
3. 系統拆分
這個是什么意思，上面不是已經說得按模塊分類了嗎？
此模塊更可以理解為系統。主要是用于一些大系統升級改造，拆分成多個子項目，這個時候就需要按照每個子系統去列。
4. 組織進度會議
PM對這種會議都不陌生（誰還沒開過會啊，沒組織過，也參加過）。
這種會議的特點：又短又快：短（會議間用時短，5~20分鐘）、快（會議頻率快，部分項目/關鍵節點天天開）。
5. 干系人進度同步
定期通過郵件同步項目進展，內容包括：
- 當前項目進度；
- 當前阻塞（如有）；
- 待支持（如有）；
- 待領導決策（如有）。
說明：干系人指提需求人員或項目Leader
其他
讀到這里，是不是感覺好像本篇的內容已經講完了。是不是有一種錯覺項目管理其實挺簡單的，不好意思，項目管理真這么簡單的話，那不是人人都已做PMO了（畢竟這崗位薪酬還不低）
其實在我們正常的工作中，上面的那部分所占用的時間可能只有20%，我們更多的時間在與項目干系人、技術同事撕逼或被他們打臉。
- H5前端A：微笑，你這個地方設計的不合理啊，我覺得按照用戶操作行為應該這么設計。
- IOS前端B：微笑，你這邏輯是不是有問題，感覺怪怪的。
- JAVA后臺C：微笑，你這樣設計，我后臺又要增加臨時表，這表關聯的好亂，后期沒辦法維護。能不能調整一下方案。
- 設計師D：……
- 某干系領導：……
- 某干系運營：……
這才是實際項目管理的真實情況。而且項目過程中出的不確定性因素太多，所以很難去統一化、規范化。（核心點是不變：人-事-時）
列了一些常見的點：
- 需求調整：細節微調、方案微調
- 需求變更：流程變更、功能變更
- 其他：方案大調整、合作方跑路，急需備用方案
上面這些在項目管理過程中基本占據我們60%以上的時間，在處理這些問題的方式或者方法上可能大家的存在很大的差異，或者有部分初級PM在遇到棘手的問題，甚至不知如何處理。
問題的本質最后也會回歸到人上面，出現問題就去解決它，解決不了問題，就解決提出問題的人（開玩笑啦）。
處理項目過程中遇到問題的方法步驟：
- 分析問題的真偽性（假需求，該怎么辦你懂得）；
- 及時提出解決方案；
- 與干系人確定修改后方案的合理性與可行性；
- 同步項目成員及干系人、領導方案結果。
可能讀完還是沒有太大感觸。舉個簡單的例子：
lowB微笑在設計登錄機制時采用賬號密碼登錄，開開心心碼完需求文檔：注冊包含大小寫字母-密碼不少于8位；
到需求評審的時候，前端/后臺技術就開始展示他們的專業性（批斗產品的機會來了）：
- H5技術：微笑，你這注冊機制是不是太low了哦，現在都采用手機號+驗證碼登錄，方便用戶登錄（順帶還會提一下用戶體驗）；
- java后臺：你需要考慮一下用戶體系，如果一開始不考慮這個，后面再去搭建用戶體系，針對系統改造很大，你可以考慮一下使用手機號+UID，這樣……（os：大牛，講的真好）
- ios前端：……
再經過一番被教育后，覺得技術同事給的意見很在理，那么我就只能去修改，按照手機號+驗證碼的機制去設計。
在我修改完后怎么辦？直接發給技術？NO！NO！
記?。涸陧椖窟^程中，一定要保持信息同步，同步給項目成員及干系人。
同步信息時一定要想清楚，那些人是必須要知道的，那些人是需要知悉。同步方式根據自己公司的實際情況去同步：郵件、項目群或者二者同時使用。
例如我剛剛的那個例子，我會這么寫：
{日期}需求變更：
- 登錄機制由賬號密碼變更為手機號+驗證碼，同時支持第三方登錄（微信、QQ）……需求，文檔已更新，位置（4.3.2）
- 效果圖已同步更新……
望各位熟知。
@具體負責開發的技術人員。
上面只是一個很簡單的例子，項目過程中，有很多比這個復雜、繁瑣、難以抉擇、突發是事情發生。我們需要抓住管理的本質（人-事-時）去進行靈活的變通，這樣才能更好的掌握項目管理的技巧而熟練運用。
最后祝各位PM正在負責的項目順利上線，沒有重大BUG，數據biu biu biu的撐爆服務器。
#相關閱讀#
本文由 @微丶笑 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
私人微信： weixin-lianggao1993