如果問一個產(chǎn)品經(jīng)理，你最頭痛的事情是什么？估計十有八九會聽到產(chǎn)品/項目延期這個答案。項目延期，意味著產(chǎn)品沒有如期投入市場，意味著要開始加班加點趕進度，意味著可能加班加點趕出來的產(chǎn)品存在大大小小的BUG，你原先設(shè)想的XX功能，XX體驗沒辦法實現(xiàn)，你的KPI可能會有危險，你的年終獎可能泡湯。。。

為什么會延期呢？除掉人力資源和開發(fā)資源等一些我們無法改變的客觀原因之外，我覺得重點要關(guān)注以下幾個問題：

這其實是很要命的一點。只關(guān)注自己的任務(wù)，忽視了上下游相關(guān)業(yè)務(wù)模塊的聯(lián)系。吭哧吭哧開發(fā)完了，發(fā)現(xiàn)和XX模塊對接不上?。∵@個接口設(shè)計前端用起來很麻煩??！于是乎，我們又一起重新寫一遍。延期的紅色警報又要響起來了。

解決這個問題，我們可以試試：

閱讀需求文檔時，請不要只看自己負(fù)責(zé)的模塊，把所有需求都過一遍，理解需求的上下邏輯關(guān)系；提前和相應(yīng)的同事溝通技術(shù)方案。這一點全靠自覺，畢竟不這樣做最后返工的肯定有自己。

開發(fā)負(fù)責(zé)人可以在正式開發(fā)之前組織大家集中花一個時間段，把需求疑難點，需要彼此配合的拿出來討論。磨刀不誤砍柴工，這會讓大家后面工作的更有效率。

每天站立會議溝通開發(fā)進度，就說自己做到哪里了，有發(fā)現(xiàn)什么風(fēng)險，需要哪些同事或者模塊來配合？也不要發(fā)什么日報，就是每天面對面溝通一下，這個比什么效率都高。日報只是起一個總結(jié)和匯報的作用，冷冰冰的幾句文字比不上同事之間面對面的交流。這點對小團隊來說特別重要，就那么幾個人你還非要搞那么多流程，何必呢？