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