腾讯大佬教我的工作方法(非常有效!)

最近越来越发现一个问题——“感觉团队的产品小伙伴都不太会工作”。主要表现在效果和工作时长完全成反比。天天加班到晚上10点,然后产出的结果……。(PS:偶尔摸鱼是肯定的,也没有怎么偷懒)其实就是工作方法的问题。其中需要记住一点:工作方法肯定能影响到工作能力

我做事的方式是刚入职场时,向几位腾讯的大佬请教后,自己边工作边整理的。(PS:方法肯定是对你有效的……)

一、产出一定有结果和目标

小伙伴A在周会上汇报工作时,从业务侧需求的沟通到需求的二次澄清,从立项到项目上线。最后在目标和结果产生的表现时,说——没有达到预期。问接下来是否有对应的解决方案时,说——暂时没有思考到。

后来才发现这并不是个例。而是大部分产品经理在工作时都会遇到的问题。没有结果的产出,过程再华丽只能作为复盘会的反思。

但是反思过后呢?一定要伴随着结果和目标。John一般是这么做的:

在梳理产品的过程中,这版本迭代需要在什么时间达到怎样的目标?——如果是业务侧活动类型(短期)的需求,需要同步业务侧制定运营计划(计划一定要伴随方案和目标),根据运营计划做产品迭代(用一次性解决方案还是做成可配置的常规解决方案?);如果是产品规划(长期)需求,提前想好这个模块的迭代计划(通过产品路线图展示出来),和其他模块是否有衔接点?以及如何协同?

如下图所示:

如果不能达到目标,解决方案是怎么样?——未尝胜先思败。想好后路很重要,版本的每次迭代都有三个deadline:需求澄清最后期限,产品评审最后期限和产品上线最后期限。当业务侧提出活动类型需求,产品经理要和业务方沟通清楚没有达到目标的补救方案是什么?(PS:如果没有,让业务方梳理清楚了再沟通);如果是产品规划需求,尤其是在需求澄清最后限期没有思考清楚,那就给版本做减法,快速评审(评审如果都搞不定,那……)并跟进项目直至上线。

如下图所示:

二、方向永远比执行重要

小伙伴B做事非常快,往往今天开完版本沟通会,两天后原型就已经梳理大半了。在版本确认会上,对自己所梳理的方案和结论自信满满。然而,实际上在沟通过程中,其他小伙伴都有更好的解决方案和想法。久而久之,感觉自己真真正正地变成了“执行机器”。

John这儿强调的重点:执行都是搬砖的活(花一定的时间就行),而方向对了,搬砖都是很顺利的。

John一般是这么做的:

在版本沟通会上,把涉及到这版本的功能清单梳理清楚,同时也要把和模块有协同的模块梳理清楚。梳理清楚等待版本确认会上沟通……

比如在电商产品做积分商城时,除了把获取积分和消耗积分的点列出来,还要考虑积分的期限和积分后续是否可以抵扣现金(防止通货膨胀),其中消耗积分有没有兑换中心?兑换的流程是怎么样的?可不可以退货?等等。

如果没有想到对应的解决方案,咱去看看竞品,试着去拆一拆,他们是怎么做的?分成了几个版本?把竞品的功能清单和流程梳理出来。一起讨论讨论是否能被我们借鉴。

在准备方案的过程中,一定要反问几个问题:

  • 还有没有其他更好的方案?(最好的办法是找运营模拟下用户流程)
  • 这个方案还需要补充什么?(试着把业务路径和用户路径梳理出来)
  • 在这个方案中,每个环节有几条出口?我该怎么引导用户一步步走下去?(大致的功能流程图梳理清晰)
  • 让业务方的小伙伴模拟后,提出他们的问题。(业务侧这一点时间还是有的,尽情的可以去打扰他们,哈哈哈)

通过一张图整理下:

只要梳理清楚了,把这套方案拿到需求确认会上,我相信起码会给其他小伙伴一些感想。后续再去梳理细节点,这岂不是很清晰?

三、受众永远是第一位的

针对于产品本身来说,首先考虑的是用户的利益。(当然是在用户合法得到的基础上)但是产品经理在工作过程中,这儿的用户就变成了受众,受众可以是你的用户、同事、老板。因为产品经理会接收到来自各方的需求,但是和各方的沟通不能用同一种沟通方式:

面对你的用户:你应该以保障他们利益优先,教他们一步步如何操作,给他们参与感和获得感;

面对你的同事:先聆听并问清楚后,再梳理出自己的建议,因为找你沟通肯定是和你有关系的;

面对你的老板:拿出有效的数据来佐证自己的方案和框架,不必过多地强调细节,当然到达的结果一定要可行并且有条理。

因为我感受很深的是小伙伴C拿着需求池和老板碰接下来的规划。导致老板以为产品规划的方向发生了偏差。

John这边一般是这么做的:

  • 这次结果产出的受众是谁?
  • TA最重要紧急的是什么?
  • 我拟定的方案能否满足TA?
  • 我的方案的可行性有多大?执行难度大不大?

通过这四步面对不同的受众应该拿出不同的方案。面对用户展示的是产品经理的细节梳理能力;面对同事展示的是产品经理的产品梳理能力;面对老板展示的是产品经理的产品规划能力。

四、团队协作才能高效工作

小伙伴D能力比较强,所有的事情都想着一手承担,总觉得UI设计没有达标,运营方案不够落地。导致项目组的小伙伴都对他有想法,渐渐地感觉他被孤立了一样。(这是我们之前团队的小伙伴)

John这儿也想强调一点:无论能力多强的人,也是需要团队协作的,因为有更重要的事情在等你。何况你能力并没有这么强!

专业的事情一定要交给专业的人去做。和专业的人配合时,你一定要明白:

  • 你能比UI设计师更懂设计规范和设计趋势么?
  • 你能比技术更清楚如何实现这个功能么?
  • 你能比运营更明白运营策略么?

如果不能,你只是提出意见方,可以和他们沟通并说出你的建议和理由。John一般是这么梳理的:

  • 这个模块,可能需要涉及到和哪些人协同?(心里可以圈定人选,然后找到对应协同职能的负责人,和他们说清楚模块规划,接着就是要人了)
  • 需要准备哪些资料给到协同人?(把对应的资料梳理,用落地的方案整理出来)
  • 接下来就是做实时的对接。(敲定时间节点并以会议的形式沟通)

当你成为某个项目负责人后,你就知道团队协作有多重要。但是前期是要用项目成员的语言去沟通,有效的建议很重要,通过权力干预往往会适得其反。(现在你是我老大,也许下一次我就翻身做主人了。)

五、凡事有交代,件件有着落,事事有回音

不知道你们有没有这样的感受,开会时都讲得好好的(PS:尤其是开大会的时候),然后会后还是各回各家。

这种情况下超级可怕,实际上会导致会后沟通成本超级高,并且与会人没有安全感。是谁的工作范围,就应该优先去解决。交代了的事情就需要去落实,完成后应该给予交代人反馈。

这个是所有职场人需要执行的。否则,你给予别人的安全感会越来越少。

以上只是John简单的总结分享,当然落地更重要。与其我们不断要求别人,首先更应该规范自己的工作。

本文完。记得三连哟!


(0)

相关推荐