产品经理日常:撕逼并不能解决问题,和谐才是王道

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

你在和团队成员沟通的时候,是经常撕逼?还是和谐共处?一起来看看作者都给出了哪些建议。

产品经理在日常的工作过程中,与开发人员、测试人员、业务部门人员之间可能会有比较多的撕逼场景,比较容易起争执。如果公司内工作氛围好,可以做到对事不对人,吵过之后还能跟没发生过一样。

但毕竟这种情况说的容易,做起来还是比较难的——再怎么样,吵过一次的或多或少都会存在一些芥蒂。

如果通过撕逼能解决问题,那说明撕逼还是有价值的。最怕的就是撕完发现问题没有解决,还与同事之间产生了隔阂——大家天天在一个办公室里,抬头不见低头见的,真是有点得不偿失。

我比较奉行“讲道理”文化,这也是我在盛大网络工作时接触一种企业文化:不管职务高低,大家进入会议室之后都是平等的,把各自的观点阐述出来,谁有道理听谁的;相互之间实在无法相互说服的,找责任人来拍板,大家达成一致共识,问题也就解决了,很少出现争吵的情况。

有些人自带“火药桶”属性,一碰就着,肝火比较旺,一边的情绪上去之后,另一边也就很难控制了。

曾经我自己也是这样的,遇到事有时候会沉不住气。这些年产品做下来,逐渐的收敛了自己的心性,把解决问题放在第一位,把对错、输赢看的淡了,起争执的情况越来越少。

这里分享自己的一些心得,供广大产品经理小伙伴们参考。

一、明确需求,这是立身之本

产品经理首先要对你自己产出的需求负责,需求不明确,老是变来变去的,就不能怪开发和测试有情绪了。

需求明确是要确保你的PRD或者原型上的标注逻辑、条件、限制等各方面的约束和要求都是明确的,不能经常和开发、测试在沟通的过程中发现需求有遗漏、有考虑不周全的地方、有模棱两可的地方、有缺少交互说明的地方,偶尔一次两次大家都能接受,但如果经常性的有这样的问题,别人都要怀疑你的专业性了。

需求变更也要适度,如果变更的影响不太大的,尽量就安排到下个迭代去。实在需要变更的,要沟通清楚变更的意义、价值,要对所增加的工作量做适当的全局调整,安抚开发人员受到的小伤害,目的是让你的需求变更顺利实施下去。

二、学会和不同的人用不同的沟通方式

产品经理在与人沟通的时候不能老是坚持一套沟通方式,不同的人信息接收能力、理解能力不一样,性格、喜好各方面也不一样,都用同一种沟通方式去面对所有人的时候,不能完全确保对每个人都是有效的。

所以我们经常会看到一种现象,同样一个团队,部分人喜欢这个产品经理,部分人讨厌这个产品经理。这里头的差别就在于每个人的交际能力都是不一样的,一招鲜吃遍天的情况是很难出现在90后充斥的团队里了,大家都很有个性。

不要求产品经理八面玲珑,但至少要会随机应变,当发现你的沟通方式对某人无效的时候,尝试着改变自己。如果硬着来,对方不但拒绝接收你传达信息,还容易起争执。

永远记住一点:这个社会不可能按照你喜欢的样子来发展,只能你去适应这个社会。

三、提高信息传达的有效性

需求评审不是万能药,不可能靠一两次需求评审就达到让参与的所有人都理解一致的。需求评审只不过是一次你一对多的信息传达机会,至于对方接收的效果怎么样,每个人的情况都不太一样,所以在产品研发的过程中,经常出现需求理解偏差,导致做出来的功能不是你想要的。

所以过程跟踪就很有必要,不断的确认团队成员对需求的理解是否都是一致的,每天都需要确认有没有遇到问题,送测的功能第一时间体验,参与系统设计评审、测试用例评审,看看相关人员有没有理解偏差。

出现需求理解不一致的情况并不可怕,可怕的是二次需求确认沟通的时候还是不能达成一致,要提升有效性,可以用以下几种方式:

A、借助参照物来表达。有原型最好,没有原型的情况拿纸笔画一下,都比纯口头的沟通效果要好。很多时候讲半天对方都不理解,画一下对方1分钟就理解了。

B、举例说明。生硬的表述不如案例来的生动,不管是业务场景下的实例,还是举假设数据的例子,都比生硬的表述逻辑要求、条件限定来的更直接。

C、引导对方把顾虑和问题说出来。有些人比较内向、比较害羞,明明看到了问题,但碍于面子或各种原因,不愿意开口。或者他自己还不确定,不愿意说。这种情况下,一定要在团队里面营造简单、开放的工作氛围,多确认几次还有没有问题,有没有真正理解了。

