前言：一個需求下來,，產(chǎn)品、設計,、開發(fā),、測試都評估了時間,。但實際開發(fā)的需求可能會有變動，老板今天要改這個，明天要改那個,；不少東西要多方確認，最后到項目時間節(jié)點,，老板問你怎么樣了？你無言以對... 很多產(chǎn)品的開發(fā)中產(chǎn)品經(jīng)理又兼了項目經(jīng)理的職責,，所有在項目進度管理這塊也是重中之重,。

一、產(chǎn)品經(jīng)理為什么要管理項目進度大公司可能會有專門的項目經(jīng)理去進行項目進度的把控,，初創(chuàng)型的小公司可能是CTO兼任,，但是CTO可能在開發(fā)的過程中為了盡快上線砍需求，最后做出來的東西質量堪憂,。一個項目,，有明確的開始和結束時間，有明確的質量監(jiān)控和要求,，有明確的投入和產(chǎn)出預算,，這些是項目管理的核心。但也應該是產(chǎn)品經(jīng)理的責任——如果產(chǎn)品經(jīng)理不考慮時間,，怎么能夠按時上線產(chǎn)品?如果他不關注質量,，怎么能夠推出受用戶歡迎的產(chǎn)品?如果他不考慮投入產(chǎn)出比(這個恰恰是很多技術出身的產(chǎn)品經(jīng)理最不以為然的——好東西要舍得投入)，就有可能浪費公司大量的人力,、物力和時間,。二、產(chǎn)品經(jīng)理如何管理項目進度1,、拒絕業(yè)務頻繁的更改和插入需求市場部門今天提出一個需求,，過兩天感覺成本可能會有點高，需要改一下規(guī)則,；老板今天冒出一個想法覺得這個不錯,，需要做一下，明天又有一個新的idea要加上,。這個時候你作為產(chǎn)品經(jīng)理就需要動之以情,，曉之以理的說服業(yè)務部門。你可以說：“1,、你的一個小小的規(guī)則變動可能導致技術之前做的功夫全部白費,，打擊士氣，喪失技術對你的信任,，說不好還需要買個人身保險,。2、如果這樣變化的話,，可能會導致整個項目延期,，無法及時上線,，你看你是否能夠接受“。對于老板插入的需求你可以說：“您提出的這個需求很好,，很符合我們的實際,，為了不拖延項目進度，可以在下一版本進行規(guī)劃“,；你還可以用數(shù)據(jù)來說服老板,，暗示他提的這個需求和我們現(xiàn)在的實際情況不符?？傊粋€原則就是產(chǎn)品項目進入開發(fā)階段以后就不要再頻繁變更和插入需求,。2、可以提前規(guī)劃一兩個版本產(chǎn)品的迭代是有一條循環(huán)的流水線的：需求發(fā)掘-版本規(guī)劃-原型策劃-原型評審-UI 設計-開發(fā)-測試-發(fā)布,。一般而言,，為了效率最大化，我們都會爭取做到相鄰的兩次迭代之間能夠無縫對接,。也就是流水線上每一個環(huán)節(jié)的人在完成了當前版本的工作后,，就能立即執(zhí)行下一個版本的需求。產(chǎn)品提前規(guī)劃有個好處就是當你覺得技術在當前版本開發(fā)有余量的情況下,，可以將之后版本的需求拿到當前版本進行開發(fā),。為什么不提前規(guī)劃5-6個版本。一般來說一個月迭代兩個版本已經(jīng)算快的了,，提前規(guī)劃5-6個版本,，就提前把3個月以后的事情規(guī)劃了，互聯(lián)網(wǎng)瞬息萬變,，這樣規(guī)劃顯然是跟不上市場變化的,。3、明確每個版本迭代的目標每個版本迭代都是有目標的,，例如互聯(lián)網(wǎng)電商產(chǎn)品的目標可以分為：拉新,、留存、轉化,、銷售,。所以你規(guī)劃的時候就要考慮你這個版本的主要目標是這四個當中的哪一個。這樣做的好處就是在你項目時間不夠,，需要做出取舍的時候,，能夠輕易的做出取舍。例如：資本寒冬的時候,，推廣成本居高不下,，這個時候你下個版本的主要目標是留存，那么當你項目實現(xiàn)不了，需要砍需求的時候,，你就可以把不相關的需求砍掉,，確保你的項目順利上線。4,、MVP原則最小化產(chǎn)品原則需要你在規(guī)劃版本的時候考慮產(chǎn)品功能的延展性,，需不需要在一個版本里面把所有的功能都做完，可不可以分幾個版本迭代來實現(xiàn),。例如你規(guī)劃一個金融社區(qū),，前期是不是可以只做用戶單點評論功能，在以后的版本再做用戶和用戶之間的互動,。最小化產(chǎn)品原則不僅可以快速驗證市場，同時也能更好的控制項目的開發(fā)周期,。5,、產(chǎn)品經(jīng)理不要頻繁變更需求很多時候產(chǎn)品經(jīng)理在規(guī)劃產(chǎn)品的時候異常情況沒有考慮清楚，很多情況沒有沒有考慮到,，導致在技術人員在開發(fā)的時候需要不斷的找產(chǎn)品經(jīng)理確認,，無形中增加了溝通成本，延長了開發(fā)周期,，尤其在溝通不順暢的情況下,。這就要求產(chǎn)品經(jīng)理不要急著出文檔去開發(fā)，一定要深思熟慮,，考慮周全,。這樣做有兩個好處：1、增加在開發(fā)人員心目中的威信,，更利于在工作當中的溝通2,、開發(fā)過程中你會很輕松，不會有開發(fā)人員不斷地找您確認需求,，有利于項目的快速進行,。6、制定明確的項目管理計劃制定明確的項目開發(fā)管理計劃,。第一,、需要明確目標。項目什么時間封包,、什么時間上線要有一個一致的目標,。第二：制定詳細計劃。有了明確的目標以后就需要制定開發(fā)計劃,。產(chǎn)品出需求需要多久,、設計需要多久、開發(fā)需要多久,、測試需要多久,，出一個時間節(jié)點,。這樣做有三個好處：1、這樣會給各個部門一個壓力,。2,、同時當你老板問你項目進度的時候你也有地方可查詢。3,、你自己對項目進度也有一個大概的了解,。甘特圖進度計劃7、對開發(fā)成本有所了解上面提到產(chǎn)品經(jīng)理要制定項目管理計劃,。如果產(chǎn)品經(jīng)理對開發(fā)成本不了解的話很容易被開發(fā)忽悠,，導致開發(fā)的周期過長。同時對技術的了解,，有利于和程序員進行溝通,，減少開發(fā)過程中的溝通成本。同時對技術的了解,，有利于在產(chǎn)品規(guī)劃的時候了解技術的實現(xiàn)成本,，做到規(guī)劃的時候有的放矢。對開發(fā)技術的了解當然越精細越好,，如果達不到專家程度,，至少也要達到半骨灰級的程度。8,、項目進度的Review項目進度計劃做好以后,，把項目分配給每個人，但是你不能保證每個人都能在時間點之前完成任務,。產(chǎn)品經(jīng)理可以每天舉行幾分鐘的站立會議,，了解一下項目的進度，是否會有延期,。如果延期,，原因是什么？如果是不可抗因素,，則重新評估開發(fā)的進度計劃,；如果是可抗的因素，則要求在后續(xù)想辦法趕上原計劃的進度,。團隊協(xié)作視圖如果不實行每天的站立會議,，可以分為兩次review。第一次review主要看進度是否跟的上,，如果跟不上是及時調整還是需要加把勁追趕,。第二次review主要是是評估那些問題可以暫時擱淺，那些問題必須解決。在和他們溝通進度,，尤其在他們沒有完成的時候不要訓斥他們?yōu)槭裁礇]有按進度完成,，要幫助他們解決問題，給他們梳理一個愿景,，描繪一個美好的目標,。別人尊重你，你就是PM,。別人不搭理你,，你就只是一個P。9,、敏捷開發(fā)的PRD文檔我這里所說的敏捷開發(fā)的PRD文檔是指原型+標注形式的文檔,。說實話，你寫的冗長的word文檔不僅耽誤你自己的時間,，開發(fā)也不一定會看,，即使看了，也不方便,。開發(fā)一般直接照著產(chǎn)品原型來開發(fā),，這個時候就需要你有一個敏捷開發(fā)的PRD文檔,。敏捷開發(fā)的PRD文檔包含版本迭代歷史,、功能list、異常情況的說明,、全局結構圖和重要的流程圖,、第一次出現(xiàn)的名詞解釋，這些不能少,，否則你的PRD不是一個完整的文檔,。10、良好的溝通項目成員包含設計,、開發(fā),、測試人員。你需要和這些人良好的溝通,，和設計人員溝通你要有感性思維,，有審美能力。和開發(fā)人員溝通,，你需要有技術的邏輯思維,、測試人員一般比較嚴禁，和測試人員溝通你需要有嚴禁縝密的思維,。和他們溝通項目進度的時候,，如果你讓成員不必為他所說的話負責任，你就能得到負責任的回答。選自.投標書代寫網(wǎng) yipai178.com 如果把自己和工程師當成上下游的關系,，把工程師對工期的估計當作對自己的承諾,。“30天才能給你。”“不行,，我15天就要,。”這不是溝通，這是對立面的談判,。道已錯,，追求術有什么用？真正有效的辦法,，是讓彼此間的溝通,，永遠不會成為日后扯皮時的證據(jù)。這樣才有利于拿到最真實的信息,，方便作為正確的判斷,。11、使用團隊協(xié)作工具工欲善其事,，必先利其器,。良好的團隊協(xié)作工具能夠減少團隊成員之間的溝通成本。比如說通過統(tǒng)一溝通渠道從而節(jié)省時間,、避免重復溝通,，自動同步信息等等。市場上的團隊協(xié)作工具不少,，找一個適合自己團隊目前狀況的,，團隊成員大多數(shù)都用過的。因為項目協(xié)作工具大同小異,，基本上可以滿足你的團隊協(xié)作需求,比如國內比較好的工具 Teambition,、進度貓。12,、有變化及時溝通項目在做的過程中難免會出現(xiàn)變化的地方,，變化不可怕，可怕的是變化之后其他成員不知道,。你試想你更改一個需求,，技術不知道，技術還是按照之前的需求進行開發(fā),，等快開發(fā)完成以后,，技術知道需求變了，會不會有殺人的沖動,？其次能當面溝通就別打電話,，當打電話就別發(fā)郵件,，一切以溝通高效為主。人少的時候,，同步變化其實不是什么困難的事情,，但人多的時候就有難度了。雖然很多協(xié)作工具都有文檔更新通知,，或者文檔本身就有修改記錄,。但即便如此，也會有很多人忽略這些變動,。在同步變化上,，除了確保文檔及時修改、告知相關設計師,、工程師和測試人員以外,，我還會單獨召集各平臺的 leader 進行簡單的站立會議，提醒其確認變更是否已安排執(zhí)行,，同時也相當于交接了監(jiān)管的責任,。總結：上面就是個人在實踐中管理項目進度的一些感悟,，管理項目進度不是一朝一夕的事情,，需要在項目中反復的實踐。

>產(chǎn)品經(jīng)理如何管理項目進度