據不完全統計，筆者在工作中約60%以上的時間用于溝通協調。當團隊中理應提供洞察，為產品指明道路的產品經理們深陷「體力協作」的低效率泥潭時，產品經理在自身價值感變得稀薄的同時，產品的市場表現也將趨向平庸。是否有辦法跳出低效循環？如果你也在被類似問題困擾，歡迎進來聊聊。

本問的本質是一篇「求助文」，筆者將為大家介紹自身在工作中碰到的問題及問題發生的背景，及原因的剖析，希望在給大家帶來啟發的同時，也可以收集到大家的意見，為解決問題提供新的可能性。

問題發生的背景

業務組織背景

每條業務線都是一個敏捷團隊，有著自己的核心指標及迭代節奏。

在公司層面，這種業務架構的優勢是線內效率足夠高，業務響應速度快，靈活度較高；缺點是跨線協作成本極高，各業務線之間訴求不一致，信息孤島效應明顯。

團隊背景

「產品+研發+設計+數據+運營」是敏捷團隊標配；筆者所處的產品團隊3人，產品及研發比例穩定維持在1：6，隨著業務發展，影響效率的明顯變量：

1. 團隊：業務人員數量激增

半年內，業務團隊從30人拓張至150人+，意味著產品需要在業務人員的效能上提供支持。

2. 業務：業務模型尚未調整至最優，需頻繁做嘗試

高頻率的實驗對團隊的整體信息管理提出更高要求，大量的投放AB對照實驗，產品每個迭代此類業務需求占需求總量的70%。

問題發生的場景

團隊內&外日常協作

場景一：插入需求

Boss：今天戰略組給了最新信息，出臺了新政策XXX，我們需要在這個迭代內上線XX，你別用這種眼神看著我，沒錯，就走插入需求~

我：我手上優先級次高的需求是XXX和XXX，如果是我來推進，大概率會替換掉這兩個需求。但我知道Tony（其他PM）手上的需求這期排的不是很滿（甩鍋+1），不如咱們拉產品組討論下？

Boss：好的，你來拉會，我今天下午4點之后和明天上午10點有時間

我：（拉起產研會議）省略1W字，強行達成共識，確定了插入需求的負責人和置換掉的項目

插入評審會議：開發負責人生無可戀的參會，同步了本迭代項目的推進狀況，和產品明確了項目優先級后，重新分配了開發資源（產品組威信-100）

場景二：內部日常溝通

BI：咱們的這個流量入口，現在是按照什么判斷條件，什么流量比例分發流量？總共有幾個實驗組？

我：我上周做了一期，是按XX條件，XX比例分發，總共XX組。不確定實驗組的總量，我印象中上個迭代是呆呆（其他PM）在負責這部分邏輯。

BI：上周是泡泡（其他BI）在負責這個項目，我問過她，她說上周封版后XX（產品老大）走了一個插入需求，加了一個分發邏輯

我：這種不可見的邏輯最頭疼了，我問下老大和呆呆

釘釘拉群：（產品未能達成共識，拉入了負責的開發和BI，最終拼湊出了原需求的全貌）

場景三：跨線協作

我：hey，我們有這樣一個需求blahblah，我們希望的時間點是blahblah

接口人：嗯，這個需求實現需要和我們的開發確認，設計需要和我們的UI確認，有數據預期嗎？最好和BI也說一下。

我：排期目前確認不了嗎？

接口人：最近排期比較滿，我建議先把兩邊的相關人員拉個會吧。

我：（拉起會議）咦，你們的開發負責人呢？

接口人：他今天請假啦，咱們先對接信息吧，明天我幫你你單約下負責人

我：（對接了部分信息，會議結束，由于信息缺失并未達成共識）

-隔天，帶著我線的開發負責人約到了開發負責人

我：您好，想必XXX（接口人）已經給您介紹過背景了

負責人：沒有，你幫我簡單介紹下吧

我：blahblah，您看可以進排期嗎？

負責人：額，這個需要和XXX（另一條線的某研發負責人）確認，確實對他們有依賴，下周咱們找時間開個會吧。

我：（本月第X次燃起離職念頭）

日常協作問題總結

不論項目內外，能看到的共性問題是我們必須先“搞定人”才能獲取我們決策需要的信息；我們需要將搞定的“所有人”加工過的信息拼湊起來，才能勉強窺得信息的全貌。

理想場景和現實場景總是有所出入：

項目管理

項目推進流程：

在最理想的狀況下，我們按周推進需求，會有各種不可抗力導致需要插入需求。

