产品学习笔记7—如何与程序员高效沟通

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/tangren03/article/details/51002745

目前在行业或者学术界,并没有一个系统化的产品经理培训体系,也就是说产品经理的学习和成长是一种粗放式的进阶路线。现今,产品经理分布在各行各业,而且在互联网逐渐普及的今天,产品经理一职越来越成为互联网公司的标配。相对之下,如今的产品经理大多是从其他职能转型过来,并不像一些传统专业,比如计算机,在大学就可以进行系统化的学习。而产品经理更多的是从开发转型、从设计转型或者从运营转型,或者也有很多从市场和销售转型。


在互联网公司中,产品经理们需要处理多方事物,与各种职能的人合作,比如与设计、业务、市场、销售、财务、开发,而在这些职能领域中,产品经理们打交道最多的莫过于程序员们了,有句打趣的话,说产品经理和程序员是上辈子的冤家,果真如此吗?其实不然,其实很多的冲突都是发生在沟通环节,相信大家都是为了一个共同目标要把事做好,但因为用了不同的语系,所以发生了沟通和理解的不一致,导致合作困难。


对于非技术型产品经理们,在平时工作中,产品经理的角色属于流程上游,而程序员的角色属于流程下游,也就是先设计再开发。实际的场景更多是产品经理苦思冥想设计出一个产品,然后信心满满的去找程序员沟通,而程序员看到设计第一反应是很难实现,而产品经理心里却是一团疑问,这么好的设计为什么很难实现。然后开始讨论,产品经理觉得这种设计能使用户体验很好,就算实现难一点也是值得的。程序员觉得不值得为了这一个点投入那么多的时间和精力开发,由此,双方各执一词,站在不同的利益角度上在沟通,可以想象,这样沟通的结果就是很难达成一致,好一点大家各退一步,坏一点就有可能形成争执。


基于上面这个问题,正确的沟通方式应该是怎样的呢?其实应该找到沟通背后各自的关注点。对于产品经理来说,满足业务需求和用户体验是核心关注点,但对于程序员来说,在开发量和时间成本的考虑下,简单可行的方案是其追求的目标,对于程序员来说,不重复发明轮子,实现高度复用是其关注点。所以当产品经理和程序员在沟通的过程中,双方的关注点不一样,但双方的关注点都是正确的。那如何平衡这种利害关系,对于产品经理来说,需要学会换一种思维沟通,也就是所谓的同理心。


作为程序员,脑海里装的是目前产品的实现模型,就好比建筑师看到一座自己设计的房子时,里面每一个细节都是了如指掌的,对于要动一下房屋结构,建筑师肯定知道牵一发而动全身的后果,在程序员看来,这是一样的道理,一个产品需求看似简单,但在微观实现层面,可能就是改一下房屋结构的效果,说的不好听,房子塌了谁负责呢。换个角度说,不是不能改,但是在一个简单需求的表面之下,隐含的可能是庞大的基础工作的修改,比如说涉及到底层架构和数据结构的更改。


作为产品经理,遇到这种问题时,该如何与程序员沟通呢,既能满足业务需求提升用户体验,也能降低实现成本。其实也很简单,产品经理在保持目标不变的情况下,需要权衡其中的利害关系,首先,在沟通中,需要用引导式的沟通方式与程序员进行沟通,很多时候,程序员会告诉你现在系统是怎么实现的,代码是怎么写的,哗哗出来很多技术术语,对于非技术背景的产品经理来说绝对是头大的,这时如果通过引导式和提问式的方式去沟通,首先让程序员也产生同理心,比如这个需求被满足后确实能让整体业务上一个台阶,能让用户体验得到极大改善,动之以情晓之以理,让沟通的双方看到一致目标,把不同的利益关注点合成一个,这时,对立沟通会转换为一致性沟通,产品经理和程序员会以共同目标为前提共同想办法寻求解决方案,以我的实际经验来看,更好的解决方案往往是在这种一致性目标沟通中产生的。


对于非技术型产品经理来说,工作中会遇到很多非自身专业领域内的问题,当遇到这些问题时,第一是别胆怯,首先找到核心关注点,然后寻找一致性沟通方案,以共同目标的方式去解决问题,将对立式沟通转变为一致性沟通,这样既能解决问题,也能让正确的事情持续发生。


Never let yourself regret


我是Ryan,前非著名移动开发者,现不知名产品经理,互联网医疗创业公司PM,我记录着我的记录,微信公众号:ryantang007

阅读更多
换一批

没有更多推荐了,返回首页