這個問題是肯定會遇到的，大一點的項目都會再指定一個項目經(jīng)理來協(xié)助產(chǎn)品經(jīng)理，以確保項目能最終上線，這種情況在大公司很常見，小公司就不說了，否則怎么叫苦逼的產(chǎn)品經(jīng)理呢。在接觸了幾個這樣的項目之后，感覺這種配合模式比較難達到非常和諧的地步，項目經(jīng)理從項目立項開始跟進，到項目上線，其要保證項目不被delay；產(chǎn)品經(jīng)理介入的會更早，前期用戶調(diào)研，需求確認等等就已經(jīng)參與了，到項目執(zhí)行的過程和最終上線運營，都需要參與進去，中間如果不是敏捷開發(fā)，沒有嚴格的迭代控制，那么需求變更不可避免，自然就會影響到項目的進度，這里就不以敏捷開發(fā)為例了，就以常見的瀑布式為例。

之前有寫過一篇文章《如何區(qū)分產(chǎn)品管理與項目管理》，里面就大概講了一下產(chǎn)品經(jīng)理與項目經(jīng)理的分工和協(xié)作，真正要嚴格的區(qū)分開來是比較難的，在工作過程當中都是結合的比較緊密的，拿親身經(jīng)歷的實際例子來說，一個項目在立項之前，是沒有項目經(jīng)理的，這個過程全部都由產(chǎn)品經(jīng)理負責，主要是要完成需求確認的過程，待到項目立項之后，一般項目經(jīng)理都是開發(fā)負責人或者測試負責人，這時問題就來了。

對工作量的評估

產(chǎn)品經(jīng)理一般對某個項目的上線運營是要背KPI指標的，在多長時間內(nèi)上線，因此如果前期需求調(diào)研時間長了，后期就會很緊張，就會希望開發(fā)和測試加快速度，難聽點就是加班；項目經(jīng)理會更多的從實際工作量的角度去評估，往往一開始評估出來的工作量都讓產(chǎn)品經(jīng)理大跌眼鏡，產(chǎn)品經(jīng)理認為只要20個工作日的，項目經(jīng)理說需要40個工作日，都還是保守估計，這個時候為了保證項目的按時上線，是要協(xié)商的，個人覺得這里有一個共識的問題，就是前期沒有讓開發(fā)人員參與需求的討論，或者產(chǎn)品經(jīng)理沒有將需求實現(xiàn)的價值、意義和項目經(jīng)理講清楚，這樣就會存在認識上的偏差，當為了做任務而做任務的時候，可想而知是沒有什么緊迫感的，但要是從產(chǎn)品的角度出發(fā)，完全會是兩碼事。因為個人建議在進行需求講解的時候，不要一味的只講功能點和實現(xiàn)邏輯，一定要說實現(xiàn)的產(chǎn)品價值，給大家一個主人翁的共識，這樣在協(xié)調(diào)工作量問題的時候會好很多，而且后續(xù)的過程當中也會順暢很多。

對需求的理解角度

產(chǎn)品經(jīng)理更多的是從業(yè)務的角度去理解去設計，而項目經(jīng)理大多是從技術實現(xiàn)的角度來考慮，看問題的角度不一樣，決定了會有很多沖突。比如產(chǎn)品經(jīng)理在設計某個需求功能時候，認為這個功能是必備的功能，且是滿足業(yè)務要求的；項目經(jīng)理看了之后覺得實現(xiàn)的代碼量巨大，就想對這個功能點進行攔腰斬，只做其中一部分，甚至建議不做，或者說會影響性能卻又給不出更好的方案時提議能否暫時不做這個功能。這種情況下就會產(chǎn)生很大的矛盾，這種時候就需要建立一種負責制，遇到分歧的時候到底聽誰的，是產(chǎn)品經(jīng)理說了算還是項目經(jīng)理說了算，理論上來說沒有任何功能是技術無法實現(xiàn)的，應該由產(chǎn)品經(jīng)理來評估決定最好到底要不要做這個功能。

對需求變更的容忍度

對于產(chǎn)品人員來說，需求變更是家常便飯，哪個產(chǎn)品在做的過程當中沒有進行過需求變更，這個產(chǎn)品的不靠譜指數(shù)估計就會很高，因此對產(chǎn)品經(jīng)理們來說，需求變更時很正常的，雖然也要控制變更的頻率，太過頻繁的變更就證明產(chǎn)品的框架結構有問題了，或者已經(jīng)偏離了原來的主要方向。但開發(fā)人員不是這么認為的，當一個功能辛辛苦苦開發(fā)出來，馬上接到通知說這個功能不要了，要換成另外一種，這種情況發(fā)生的次數(shù)多了，換成任何一個人都會覺得是被耍了，畢竟都是自己的成果，說不要就不要了，說改就得改了，而且變更的次數(shù)多了也會影響項目進度，如果開發(fā)負責人是項目經(jīng)理的話，問題就來了。這種情況一是一定要讓項目經(jīng)理理解需求變更的目的及其價值所在，做好溝通，確保每次變更都是能讓各方接受的；二是要嚴格控制版本，減少變更的次數(shù)和降低變更的頻率，做好迭代周期的規(guī)劃。

現(xiàn)在有一種新的方式來解決協(xié)作問題，那就是引入PMO來做項目經(jīng)理，既不是產(chǎn)品經(jīng)理也不是開發(fā)人員、測試人員，總之是不在產(chǎn)品團隊里面的，只是過來管理項目的。這樣有個好處是避免了項目管理的束縛，整個產(chǎn)品團隊可以安心的做產(chǎn)品，但問題也很顯然，第一是PMO只是來管理項目的，必然是以項目進度為重；第二是PMO不一定懂產(chǎn)品策略，出現(xiàn)問題的時候溝通比較麻煩。個人是不建議把一個項目周期掐的很死的，要控制單可以適當?shù)母鶕?jù)實際情況來調(diào)整，把項目是否delay看成是一個KPI的話，會比較杯具。敏捷開發(fā)的話會稍微好一點，只有一個大周期，所有人員都是置身其中的。

其實多數(shù)情況下一個項目里面都只有產(chǎn)品經(jīng)理，個人覺得這樣比較好，雖然比較難，但就不存在多頭領導了，搞那么多l(xiāng)eader，把大家都弄暈了不說，還容易出現(xiàn)矛盾。中國人有個特色，無官一身輕，有點官了就要擺官架子，互聯(lián)網(wǎng)行業(yè)還稍微好點，但大公司里還是容易滋生官僚主義，所以說小型公司適合創(chuàng)業(yè)適合做產(chǎn)品，因為沒有那么多的流程約束。