怎样成为一名受RD欢迎的PM

jopen 10年前

作者:翟路佳

  如今,RD(研发)和 PM(产品经理)之间的矛盾与协作,时常成为互联网行业里的热门话题。PM 方面文科出身偏感性的居多,时常看到他们分享经验(RD 一般直接骂 PM 是傻X),但考虑到他们的知识体系和思维习惯,这些分享大多没啥营养,缺少参考价值。

  我从入行起就做一线开发,而且是前端,离用户近,工作大多围绕界面、交互进行。创业这两年挂职“产品总监”,做产品经理的同时也在做开发,自己给自己提需求。接下来,由我来告诉你,怎样成为一名受 RD 欢迎的 PM。

  告别愚蠢

  很多 PM 的最大问题是愚蠢而不自知。

  就目前来看,RD 多是科班出身,受过系统的计算机相关知识和技能培训(包括学校和自发),头脑清晰逻辑缜密,平时多半有点宅,人机交互甚至多余与人交互;而产品经理则是三 教九流各色人等都有,知识技能工具也缺少统一标准。这种情况下,RD 有些优越感再正常不过。总结起来,初始状态下,RD 眼中,PM 是这样的:

  • 学习成绩、学习能力、学习习惯都有问题,唯独嘴炮很厉害
  • 用(移动互联网)产品的时候还不如我多(宅么……),竞品观察的还不如我细(要抄的这个产品我用大半年了)
  • 假传圣旨狐假虎威

  偏偏很多 PM 还特别喜欢用“我觉得……”这种句式跟 RD 交流,遇到挑战往往也没法拿出数据、竞品设计进一步讨论,只能说“总会有人……”“像我这样……”,甚至继续“我觉得……”。他们忽视了一个问题:大家的 命运都和产品息息相关。RD 对产品的关注程度,倾注的情感,并不比 PM 少。RD 对产品的期望,也不比 PM 低。这个时候,如果 PM 拿来的一份说不清好坏甚至脑残设计,那被抵制或消极对待就是自然而然了。

  如何才能不让自己显得愚蠢呢?其实也不复杂。

  • 多用竞品,多用互联网产品。没办法,吃这碗饭,就得有投入。时刻了解界面交互的新潮流新尝试。
  • 能找到数据,尽量多用数据。
  • 除了直接合作的 RD 以外,争取交几个 RD 朋友,提需求之前,请他们先帮忙评估下开发成本,再去跟自己的 RD 沟通时会有准备的多。

  PM 一定要树立自己的专业性权威性,要让 RD 相信,这个需求是有利的,是有效的,是可以给自己带来奖金的,那么积极配合就是水到渠成的事儿了。

  理解 RD

  每个人都有自己的小确幸,RD 自然也不例外。

  可能是用某种模式巧妙地重构了代码,使之清晰好读便于扩展;

  可能是妙笔偶得的正则,效率比以往提升了数倍;

  可能是学会一个新技术找到一个新框架……

  理解 RD,就是理解他们在发现身边的小确幸之后,给予他们足够的空间去满足。比如,不要把项目进度填得太满;或者适当调整功能需求,把 RD 自发提出的需求加进来。

  另外一种温柔理解,就是不打扰。有些 PM 控制欲较强或者项目出身,热衷于“对进度”,简直愚蠢到令人发指——你对不对进度,进度就在这里,不进不退。程序开发不是线性的,不是每小时 12.5%,一天 8 小时 100%;也不是写了 200 行,再写 200 行就完成了;甚至我都没办法告诉你我做了多少,还要多少时间才能做完。有些 PM 更是不知道从哪儿喝的过期鸡汤,竟然认为只要够坚持够忍耐,坚持询问耐心询问,就能和 RD 在对进度这件事上达成共识——这除了让 RD 确信 ta 是个无可救药的蠢材之外别无它用。

  最后的理解,就是“PM 动动嘴,RD 跑断腿”了。能理解这一点,其它也都好理解了。任何需求都有开发成本,这个开发成本,往往连同是 RD 的其他人都无法准确估测,更何况缺少技术背景的 PM。所以很多 PM 提需求提得很随意,明显没有经过深思熟虑(或者明显没有和更高阶的 PM 进行讨论,或者没有和其它需求方确认);改得更随意,而且常常伴着一句:“你就那个那个啥一下,很简单。”坦白告诉你,听到这句话 RD 没拿出刀砍死你说明他爱你。想改善的话,开工之前多沟通,降低返工可能性;提出需求时尊重 RD 的判断,共同拟定阶段性目标;开工后尽力维持计划,等等。

  理解 RD 的 PM,真的好迷人。

  避免误区

  第一个误区是打嘴炮。

  为了写这篇文章,我简单 google 了下“产品经理自我修养”,搜出来一堆心灵鸡汤。这些文章几乎可以作为产品经理“假大空”的代表,正是这些文章误导了很多初入行的新人。

  作为有必要时常和 RD 打交道的 PM,一定要务实,想法要落地,提出的东西要有具体执行细节,有考量标准。不能满嘴跑火车,动不动战略布局就,动不动就拽名词(“破坏式创新”),动不动 就引名言。我们的目的既简单又统一,把产品做好,把运营做好,提升用户体验,抓住用户,增加活跃用户,最终流量变现,大家分钱。这之间,需要的是一个又一 个具体的需求,一点又一点持续的改进,合理规划的统计点,用数据支撑的每步选择。而且前面说过,RD 可能嘴笨,其实很聪明,并且有点优越感,PM 拿不出真材实料只靠嘴炮很快就被归到不靠谱那类了。

  第二个误区是想说咱俩是一伙儿的结果表述错误。

  常见于老板或者某领导提了个不咋样的需求,交给 PM,PM 劝 RD:“我也不想的,可是老板他非要。”前面说过了,PM 动动嘴,RD 跑断腿,最后开发成本要 RD 扛,所以你说服不了老板,苦果得我吃。所以你嘴上想说咱俩是一伙儿的,其实你正在出卖我……正确的做法是先尝试说服领导或者老板,如果无法做到,就试着理 解老板的意思,用道理说服 RD,同时及时修正项目进度。

  总结

  其实 PM 和 RD 不是仇人,相反,二者的切身利益息息相关。PM 希望找到给力 RD 的同时,无数 RD 也在期盼上天赐予一个靠谱的 PM。RD 不善表达的居多,也懒得跟“外行人”废话,所以常常只表现出对 PM 很冷淡甚至敌视。其实他们并不是不愿意做功能或者不接受改需求,只是需要一些更说的过去的理由而已。

  获取 RD 信任之后会发现他们都很好相处,而只要做到以上几点,受到 RD 们欢迎也是必然的。