产品经理需要更多的了解非技术层面的知识,与研发沟通的能力就是其中一项。作为"没有什么技术含量,人人都可以做"的产品经理来说,沟通能力才是最核心的价值。 我是Rookie Chan,"产品+运营"的混合岗,最近刚有的打算,把自己的工作心得,不定期的做个记录,分享&受教。 付诸行动的第一天,写的主题却是:关系最好的研发离职,对产品经理的影响。就在刚刚,公司的资深PHP工程师跟老大在"小黑屋"聊了好久,出来后老大官宣了这个噩耗:小哥要自己创业去了。 当然了,小山头我是不提倡的,所谓关系最好,翻译一下:沟通成本最低。 看过很多调侃产品和研发势不两立的段子,也亲身经历过面红耳赤的唇枪舌剑,不得不说都是讲求效率的人,时间都花在了沟通上。 这里所说的沟通成本,其实是基于一定的经验之上,对产品设计的理解去除一些基本层面的确定,直接对核心的功能和交互的实现进行探讨。评审项目过需求时,各端的配合都要抠细节来确认,产品经理和研发工程师往往会从进会议室的第一刻起,就在内心有了些抵触情绪。 搞好关系也是对自己的一种能力提升,不是说一起团建吃顿饭那么简单。 首先,产品经理需要更多的了解技术层面的知识,自己提的需求实现难度有个大致的评估。 当然了,现在去学代码转研发,一是要本人有勇气吃得了苦,二是要家里有矿捱得过积累经验的初级阶段。我都不符合,所以这里说的是了解自己的研发兄弟们的一些工作习惯。 比如用的什么软件,接的什么sdk,有什么好的数据分析产品等等,我们确实需要把控甚至"压迫"一下进度,但要有理有据,被回怼时也有底气,从容的继续"压迫"。 其次,研发小哥的思维逻辑和产品运营的思维逻辑是有差异的,但是本质上又有着相通的部分。 用这一部分作为切入点协调,这块主要是在需求文档里体现。 网上有很多调侃研发的段子,说做研发的小哥哥们都有比较木讷,没啥人情味,沟通起来比较难。对此我不敢苟同,研发都有了一定的经验,也多少了解些每个产品经理的工作逻辑,每天都是那些代码确实索然无味。 尤其有的时候他们辛苦做出来的东西,没过多久就不去使用或者运营了,谁都喜欢自己做的东西被认可,但他们被认可的点可能由我们来决定。 再次,说研发听得懂、愿意听的话。 想节省沟通成本,往往不能做到两者都同时各自退让,从我做起还是可以实现的,根据之前的一些交流熟悉每个研发小哥的调调,其实产品经理也算半个心理学家了。 经常挂在嘴边的用户体验,可以把研发也当作用户,出个用户画像,弄个A/B测试,做个版本迭代,如果这样跟研发还有矛盾,那产品经理要好好反思了。 最后,如果产品本身设计的确实槽点一堆,那么衷心的建议不要去麻烦研发。 不是说皮厚没关系,你浪费了大家的时间。我也要面子的啊,不希望自己的产品被各种删改需求,就是确定要这么做,为了达到目的,我可以一直对你笑。(last but not least) 写在结尾:关系最好的研发小哥离职,对产品经理的影响……没有影响!换一个人换一种沟通方式,作为"没有什么技术含量,人人都可以做的"产品经理来说,沟通能力才是最核心的价值,祝大家工作顺利,祝创业去的研发小哥商祺。