產品經理or項目經理，關于職責和工作的思考

互聯網公司中，產品經理兼任項目經理職責的情況已經很普遍，PM經常會承擔起日常產品項目的推進和執(zhí)行。每個公司要求PM負責項目管理的具體工作各有不同，只有進行合理的定位和職責分配，才能發(fā)揮PM應有的價值，提升團隊的效率和質量。

公司年會，酒過三巡之后，同事們開始和我推心置腹說平常工作上的感悟。酒后吐真言，同事也開始毫無顧忌的說出對我的評價，雖然被別人批評總是難以接受，但從批評中總能得到對自己有價值的信息。而其中最重要的一個評價便是：

在項目項目開發(fā)中，因為對技術沒有深入的理解，所以造成對產品需求開發(fā)時間認知的偏差，從而給開發(fā)同事定的開發(fā)排期造成其較大的壓力。

項目管理三種模式

這個評價主要集中在項目管理方式上，目前在行業(yè)里關于項目管理的模式主要有三種：

1、設置項目經理職位

在成熟型的企業(yè)中，一般都會有項目經理職位，負責整個產品項目的執(zhí)行和落地，主要包括項目成本的核算、協調資源開發(fā)、項目推進及管理。

在項目開發(fā)過程中，PM參與的環(huán)節(jié)主要有：完成產品需求的技術評審、交付完整的PRD、產品開發(fā)中就需求與研發(fā)溝通、開發(fā)完成后的產品驗收。

2、技術leader承擔項目管理

有些企業(yè)，產品項目會由技術leader負責開發(fā)與推進，PM的職責工作與第一種模式基本一致。

3、PM承擔項目管理

還有一些企業(yè)，PM負責產品的開發(fā)和推進，因此PM除了以上和產品需求相關的職責之外，還兼具的職責有：協同各部門安排產品項目成員、協助技術leader確定各個環(huán)節(jié)的產品開發(fā)排期、定期的進度跟蹤、項目變更時的優(yōu)先級和排期調整、項目交付與上線。

公司的項目管理

那么我們公司目前的項目管理模式屬于哪種呢？其實準確的說哪種都不屬于，只是傾向于第三種，而其和第三種的不同之處在于，PM還承擔了另外兩個重要的職能：

1、在組織討論產品技術方案的過程中，前后端開發(fā)人員的職能相互割裂 ，無法給出針對產品系統(tǒng)性的技術架構。而且開發(fā)人員之間缺乏主動溝通橋梁，需要PM去協調串通。那么PM需要深度參與產品技術從架構到細節(jié)的方案中。

舉個例子，我們曾經的一個功能在開發(fā)過程中，發(fā)現已有的技術方案完全不適用。然后所有開發(fā)人員在一起面面相覷，找不出解決辦法。最后由我技術功底較強的產品同事給出了解決方案。包括在哪個環(huán)節(jié)出接口、客戶端傳什么參數、需要在哪個數據庫中建幾張表、哪些字段是已有而哪些字段需要新增等。

2、PM參考開發(fā)人員給出開發(fā)工作量之后，確定最終的開發(fā)排期。因此這個排期就會面臨雙方的博弈，開發(fā)人員為了避免可能帶來較大工作量的風險以及對不可預知的需求留出緩沖時間，會將給出較為充裕的排期。而PM為了滿足產品的迭代節(jié)奏和高層的預期，會壓縮開發(fā)的排期。因此最終雙方會權衡一個排期的中間點。

而問題的關鍵點就在于，這個權衡排期的中間點是否合理。其合理性滿足兩個條件：

• PM能順利進行正常的產品迭代節(jié)奏，以及滿足高層的預期
• 開發(fā)人員不至于因為緊張的排期承受較大的工作壓力

因為產品開發(fā)最終的排期是由PM決定，那么其合理性的核心就在于：PM能否準確預估到一個產品從界面、邏輯到聯調的開發(fā)需要多大工作量。

就如同我們去買東西時的討價還價一樣，確定購買的唯一準則便是對商品的內在價值心理有數，不論賣家如何吹噓都不改變看法。而要做到心中有數就是能真正了解和認識我們要買的商品。

同樣地，PM能否準確預估產品的開發(fā)量，就在于是否理解到產品涉及到技術和開發(fā)流程。如果沒有深度開發(fā)產品的經驗，我相信這個能力是不存在的。

小結

從上面的分析可以看出，為何開發(fā)同事會指出這樣的缺點，本質原因就是在公司做產品需要兩個條件：

• 正常PM所具備的素質和能力
• 有產品開發(fā)經驗，能夠對產品技術和開發(fā)有深入的認知

因為自己沒有開發(fā)和寫代碼經驗，對技術認知并不深入，因此造成如今存在的困局。

延伸思考

從上面三種行業(yè)項目管理模式可以看出，其核心在于對產品項目的開發(fā)排期，是由項目的對應技術leader來進行評估后給出。

而我們公司的技術leader呢？答案是leader并不參與整個產品項目的開發(fā)和執(zhí)行環(huán)節(jié)，因此不會參與到給技術方案和開發(fā)排期中，原因需要從公司的組織架構和管理說起，目前公司的組織架構有兩個維度：

• 縱向上：按職能部門劃分，包括產品部、UED、iOS開發(fā)部、Android開發(fā)部、后端開發(fā)部等，由部門leader領導
• 橫向上：按業(yè)務線劃分，包括投顧、經紀、期貨等業(yè)務線，日常的產品和項目由PM統(tǒng)籌

而目前公司的管理風格是：重業(yè)務線，輕職能部門。人員安排和資源協調基本是PM直接越過部門leader，向相關業(yè)務線開發(fā)人員直接分配工作。而部門leader的職責基本僅限于人員招聘，以及各業(yè)務線人員沖突時的協調，其他時間便是做產品需求。

因此leader并不會參與產品開發(fā)技術方案和排期工作上，那為何會如此呢？

在公司，產品經理的直接匯報對象是老板，老板要求產品需求和項目管理的各個環(huán)節(jié)由PM負責，當然如果產品開發(fā)未達預期首先也是向PM問責。

那么問題的矛盾之處就在于，如果技術leader并未被分配承擔應有的職責，那么leader也就沒有理由和動力參與到產品開發(fā)和排期的工作中。

為何會出現這樣的職責分配和工作流程？

我的看法是：這和創(chuàng)始人對于管理的認知密不可分，公司從創(chuàng)立的那天起就確立了老板需要一手掌控全局和細節(jié)的管理風格。當公司越來越壯大，員工越來越多（現在有200人左右），創(chuàng)始人如果還需要事無巨細掌控公司的一切就會越來越困難。

如何在公司壯大的過程中創(chuàng)始人還能絕對地掌控公司，老板給出了一個于他而言不那么復雜的方式：老板驅動產品經理，產品經理驅動其他團隊。PM需要深入到公司業(yè)務的各個環(huán)節(jié)，而老板只需緊盯PM，讓PM去解決所有問題。

總結

任何一個問題地提出都有其背后的原因，而PM需要透過現象去尋找本質，這其實也是一個從需求采集、分析到產品設計的過程。

如果要適應公司的風格，我需要做的其實是在短時間內就能具備深入了解技術的能力，最好能親自寫代碼和實現產品。而PM的能力模型中，對技術的深入理解甚至有開發(fā)產品經驗真的是其核心要素嗎？我心中已有答案。




摘自：人人都是產品經理