產品經理如何管理項目進度

一個需求下來，產品、設計、開發、測試都評估了時間。下面是yjbys小編為大家帶來的關於產品經理如何管理項目進度的知識，歡迎閲讀。

　　產品經理為什麼要管理項目進度

大公司可能會有專門的項目經理去進行項目進度的把控，初創型的小公司可能是CTO兼任，但是CTO可能在開發的過程中為了儘快上線而砍需求，導致最後做出來的東西與設想不一致。一個項目，有明確的開始和結束時間，有明確的質量監控和要求，有明確的投入和產出預算，這些是項目管理的核心。但也應該是產品經理的責任——如果產品經理不考慮時間，怎麼能夠按時上線產品?如果他不關注質量，怎麼能夠推出受用户歡迎的產品?如果他不考慮投入產出比(這個恰恰是很多技術出身的產品經理最不以為然的)，就有可能浪費公司大量的人力、物力和時間。

　　1拒絕業務頻繁的更改和插入需求

市場部門今天提出一個需求，過兩天感覺成本可能會有點高，需要改一下規則;老闆今天冒出一個想法覺得這個不錯，需要做一下，明天又有一個新的idea要加上。這個時候你作為產品經理就需要動之以情，曉之以理的説服業務部門。你可以説：“1、你的一個小小的規則變動可能導致技術之前做的功夫全部白費，打擊士氣，喪失技術對你的信任，説不好還需要買個人身保險。2、如果這樣變化的話，可能會導致整個項目延期，無法及時上線，你看你是否能夠接受”。

