产品经理60的时间用于沟通协调，如何破局？

　　据不完全统计，笔者在工作中约60以上的时间用于沟通协调。当团队中理应提供洞察，为产品指明道路的产品经理们深陷体力协作的低效率泥潭时，产品经理在自身价值感变得稀薄的同时，产品的市场表现也将趋向平庸。是否有办法跳出低效循环？如果你也在被类似问题困扰，欢迎进来聊聊。
　　本问的本质是一篇求助文，笔者将为大家介绍自身在工作中碰到的问题及问题发生的背景，及原因的剖析，希望在给大家带来启发的同时，也可以收集到大家的意见，为解决问题提供新的可能性。
　　问题发生的背景
　　笔者在一家K12教育公司做产品（小学业务），主业务是2019年比较热的在线教育班课，具有重运营，强KPI导向的特征。笔者从冷启动阶段加入产品团队，陪伴产品进入成长期，目前在业务上做大量尝试，产品迭代频率高，业务拓张速度快，很多问题亦随之出现。
　　业务组织背景
　　每条业务线都是一个敏捷团队，有着自己的核心指标及迭代节奏。
　　在公司层面，这种业务架构的优势是线内效率足够高，业务响应速度快，灵活度较高；缺点是跨线协作成本极高，各业务线之间诉求不一致，信息孤岛效应明显。
　　团队背景
　　产品研发设计数据运营是敏捷团队标配；笔者所处的产品团队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以上的工作时间，我们距离真正的“脑力协作”还有很远的路要走。
　　大量琐碎的项目管理，沟通推进将我们的工作时间和价值感一起碎片化。
　　每日三省吾身：“项目能否按时交付乎？决策质量是否提高乎？懂用户乎？”
　　我能勉强回答第一个问题，但第二个和第三个问题却日夜煎熬着我，难以安眠。
　　不论你是和我一样的小白新人，还是项目经验丰富的前辈，如果我抛出的问题也同样困扰着你和你的团队，那么请和我坐下聊一聊，相信我们有机会解决这个行业问题。