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

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

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

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

項目管理三種模式

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

1、設置項目經理職位

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

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

2、技術leader承擔項目管理

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

3、PM承擔項目管理

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

公司的項目管理

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

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

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

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

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

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

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

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

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

小結

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

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

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

延伸思考

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

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

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

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

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

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

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

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

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

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

總結

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

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

作者：Fintechina，互聯網證券公司產品經理，專注于國外證券投資市場產品服務，熱衷智能投顧和海外資產配置業務方向的探索。

本文由 @Fintechina 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自unsplash，基于CC0協議