大一點(diǎn)的項(xiàng)目都會(huì)再指定一個(gè)項(xiàng)目經(jīng)理來協(xié)助產(chǎn)品經(jīng)理，以確保項(xiàng)目能最終上線，這種情況在大公司很常見，小公司就不說了，否則怎么叫苦逼的產(chǎn)品經(jīng)理呢。

在接觸了幾個(gè)這樣的項(xiàng)目之后，感覺這種配合模式比較難達(dá)到非常和諧的地步，項(xiàng)目經(jīng)理從項(xiàng)目立項(xiàng)開始跟進(jìn)，到項(xiàng)目上線，其要保證項(xiàng)目不被delay；產(chǎn)品經(jīng)理介入的會(huì)更早，前期用戶調(diào)研，需求確認(rèn)等等就已經(jīng)參與了，到項(xiàng)目執(zhí)行的過程和最終上線運(yùn)營，都需要參與進(jìn)去，中間如果不是敏捷開發(fā)，沒有嚴(yán)格的迭代控制，那么需求變更不可避免，自然就會(huì)影響到項(xiàng)目的進(jìn)度，這里就不以敏捷開發(fā)為例了，就以常見的瀑布式為例。
　　之前有寫過一篇文章《如何區(qū)分產(chǎn)品管理與項(xiàng)目管理》，里面就大概講了一下產(chǎn)品經(jīng)理與項(xiàng)目經(jīng)理的分工和協(xié)作，真正要嚴(yán)格的區(qū)分開來是比較難的，在工作過程當(dāng)中都是結(jié)合的比較緊密的，拿親身經(jīng)歷的實(shí)際例子來說，一個(gè)項(xiàng)目在立項(xiàng)之前，是沒有項(xiàng)目經(jīng)理的，這個(gè)過程全部都由產(chǎn)品經(jīng)理負(fù)責(zé)，主要是要完成需求確認(rèn)的過程，待到項(xiàng)目立項(xiàng)之后，一般項(xiàng)目經(jīng)理都是開發(fā)負(fù)責(zé)人或者測(cè)試負(fù)責(zé)人，這時(shí)問題就來了。
　　1、對(duì)工作量的評(píng)估
　　產(chǎn)品經(jīng)理一般對(duì)某個(gè)項(xiàng)目的上線運(yùn)營是要背KPI指標(biāo)的，在多長時(shí)間內(nèi)上線，因此如果前期需求調(diào)研時(shí)間長了，后期就會(huì)很緊張，就會(huì)希望開發(fā)和測(cè)試加快速度，難聽點(diǎn)就是加班；項(xiàng)目經(jīng)理會(huì)更多的從實(shí)際工作量的角度去評(píng)估，往往一開始評(píng)估出來的工作量都讓產(chǎn)品經(jīng)理大跌眼鏡，產(chǎn)品經(jīng)理認(rèn)為只要20個(gè)工作日的，項(xiàng)目經(jīng)理說需要40個(gè)工作日，都還是保守估計(jì)，這個(gè)時(shí)候?yàn)榱吮ＷC項(xiàng)目的按時(shí)上線，是要協(xié)商的，個(gè)人覺得這里有一個(gè)共識(shí)的問題，就是前期沒有讓開發(fā)人員參與需求的討論，或者產(chǎn)品經(jīng)理沒有將需求實(shí)現(xiàn)的價(jià)值、意義和項(xiàng)目經(jīng)理講清楚，這樣就會(huì)存在認(rèn)識(shí)上的偏差，當(dāng)為了做任務(wù)而做任務(wù)的時(shí)候，可想而知是沒有什么緊迫感的，但要是從產(chǎn)品的角度出發(fā)，完全會(huì)是兩碼事。因?yàn)閭€(gè)人建議在進(jìn)行需求講解的時(shí)候，不要一味的只講功能點(diǎn)和實(shí)現(xiàn)邏輯，一定要說實(shí)現(xiàn)的產(chǎn)品價(jià)值，給大家一個(gè)主人翁的共識(shí)，這樣在協(xié)調(diào)工作量問題的時(shí)候會(huì)好很多，而且后續(xù)的過程當(dāng)中也會(huì)順暢很多。
　　2、對(duì)需求變更的容忍度
　　對(duì)于產(chǎn)品人員來說，需求變更是家常便飯，哪個(gè)產(chǎn)品在做的過程當(dāng)中沒有進(jìn)行過需求變更，這個(gè)產(chǎn)品的不靠譜指數(shù)估計(jì)就會(huì)很高，因此對(duì)產(chǎn)品經(jīng)理們來說，需求變更時(shí)很正常的，雖然也要控制變更的頻率，太過頻繁的變更就證明產(chǎn)品的框架結(jié)構(gòu)有問題了，或者已經(jīng)偏離了原來的主要方向。但開發(fā)人員不是這么認(rèn)為的，當(dāng)一個(gè)功能辛辛苦苦開發(fā)出來，馬上接到通知說這個(gè)功能不要了，要換成另外一種，這種情況發(fā)生的次數(shù)多了，換成任何一個(gè)人都會(huì)覺得是被耍了，畢竟都是自己的成果，說不要就不要了，說改就得改了，而且變更的次數(shù)多了也會(huì)影響項(xiàng)目進(jìn)度，如果開發(fā)負(fù)責(zé)人是項(xiàng)目經(jīng)理的話，問題就來了。這種情況一是一定要讓項(xiàng)目經(jīng)理理解需求變更的目的及其價(jià)值所在，做好溝通，確保每次變更都是能讓各方接受的；二是要嚴(yán)格控制版本，減少變更的次數(shù)和降低變更的頻率，做好迭代周期的規(guī)劃。
現(xiàn)在有一種新的方式來解決協(xié)作問題，那就是引入PMO來做項(xiàng)目經(jīng)理，既不是產(chǎn)品經(jīng)理也不是開發(fā)人員、測(cè)試人員，總之是不在產(chǎn)品團(tuán)隊(duì)里面的，只是過來管理項(xiàng)目的。這樣有個(gè)好處是避免了項(xiàng)目管理的束縛，整個(gè)產(chǎn)品團(tuán)隊(duì)可以安心的做產(chǎn)品，但問題也很顯然，第一是PMO只是來管理項(xiàng)目的，必然是以項(xiàng)目進(jìn)度為重；第二是PMO不一定懂產(chǎn)品策略，出現(xiàn)問題的時(shí)候溝通比較麻煩。個(gè)人是不建議把一個(gè)項(xiàng)目周期掐的很死的，要控制單可以適當(dāng)?shù)母鶕?jù)實(shí)際情況來調(diào)整，把項(xiàng)目是否delay看成是一個(gè)KPI的話，會(huì)比較杯具。敏

    項(xiàng)目經(jīng)理勝任力免費(fèi)測(cè)評(píng)PMQ上線啦！快來測(cè)測(cè)你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html