簡單說來就是，把控項目現在的進度，預計之后的進度，并且在進度控制中合理的分配項目組中每個人的個人進度。
說起來很簡單，但如果想要做到，最少需要幾點要求：
以上這些都是我在第一個項目整個過程中所欠缺的。
項目管理的前提就是做到“心中有數”，在心中有數的基礎上，比如本公司是有Web端產品并迭代過若干次，正在開發移動端產品。項目管理應該關注那么一些點。
本次項目從根本上其實是用Web端產品對移動端進行適配，但移動端有些東西領先Web端小半個版本。因為是共用一個后臺系統，因此會出現Web端和移動端相互干擾的情況。這時候就需要重點關于與之前版本不同的模塊與內容，因為他們是最有可能出錯的部分。這時候就需要和技術人員較多的溝通，反復確認是否得到的是產品經理所提出的需求。
排期包含了兩個方面，一是每個子模塊需要的時間，二是規劃模塊的之間順序，優先級。其實還有每個部門介入的順序，但這個順序基本是固定的，基本都是，產品--設計--開發（前后端）--聯調--測試，所以不計入。
如何估計每個子模塊需要的時間，對PM來說就是經驗問題了，因為影響時間的因素包括了現有的技術，之前的預研，技術人員的水平等方方面面。當然也可以讓技術人員自己估計時間，但技術人員估計的這個時間準確與否還是很難保證。
對時間及進度的控制考的是一個PM項目管理里的大局觀和對公司現狀的綜合判斷能力。
規劃模塊的設計、開發順序。影響排序的因素主要有兩個，一是優先級，優先級高的肯定會排的靠前一點。二是自底向上，可以采用自底向上法排序，因為底部的功能與其他功能之間交叉較少。如果自頂向下，很多功能只有完成了前序功能才能開發。
Deadline從來都是一把雙刃劍，用的好了，能在一定時間大幅度提升工作效率，提升團隊凝聚力，攻克項目難題。但如果用不好，整個項目組團隊怨聲載道，連續的加班，熬夜。作為產品狗的我選擇購買一份人生保險。
對于互聯網項目來說，大多都是延期，能準時完成就算是提前，Deadline真的要慎之又慎，否則只有Dead沒有Line。
市面上關于產品經理的課程、書籍都集中到了第一個箭頭，即怎么把idea通過分析、處理、構思成為一個可以用文檔提出來給研發人員的需求。忽視了第二個箭頭，對一個PM來說，不是把文檔給出去就是結束，如何把一個需求做成一個項目，從而最后凝結成為一個產品，也是衡量一個PM能力的重要方面。
作者：陌紫豐田
來源：簡書
文章轉載請保留網址：http://waterplane.cn/news/industry/1703.html
