产品经理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。请问实际工作中是否验证过这个时间比?
认真看了半天,分析的挺有道理,最后没有解决方案······
写得挺好的。“祖传代码”太幽默了,忍不住会心一笑。我觉得PM作为产品信息的枢纽,沟通协调的工作是不可避免的,但可以想办法提高一点效率。比如在沟通协调过程中,把碎片信息记录下来,并分析整理成为自己的知识图谱的一部分,再之后遇到相关的问题就可以快速找到关键人、解决关键问题。长此以往,你对自己产品线的产品,甚至整个公司的业务都能有一个更全面的解,到那时你在公司内的认知水平也将高出一般人的水平。升职加薪走上人生巅峰——这个还是得看运气哈 🙂 ,但还是能收获不少的成就感的。
还是厉害,这么个问题都说的这么高大上,给你个建议,找具体负责人去沟通。
看了半天只说了问题所在,没有说怎么解决
有假设的解法,但是还没有验证有效,完成初步验证后会再就解法写一篇。希望可以确认在和我一样1-3年的初级产品是否碰到类似的问题,感兴趣可以深聊哦~
你说的情况都是无法避免的,体力协作必然要占用我们这么多时间。我用的方法是经量把各种体力协作安排地紧凑,中间经量不要有碎片时间,挤出时间,每天至少安排一小时完整的时间,思考产品方向。可能的话再挤出半个小时到一个小时学习线上各位大佬的经验
头痛+1
有假设的解法,但是还没有验证有效,完成初步验证后会再就解法写一篇。希望可以确认在和我一样1-3年的初级产品是否碰到类似的问题,感兴趣可以深聊哦~
➡ 竟然没有提供解决方案
是的呢 ,方案呢 😐
希望可以和碰到类似问题的同学交流,wechat:ZBC19950305请备注人人,base北京,节假日可面基~
也面临这种问题 以为能获得经验 原来是抛砖引玉
有假设的解法,但是还没有验证有效,完成初步验证后会再就解法写一篇。希望可以确认在和我一样1-3年的初级产品是否碰到类似的问题,感兴趣可以深聊哦~
哈哈哈