專 案 管 理 輕 鬆 學

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

對工作量的評估

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

對需求的理解角度

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

對需求變更的容忍度

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

現在有一種新的方式來解决協作問題，那就是引入PMO來做專案經理，既不是産品經理也不是開發人員、測試人員，總之是不在産品團隊裏面的，只是過來管理專案的。這樣有個好處是避免了專案管理的束縛，整個産品團隊可以安心的做産品，但問題也很顯然，第一是PMO只是來管理專案的，必然是以專案進度爲重；第二是PMO不一定懂産品策略，出現問題的時候溝通比較麻煩。個人是不建議把一個專案周期掐的很死的，要控制單可以適當的根據實際情况來調整，把專案是否delay看成是一個KPI的話，會比較悲劇。敏捷開發的話會稍微好一點，只有一個大周期，所有人員都是置身其中的。

其實多數情况下一個專案裏面都只有産品經理，個人覺得這樣比較好，雖然比較難，但就不存在多頭領導人了，做那麽多leader，把大家都弄暈了不說，還容易出現矛盾。中國人有個特色，無官一身輕，有點官了就要擺官架子，網際網路行業還稍微好點，但大公司裡還是容易滋生官僚主義，所以說小型公司適合創業適合做産品，因爲沒有那麽多的流程約束。

文章節錄：項目管理網

圖片來源：1 2 3

ProjectClub 專案俱樂部為一群專案經理人組成的平台，網站分享專案運作的各種專案管理手法與實用專案工具，並分享如何提昇職場人的軟技巧與硬實力。