最理想的項目推進場景，產品團隊規劃好需求后，協調資源推進需求，按時交付。

（實際推進項目時，資源和任務之間的聯系更加復雜，為了便于對比，予以簡化）

總有多種多樣的原因導致我們的項目無法按時交付：

場景一：項目外部

最高頻的場景是因外力（外部政策如ios平臺、TX、政府 or 內部高層行政命令）等原因導致的需求插入&變更，使得原有項目無法按時交付。

場景二：項目內部

偶發場景是某塊資源的負責人因故（突發生病、離職等）無法按時交付原定的子任務，這時需要重新協調項目資源達成目標。

項目管理問題總結

在真實場景下，需求的變更往往會在資源分配層面構成蝴蝶效應，牽一發而動全身，現有的手段和工具只能讓我們的項目相對透明，卻沒辦法幫我們管理項目的風險。

團隊現階段使用的信息同步工具：

異常流程導致的資源二次分配，成本較高：

二次分配的成本往往比初次分配高，需要全盤權衡正在推進項目的優先級，還要兼顧現有的項目推進情況、資源狀況。

項目風險管理困難：

在做二次決策的場景下，往往要求決策者在極短的時間內，做出一個低容錯率的決策。這要求決策者對業務預期、資源分布、現有實現邏輯有全面了解。但作為項目的執行者，由于信息獲取的成本較高，執行時往往很難在短時間內看到項目的全貌，這為項目的交付時間和質量埋下隱患。（理想場景下應該有高一個層級的人來做這一類型的決策；但現實場景下，項目風險往往都由執行者承擔）

分析問題

抽象問題

無論是團隊內部的信息同步、項目管理，亦或是對外的跨線合作，基于以上背景，筆者認為導致協作效率低的核心原因集中在三方面：

獲取信息的成本高：我們往往先“搞定人”才能“搞定事”。

整合信息的成本高：我們需要將各個職能“加工”過的信息（每個人管理信息的習慣和水平都有所不同）拼湊起來，才能一窺需求全貌。

信息流失的風險高：想想那些離職的前輩們留下的“祖傳代碼”和“祖傳PRD”，咱也不知道，咱也不敢問。

原因分析

獲取信息成本高的原因：

職業分工垂直，不同職能間有信息鴻溝：同理心彌補不了專業上的信息差，和傳統行業相比，互聯網的專業分工縱深更深。

依賴個人的信息管理能力及溝通能力：人非圣賢，人一定會出錯。在中小型團隊中，產品寫PRD、繪制原型的習慣不同；開發寫代碼的習慣也不同；很多公司的設計師沒有統一的設計規范。依賴個人管理的信息一定會流失，這是可預期的。

流程的設置往往具備滯后性：和傳統行業相比，互聯網的拓張速度是無可比擬的，帶來的問題是上升期的互聯網公司往往無暇顧及管理，即使制訂了流程也遠遠趕不上團隊和業務拓張的速度。（見過部分公司將“0管理”和“扁平管理”劃等號）

整合信息成本高的原因：

儲存信息的節點分散（儲存在個人的知識庫中）。

信息總量邊界不明，當做一個決策時，從初步假設到最終決策，往往隨著接觸到的人，獲取到各式各樣被主觀“加工”過的信息，甚至在同一個問題上不同的人會給出完全相反，或模棱兩可的結論。（筆者本身經驗尚淺有關，理論上隨著經驗增加，對信息有效性的判斷會更加客觀）。

拋磚引玉

基于以上背景，相信你對我在工作的各個場景下碰到的問題已經有所了解?！叭绾谓档托畔@取&整合的成本？如何降低信息流失的風險？”截至發文日，仍然沒能找到可落地的解法。

產品經理雖然是理論上的“腦力勞動者”，但“體力協作”卻占據了我們60%以上的工作時間，我們距離真正的“腦力協作”還有很遠的路要走。

大量瑣碎的項目管理，溝通推進將我們的工作時間和價值感一起碎片化。

每日三省吾身：“項目能否按時交付乎？決策質量是否提高乎？懂用戶乎？”

我能勉強回答第一個問題，但第二個和第三個問題卻日夜煎熬著我，難以安眠。

不論你是和我一樣的小白新人，還是項目經驗豐富的前輩，如果我拋出的問題也同樣困擾著你和你的團隊，那么請和我坐下聊一聊，相信我們有機會解決這個行業問題。

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

題圖來自Unsplash，基于CC0協議