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

　　据不完全统计，笔者在工作中约60以上的时间用于沟通协调。当团队中理应提供洞察，为产品指明道路的产品经理们深陷体力协作的低效率泥潭时，产品经理在自身价值感变得稀薄的同时，产品的市场表现也将趋向平庸。是否有办法跳出低效循环？如果你也在被类似问题困扰，欢迎进来聊聊。
　　本问的本质是一篇求助文，笔者将为大家介绍自身在工作中碰到的问题及问题发生的背景，及原因的剖析，希望在给大家带来启发的同时，也可以收集到大家的意见，为解决问题提供新的可能性。
　　问题发生的背景
　　笔者在一家K12教育公司做产品（小学业务），主业务是2019年比较热的在线教育班课，具有重运营，强KPI导向的特征。笔者从冷启动阶段加入产品团队，陪伴产品进入成长期，目前在业务上做大量尝试，产品迭代频率高，业务拓张速度快，很多问题亦随之出现。
　　业务组织背景
　　每条业务线都是一个敏捷团队，有着自己的核心指标及迭代节奏。
　　在公司层面，这种业务架构的优势是线内效率足够高，业务响应速度快，灵活度较高；缺点是跨线协作成本极高，各业务线之间诉求不一致，信息孤岛效应明显。
　　团队背景
　　产品研发设计数据运营是敏捷团队标配；笔者所处的产品团队3人，产品及研发比例稳定维持在1：6，随着业务发展，影响效率的明显变量：
　　1。团队：业务人员数量激增
　　半年内，业务团队从30人拓张至150人，意味着产品需要在业务人员的效能上提供支持。
　　2。业务：业务模型尚未调整至最优，需频繁做尝试
　　高频率的实验对团队的整体信息管理提出更高要求，大量的投放AB对照实验，产品每个迭代此类业务需求占需求总量的70。
　　问题发生的场景
　　团队内amp；amp；外日常协作
　　场景一：插入需求
　　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内部高层行政命令）等原因导致的需求插入amp；amp；变更，使得原有项目无法按时交付。
　　场景二：项目内部
　　偶发场景是某块资源的负责人因故（突发生病、离职等）无法按时交付原定的子任务，这时需要重新协调项目资源达成目标。
　　项目管理问题总结
　　在真实场景下，需求的变更往往会在资源分配层面构成蝴蝶效应，牵一发而动全身，现有的手段和工具只能让我们的项目相对透明，却没办法帮我们管理项目的风险。
　　团队现阶段使用的信息同步工具：
　　异常流程导致的资源二次分配，成本较高：
　　二次分配的成本往往比初次分配高，需要全盘权衡正在推进项目的优先级，还要兼顾现有的项目推进情况、资源状况。
　　项目风险管理困难：
　　在做二次决策的场景下，往往要求决策者在极短的时间内，做出一个低容错率的决策。这要求决策者对业务预期、资源分布、现有实现逻辑有全面了解。但作为项目的执行者，由于信息获取的成本较高，执行时往往很难在短时间内看到项目的全貌，这为项目的交付时间和质量埋下隐患。（理想场景下应该有高一个层级的人来做这一类型的决策；但现实场景下，项目风险往往都由执行者承担）
　　分析问题
　　抽象问题
　　无论是团队内部的信息同步、项目管理，亦或是对外的跨线合作，基于以上背景，笔者认为导致协作效率低的核心原因集中在三方面：
　　获取信息的成本高：我们往往先搞定人才能搞定事。
　　整合信息的成本高：我们需要将各个职能加工过的信息（每个人管理信息的习惯和水平都有所不同）拼凑起来，才能一窥需求全貌。
　　信息流失的风险高：想想那些离职的前辈们留下的祖传代码和祖传PRD，咱也不知道，咱也不敢问。
　　原因分析
　　获取信息成本高的原因：
　　职业分工垂直，不同职能间有信息鸿沟：同理心弥补不了专业上的信息差，和传统行业相比，互联网的专业分工纵深更深。
　　依赖个人的信息管理能力及沟通能力：人非圣贤，人一定会出错。在中小型团队中，产品写PRD、绘制原型的习惯不同；开发写代码的习惯也不同；很多公司的设计师没有统一的设计规范。依赖个人管理的信息一定会流失，这是可预期的。
　　流程的设置往往具备滞后性：和传统行业相比，互联网的拓张速度是无可比拟的，带来的问题是上升期的互联网公司往往无暇顾及管理，即使制订了流程也远远赶不上团队和业务拓张的速度。（见过部分公司将0管理和扁平管理划等号）
　　整合信息成本高的原因：
　　储存信息的节点分散（储存在个人的知识库中）。
　　信息总量边界不明，当做一个决策时，从初步假设到最终决策，往往随着接触到的人，获取到各式各样被主观加工过的信息，甚至在同一个问题上不同的人会给出完全相反，或模棱两可的结论。（笔者本身经验尚浅有关，理论上随着经验增加，对信息有效性的判断会更加客观）。
　　抛砖引玉
　　基于以上背景，相信你对我在工作的各个场景下碰到的问题已经有所了解。如何降低信息获取amp；amp；整合的成本？如何降低信息流失的风险？截至发文日，仍然没能找到可落地的解法。
　　产品经理虽然是理论上的脑力劳动者，但体力协作却占据了我们60以上的工作时间，我们距离真正的脑力协作还有很远的路要走。
　　大量琐碎的项目管理，沟通推进将我们的工作时间和价值感一起碎片化。
　　每日三省吾身：项目能否按时交付乎？决策质量是否提高乎？懂用户乎？
　　我能勉强回答第一个问题，但第二个和第三个问题却日夜煎熬着我，难以安眠。
　　不论你是和我一样的小白新人，还是项目经验丰富的前辈，如果我抛出的问题也同样困扰着你和你的团队，那么请和我坐下聊一聊，相信我们有机会解决这个行业问题。