起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理60%的時間用于溝通協調，如何破局？
據不完全統計，筆者在工作中約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協議
這個抽象挺好的
筆者所在的公司以及團隊環境，實在是太南了，現在很多PM所煩惱的通??；
1、多數存在于小型、分散式團隊，以及重業務類型公司；
2、要想解決根本問題，達到筆者所說的“PM做腦力勞動”的效果，還是得從公司層面、領導層面來推動；
3、其次筆者這種環境，一般都是直接找技術負責人、或相應項目的負責人來溝通和協調比較好，讓負責人自己去傳達給自己的下屬團隊；
4、要想達到實際解決效果，除了自己學會著去安排、積極溝通和推動外，就是公司或領導層面提供協助解決；
總結的挺到位的，實際場景不同但是很多產品經理都遇到相似的問題。
個人覺得
1、廣義點：就是需求的管理、上級管理、資源管理
2、狹義點：說點我自己的經驗
1）迭代需求占比：
新需求、優化功能，數量上占比2:8，工期(或工時)上占比6:4
2）需求明確的優先級:
對所有排期需求，優先級又高到底，從1開始自然數不許重復。必須明確出來準確的優先級（拍腦袋也要拍出1-n的數字數來）
3）跟老板協商（這個要看各個公司了）
比如我們是3周一個固定迭代周期，研發2周，測試產品1周。
排期內第二周后半周，堅決不接新需求。所有需求下個迭代。
4）需求調整
I、接到插入需求，我們會跟研發溝通。不影響排期就加進去。
II、影響排期我們會按照優先級從后移除需求。
（這里面2個共識要求：基本排期后面的需求都是產品內部需求；研發開發過程中是按照優先級開發的。）
3、各種會議時無法避免的，溝通其實也是產品經理的主要工作。產品溝通時間占比低的企業問題可能會更多
1）避免無效會議
套用項目管理中的干系人管理
如果你要解決一個問題去召開會議，首先就要會議前明確所有干系人。
主要干系人及決策人在的時候，會議才是有效的。
當然還有其他方面（不過有時明知道是無效會議，也會開的另算）
2）明確會議目標
比如：Boss的臨時需求，可能影響了多條線的交付。那就把相關產品線的負責人叫到一起。（該扯大旗的時候，要扯起來）
與老板溝通，明確溝通的目標：1、需求下個版本；2、合理更改需求范圍；
（因為你硬加班趕，極有可能造成多條線的不穩定）
PS：其實很多還是根據企業結構，內部人員關系。采用不同的方式。沒什么固定的套路。
合適的就是最有效的。
前2點，挺科學
新需求、優化功能，數量上占比2:8，工期(或工時)上占比6:4。請問實際工作中是否驗證過這個時間比？
認真看了半天，分析的挺有道理，最后沒有解決方案······
寫得挺好的?！白鎮鞔a”太幽默了，忍不住會心一笑。我覺得PM作為產品信息的樞紐，溝通協調的工作是不可避免的，但可以想辦法提高一點效率。比如在溝通協調過程中，把碎片信息記錄下來，并分析整理成為自己的知識圖譜的一部分，再之后遇到相關的問題就可以快速找到關鍵人、解決關鍵問題。長此以往，你對自己產品線的產品，甚至整個公司的業務都能有一個更全面的解，到那時你在公司內的認知水平也將高出一般人的水平。升職加薪走上人生巔峰——這個還是得看運氣哈 ?? ，但還是能收獲不少的成就感的。
還是厲害，這么個問題都說的這么高大上，給你個建議，找具體負責人去溝通。
看了半天只說了問題所在，沒有說怎么解決
有假設的解法，但是還沒有驗證有效，完成初步驗證后會再就解法寫一篇。希望可以確認在和我一樣1-3年的初級產品是否碰到類似的問題，感興趣可以深聊哦~
你說的情況都是無法避免的，體力協作必然要占用我們這么多時間。我用的方法是經量把各種體力協作安排地緊湊，中間經量不要有碎片時間，擠出時間，每天至少安排一小時完整的時間，思考產品方向?？赡艿脑捲贁D出半個小時到一個小時學習線上各位大佬的經驗
頭痛+1
有假設的解法，但是還沒有驗證有效，完成初步驗證后會再就解法寫一篇。希望可以確認在和我一樣1-3年的初級產品是否碰到類似的問題，感興趣可以深聊哦~
? 竟然沒有提供解決方案
是的呢 ，方案呢 ??
希望可以和碰到類似問題的同學交流，wechat：ZBC19950305請備注人人，base北京，節假日可面基~
也面臨這種問題 以為能獲得經驗 原來是拋磚引玉
有假設的解法，但是還沒有驗證有效，完成初步驗證后會再就解法寫一篇。希望可以確認在和我一樣1-3年的初級產品是否碰到類似的問題，感興趣可以深聊哦~
哈哈哈