對於老闆插入的需求你可以説：“您提出的這個需求很好，很符合我們的實際，為了不拖延項目進度，可以在下一版本進行規劃。”你還可以用數據來説服老闆，暗示他提的`這個需求和我們現在的實際情況不符。

總之一個原則就是產品項目進入開發階段以後就不要再頻繁變更和插入需求。

　　2可以提前規劃一兩個版本

產品的迭代是有一條循環的流水線的：需求發掘-版本規劃-原型策劃-原型評審-UI 設計-開發-測試-發佈。一般而言，為了效率最大化，我們都會爭取做到相鄰的兩次迭代之間能夠無縫對接。也就是流水線上每一個環節的人在完成了當前版本的工作後，就能立即執行下一個版本的需求。

產品提前規劃有個好處就是當你覺得技術在當前版本開發有餘量的情況下，可以將之後版本的需求拿到當前版本進行開發。

為什麼不提前規劃5-6個版本?一般來説一個月迭代兩個版本已經算快的了，提前規劃5-6個版本，就提前把3個月以後的事情規劃了，互聯網瞬息萬變，這樣規劃顯然是跟不上市場變化的。

　　3明確每個版本迭代的目標

每個版本迭代都是有目標的，例如互聯網電商產品的目標可以分為：拉新、留存、轉化、銷售。所以你規劃的時候就要考慮你這個版本的主要目標是這四個當中的哪一個。

這樣做的好處就是在你項目時間不夠，需要做出取捨的時候，能夠輕易的做出取捨。例如：資本寒冬的時候，推廣成本居高不下，這個時候你下個版本的主要目標是留存，那麼當你項目實現不了，需要砍需求的時候，你就可以把不相關的需求砍掉，確保你的項目順利上線。

　　4、MVP原則

最小化產品原則需要你在規劃版本的時候考慮產品功能的延展性，需不需要在一個版本里面把所有的功能都做完，可不可以分幾個版本迭代來實現。例如你規劃一個金融社區，前期是不是可以只做用户單點評論功能，在以後的版本再做用户和用户之間的互動。

最小化產品原則不僅可以快速驗證市場，同時也能更好的控制項目的開發週期。

　　5產品經理不要頻繁變更需求

很多時候產品經理在規劃產品的時候對異常情況沒有考慮清楚，很多情況都沒有考慮到，導致技術人員在開發的時候需要不斷地找產品經理確認，無形中增加了溝通成本，延長了開發週期，尤其在溝通不順暢的情況下。

這就要求產品經理不要急着出文檔去開發，一定要深思熟慮，考慮周全。這樣做有兩個好處：

· 增加在開發人員心目中的威信，更利於在工作當中的溝通

· 開發過程中你會很輕鬆，不會有開發人員不斷地找你確認需求，有利於項目的快速進行。

　　6制定明確的項目管理計劃

第一，需要明確目標。項目什麼時間封包、什麼時間上線要有一個一致的目標;第二，制定詳細計劃。有了明確的目標以後就需要制定開發計劃。產品出需求需要多久、設計需要多久、開發需要多久、測試需要多久，出一個時間節點。

這樣做有三個好處：

· 這樣會給各個部門一個壓力。

· 同時當你老闆問你項目進度的時候你也有地方可查詢。

· 你自己對項目進度也有一個大概的瞭解。

　　7對開發成本有所瞭解

上面提到產品經理要制定項目管理計劃，如果產品經理對開發成本不瞭解的話很容易被開發忽悠，導致開發的週期過長。對技術的瞭解，有利於和程序員進行溝通，減少開發過程中的溝通成本。同時對技術的瞭解，有利於在產品規劃的時候瞭解技術的實現成本，做到規劃有的放矢。

對開發技術的瞭解當然越精細越好，如果達不到專家程度，至少也要達到半骨灰級的程度。

　　8項目進度的Review

項目進度計劃做好以後，把項目分配給每個人，但是你不能保證每個人都能在時間點之前完成任務。產品經理可以每天舉行幾分鐘的站立會議，瞭解一下項目的進度，是否會有延期。如果延期，原因是什麼?如果是不可抗因素，則重新評估開發的進度計劃;如果是可抗的因素，則要求在後續想辦法趕上原計劃的進度。

如果不實行每天的站立會議，可以分為兩次review。第一次review主要看進度是否跟的上，如果跟不上是及時調整還是需要加把勁追趕。第二次review主要是是評估哪些問題可以暫時擱淺，哪些問題必須解決。

在和成員溝通進度時，尤其是在他們沒有按時完成的時候，不要斥責他們為什麼沒有按進度完成，要幫助他們解決問題。別人尊重你，你就是PM。別人不搭理你，你就只是一個P。

　　9敏捷開發的PRD文檔

我這裏所説的敏捷開發的PRD文檔是指原型+標註形式的文檔。説實話，你寫的宂長的word文檔不僅耽誤你自己的時間，開發也不一定會看，即使看了，也不方便。開發一般直接照着產品原型來開發，這個時候就需要你有一個敏捷開發的PRD文檔。

敏捷開發的PRD文檔包含版本迭代歷史、功能list、異常情況的説明、全局結構圖和重要的流程圖、第一次出現的名詞解釋，這些不能少，否則你的PRD不是一個完整的文檔。

　　10良好的溝通

項目成員包含設計、開發、測試人員等，你需要和這些人進行良好的溝通，和設計人員溝通你要有感性思維，有審美能力;和開發人員溝通，你需要有技術的邏輯思維;測試人員一般比較嚴謹，和測試人員溝通你需要有嚴謹縝密的思維。

和他們溝通項目進度的時候，如果你讓成員不必為他所説的話負責任，你就能得到負責任的回答。如果把自己和工程師當成上下游的關係，把工程師對工期的估計當作對自己的承諾，“30天才能給你”“不行，我15天就要”這不是溝通，這是對立面的談判。道已錯，追求術有什麼用?

真正有效的辦法，是讓彼此間的溝通，永遠不會成為日後扯皮時的證據。這樣才有利於拿到最真實的信息，方便做正確的判斷。

　　11使用團隊協作工具

工欲善其事，必先利其器。良好的團隊協作工具能夠減少團隊成員之間的溝通成本。比如説通過統一溝通渠道從而節省時間、避免重複溝通，自動同步信息等等。市場上的團隊協作工具不少，找一個適合自己團隊目前狀況的，團隊成員大多數都用過的。因為項目協作工具大同小異，基本上可以滿足你的團隊協作需求。

　　12有變化及時溝通

項目在做的過程中難免會出現變化的地方，變化不可怕，可怕的是變化之後其他成員不知道。你試想你更改一個需求，技術不知道，技術還是按照之前的需求進行開發，等快開發完成以後，技術知道需求變了，會不會有殺人的衝動?

其次能當面溝通就別打電話，能打電話就別發郵件，一切以溝通高效為主。

人少的時候，同步變化其實不是什麼困難的事情，但人多的時候就有難度了。雖然很多協作工具都有文檔更新通知，或者文檔本身就有修改記錄。但即便如此，也會有很多人忽略這些變動。在同步變化上，除了確保文檔及時修改、告知相關設計師、工程師和測試人員以外，還可以單獨召集各平台的 leader 進行簡單的站立會議，提醒其確認變更是否已安排執行，同時也相當於交接了監管的責任。