D、复述确认。一些关键的点,如果你担心对方的理解程度,可以引导对方复述一遍,看他所表述的内容是否与你传达的一致,这是一种比较好的信息确认方式。

四、学会换位思考

产品经理不能只站在自己的立场上思考问题,你所要的和对方所要的是不一样的,因此你要学会换位思考。

当出现需求变更的时候,变多了,任何人都会不耐烦的。换成是你自己去开发,你肯定也会对需求经常变更而烦恼。很多时候业务部门提需求的时候不明确,或者经常变来变去,你做为产品经理也会不耐烦。

虽然都是整体产品研发链条上的团队,但各个角色的立场、出发点不同,就会造成很多认知是不一样的。如果一味的按照自身的要求来,不去考虑对方的感受,很可能就会让你的这次沟通无效。

五、认清沟通的目的

沟通的目的永远都是解决问题,而不是其他无关紧要的事情。对错、输赢都不重要,重要的是你要解决的问题有没有解决。非得去争个谁对谁错,换成谁都会有逆反心理的,拒不承认错误的情况时常有之,这对你要解决的问题一点帮助都没有。

你想让开发改功能,一定要说对方没有理解你的需求设计,或者说PRD上标注的很清楚,是对方没有仔细看。换成你自己是开发人员,你对别人指责你做错时候的第一反应是什么,肯定是找借口解释,一来二去就很容易争吵起来了。到最后你要改的功能也没改成,还得罪了开发人员,一点用都没有。

你首先要做的是让对方接受功能的修改,讲清楚业务逻辑、业务场景、更改的原因、实现后的表现等等,讲道理人谁都喜欢的,最怕的都是蛮横不讲理的人。

六、需求有延误的情况下要做取舍

实在出现迭代里安排的需求点做不完的情况下,要学会取舍,尽量确保核心功能点能顺利上线。

一是要做好需求的优先级设定。写PRD的时候一定要明确各个需求功能点的优先级,确保最高优先级的功能先做,这样能保证核心功能点能顺利上线。

二是要做好过程跟踪。及早发现需求可能会延期的情况,要么协调资源安排加班,要么调整迭代内需求的数量。要延期的情况发现的早,调整的空间就大,发现的晚了,很多措施就失效了。

七、一定要控制住情绪

冲动是魔鬼,这话一点都不假。在工作过程中,和同事拍桌子、翻脸吵架等情况尽量不要发生,大家都是同事,日常的相处还是要和谐为主。同事不一定要变成朋友,但必须保证同事的关系能够维持下去,不然工作就没法开展了。

闹翻了的情况即便换成是你和你的好朋友,也会不愉快很长时间,何况是同事之间。发火对事情的处理一点帮助都没有,反而会增加难度。事后还得去找人家道歉,多尴尬,还不如一开始的时候就控制住情绪。

八、学会复盘总结

每个迭代结束之后,产品经理一定要总结一下这个迭代当中出现的问题。哪些是需求理解上的问题,哪些是需求描述上的问题,哪些是沟通上的问题等等,复盘总结过之后要改正,这样后续的迭代中就能减少问题的出现。

如果你一直我行我素,按照固有的方式去开展每个迭代的工作,对你自己的能力提升没有帮助不说,还会让团队觉得你是一个老犯错误的产品经理。把容易出现错误的地方一个个的避免掉,会让后续的迭代越来越轻松。

以上是个人总结的一些经验之谈,不一定适合所有的产品经理,但这些方式方法应该都是通用的。这些问题也是我自己在带产品团队的时候发现的,相信很多产品新人应该都会有类似的问题。

与团队成员吵架并不能解决问题,反而会暴露出你的不成熟、你的不专业。产品经理要成为整个团队的润滑剂,只有当你把团队能很好的捏合在一起了,才能实现你的价值。

产品经理的成就感来源于产品被用户所认可,前提是你所设计的功能能够顺利的按照设计方案的要求上线,否则用户根本都接触不到,也就没什么成就感可言了。所以撕逼并不能解决问题,和谐才是王道!

#专栏作家#

华仔,微信公众号:zeropm,人人都是产品经理专栏作家。历任阿里巴巴、1号店、盛大网络资深产品经理,现任美平米电商产品产品总监,合著有《运营前线》、《产品前线》、《互联网产品之美》,译著有《人人点赞:让APP瞬间疯转的绝妙文案》。11年产品经理工作经验,专注于在线教育和电商产品方向。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash ,基于 CC0 协议

评论
欢迎留言讨论~!
  1. :o 受教了~思路很清晰~学习了~~

    回复
圈子
关注微信公众号
大家都在问