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

19 评论 14686 浏览 63 收藏 14 分钟

据不完全统计,笔者在工作中约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%以上的工作时间,我们距离真正的“脑力协作”还有很远的路要走。

大量琐碎的项目管理,沟通推进将我们的工作时间和价值感一起碎片化。

每日三省吾身:“项目能否按时交付乎?决策质量是否提高乎?懂用户乎?”

我能勉强回答第一个问题,但第二个和第三个问题却日夜煎熬着我,难以安眠。

不论你是和我一样的小白新人,还是项目经验丰富的前辈,如果我抛出的问题也同样困扰着你和你的团队,那么请和我坐下聊一聊,相信我们有机会解决这个行业问题。

 

本文由 @ 大北 原创首发于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 这个抽象挺好的

    来自北京 回复
  2. 笔者所在的公司以及团队环境,实在是太南了,现在很多PM所烦恼的通病;
    1、多数存在于小型、分散式团队,以及重业务类型公司;
    2、要想解决根本问题,达到笔者所说的“PM做脑力劳动”的效果,还是得从公司层面、领导层面来推动;
    3、其次笔者这种环境,一般都是直接找技术负责人、或相应项目的负责人来沟通和协调比较好,让负责人自己去传达给自己的下属团队;
    4、要想达到实际解决效果,除了自己学会着去安排、积极沟通和推动外,就是公司或领导层面提供协助解决;

    来自广东 回复
  3. 总结的挺到位的,实际场景不同但是很多产品经理都遇到相似的问题。
    个人觉得
    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:其实很多还是根据企业结构,内部人员关系。采用不同的方式。没什么固定的套路。
    合适的就是最有效的。

    来自四川 回复
    1. 前2点,挺科学

      来自北京 回复
    2. 新需求、优化功能,数量上占比2:8,工期(或工时)上占比6:4。请问实际工作中是否验证过这个时间比?

      来自上海 回复
  4. 认真看了半天,分析的挺有道理,最后没有解决方案······

    来自北京 回复
  5. 写得挺好的。“祖传代码”太幽默了,忍不住会心一笑。我觉得PM作为产品信息的枢纽,沟通协调的工作是不可避免的,但可以想办法提高一点效率。比如在沟通协调过程中,把碎片信息记录下来,并分析整理成为自己的知识图谱的一部分,再之后遇到相关的问题就可以快速找到关键人、解决关键问题。长此以往,你对自己产品线的产品,甚至整个公司的业务都能有一个更全面的解,到那时你在公司内的认知水平也将高出一般人的水平。升职加薪走上人生巅峰——这个还是得看运气哈 🙂 ,但还是能收获不少的成就感的。

    来自北京 回复
  6. 还是厉害,这么个问题都说的这么高大上,给你个建议,找具体负责人去沟通。

    来自广东 回复
  7. 看了半天只说了问题所在,没有说怎么解决

    来自四川 回复
    1. 有假设的解法,但是还没有验证有效,完成初步验证后会再就解法写一篇。希望可以确认在和我一样1-3年的初级产品是否碰到类似的问题,感兴趣可以深聊哦~

      来自北京 回复
  8. 你说的情况都是无法避免的,体力协作必然要占用我们这么多时间。我用的方法是经量把各种体力协作安排地紧凑,中间经量不要有碎片时间,挤出时间,每天至少安排一小时完整的时间,思考产品方向。可能的话再挤出半个小时到一个小时学习线上各位大佬的经验

    来自浙江 回复
  9. 头痛+1

    来自广东 回复
    1. 有假设的解法,但是还没有验证有效,完成初步验证后会再就解法写一篇。希望可以确认在和我一样1-3年的初级产品是否碰到类似的问题,感兴趣可以深聊哦~

      来自北京 回复
  10. ➡ 竟然没有提供解决方案

    来自广东 回复
    1. 是的呢 ,方案呢 😐

      来自吉林 回复
  11. 希望可以和碰到类似问题的同学交流,wechat:ZBC19950305请备注人人,base北京,节假日可面基~

    来自北京 回复
    1. 也面临这种问题 以为能获得经验 原来是抛砖引玉

      回复
    2. 有假设的解法,但是还没有验证有效,完成初步验证后会再就解法写一篇。希望可以确认在和我一样1-3年的初级产品是否碰到类似的问题,感兴趣可以深聊哦~

      来自北京 回复
    3. 哈哈哈

      来自吉林 回复