許多互聯網中小公司，團隊里不一定配備項目經理，產品經理往往身兼項目經理的角色，對項目進度進行全程把控，直至項目及時交付。

剛負責項目那會，由于非項目管理專業出身，當時那個忐忑不安啊！許多事情都是憑著固有的思維與認知去行事和判斷，加之缺乏經驗，有時會主次不清或管控流程上有所紕漏，項目經常瀕臨無法準時交付的風險。

可見，在行業內，大部分產品經理都必須去學習掌握項目管理的知識，畢竟市場千變萬化，一個好項目如果一而再，再而三的延期交付，那么多半產品出爐的質量不怎么樣，即便可以，也可能因慢競爭對手一步，市場表現大打折扣。

本次系列篇主要分享一些項目管理的一些方法與經驗，希望可以幫助小伙伴提前認識與避坑。

筆者是小菜鳥的時候（diss：如今也是個老點的菜鳥），聽聞要兼管項目管理的活兒，即忐忑又興奮，抱著“天降大任于斯人也，我必對得起老天”的心態匆匆忙忙地制定了詳細、標準、帥氣的甘特圖，畫完有種“老子真是天才，這計劃真TM完美”的感慨。

結果，顯而易見，那臉是啪啪作響。雖然敢做計劃和提前做計劃，但是忽視了做計劃的核心理念—— “漸進明細”與“反復修正”。俗話說，計劃永遠趕不上變化，毫無彈性的計劃一定會被現實擊打得七零八碎，除非你是這類項目的老手高手。

立項之前，我們需要的是表示大概進度的時間表即可，最大的作用就是讓團隊與領導知道幾個關鍵的時間點，如調研評估時間、項目啟動日、第一個里程碑。

立項之后，這時各類資源基本就位，與研發經理、領導等對團隊的生產力進行預估，進一步推導需求確認、設計確認、等中間的時間節點。

需求確認后，與負責設計、前端等各環節的成員共同討論，詳細估算具體的工作量，進一步明確設計確認、功能完成、測試完成、里程碑等時間點。

至于“反復修正”非頻繁調整，調整計劃應當有合理的數據和論據來支撐，時間寬松還好，時間緊張可能會讓團隊梁山起義。

我們要謹記，好的計劃表都是大家共同商榷出來的，因為功能實現方案是他們執行的，他們更為清楚，此外，計劃表代表著一種對項目的共識，有共識才好一起發力做事情。

在計劃制定后，要謹記交付物的標準是什么？比如設計稿完成到什么程度，研發就可以準備產品代碼；什么叫功能完成，可以允許多少需求比例沒有完成；怎樣算里程碑，產品質量達到什么水平，允許多少BUG什么類型BUG暫時存在等等。我們需定義好，避免后期有所爭執，這些也是大家對項目理解達成共識的細節體現。

做計劃的核心理念上便是“合理切割并分而治之”。在產品探索期，我們往往還在尋找合適產品方向，方向變動可能頻繁，迭代的長度應當更短，俗話說的話，船小好掉頭。

最后，計劃一定要趁早，不要擔心太早做計劃會有太多不確定因素，正因為有不確定因素，所以我們當我們披露初期計劃時，自然會有人跳腳指出不合理之處，這才是我們的目的，根據提供的信息進行合理調整，計劃便會變得越來越充實和準確。

下回我們分享項目溝通的那些事兒，也推薦下相關書籍。