时间: 2021-07-30 09:51:49 人气: 4 评论: 0
你在和团队成员沟通的时候，是经常撕逼？还是和谐共处？一起来看看作者都给出了哪些建议。
产品经理在日常的工作过程中，与开发人员、测试人员、业务部门人员之间可能**有比较多的撕逼场景，比较容易起争执。如果公司内工作氛围好，可以做到对事不对人，吵过之后还能跟没发生过一样。
但毕竟这种情况说的容易，做起来还是比较难的——再怎么样，吵过一次的或多或少都**存在一些芥蒂。
如果通过撕逼能解决问题，那说明撕逼还是有价值的。最怕的就是撕完发现问题没有解决，还与同事之间产生了隔阂——大家天天在一个办公室里，抬头不见低头见的，真是有点得不偿失。
我比较奉行“讲道理”文化，这也是我在盛大网络工作时接触一种企业文化：不管职务高低，大家进入**议室之后都是平等的，把各自的观点阐述出来，谁有道理听谁的；相互之间实在无法相互说服的，找责任人来拍板，大家达成一致共识，问题也就解决了，很少出现争吵的情况。
有些人自带“火药桶”属性，一碰就着，肝火比较旺，一边的情绪上去之后，另一边也就很难控制了。
曾经我自己也是这样的，遇到事有时候**沉不住气。这些年产品做下来，逐渐的收敛了自己的心性，把解决问题放在第一位，把对错、输赢看的淡了，起争执的情况越来越少。
这里分享自己的一些心得，供广大产品经理小伙伴们参考。
产品经理首先要对你自己产出的需求负责，需求不明确，老是变来变去的，就不能怪开发和测试有情绪了。
需求明确是要确保你的PRD或者原型上的标注逻辑、条件、限制等各方面的约束和要求都是明确的，不能经常和开发、测试在沟通的过程中发现需求有遗漏、有考虑不周全的地方、有模棱两可的地方、有缺少交互说明的地方，偶尔一次两次大家都能接受，但如果经常性的有这样的问题，别人都要怀疑你的专业性了。
需求变更也要适度，如果变更的影响不太大的，尽量就安排到下个迭代去。实在需要变更的，要沟通清楚变更的意义、价值，要对所增加的工作量做适当的全局调整，安抚开发人员受到的小伤害，目的是让你的需求变更顺利实施下去。
产品经理在与人沟通的时候不能老是坚持一套沟通方式，不同的人信息接收能力、理解能力不一样，性格、喜好各方面也不一样，都用同一种沟通方式去面对所有人的时候，不能完全确保对每个人都是有效的。
所以我们经常**看到一种现象，同样一个团队，部分人喜欢这个产品经理，部分人讨厌这个产品经理。这里头的差别就在于每个人的交际能力都是不一样的，一招鲜吃遍天的情况是很难出现在90后充斥的团队里了，大家都很有个性。
不要求产品经理八面玲珑，但至少要**随机应变，当发现你的沟通方式对某人无效的时候，尝试着改变自己。如果硬着来，对方不但拒绝接收你传达信息，还容易起争执。
永远记住一点：这个社**不可能按照你喜欢的样子来发展，只能你去适应这个社**。
需求评审不是万能药，不可能靠一两次需求评审就达到让参与的所有人都理解一致的。需求评审只不过是一次你一对多的信息传达机**，至于对方接收的效果怎么样，每个人的情况都不太一样，所以在产品研发的过程中，经常出现需求理解偏差，导致做出来的功能不是你想要的。
所以过程跟踪就很有必要，不断的确认团队成员对需求的理解是否都是一致的，每天都需要确认有没有遇到问题，送测的功能第一时间体验，参与系统设计评审、测试用例评审，看看相关人员有没有理解偏差。
出现需求理解不一致的情况并不可怕，可怕的是二次需求确认沟通的时候还是不能达成一致，要提升有效性，可以用以下几种方式：
A、借助参照物来表达。有原型最好，没有原型的情况拿纸笔画一下，都比纯口头的沟通效果要好。很多时候讲半天对方都不理解，画一下对方1分钟就理解了。
B、举例说明。生硬的表述不如案例来的生动，不管是业务场景下的实例，还是举假设数据的例子，都比生硬的表述逻辑要求、条件限定来的更直接。
C、引导对方把顾虑和问题说出来。有些人比较内向、比较害羞，明明看到了问题，但碍于面子或各种原因，不愿意开口。或者他自己还不确定，不愿意说。这种情况下，一定要在团队里面营造简单、开放的工作氛围，多确认几次还有没有问题，有没有真正理解了。
D、复述确认。一些关键的点，如果你担心对方的理解程度，可以引导对方复述一遍，看他所表述的内容是否与你传达的一致，这是一种比较好的信息确认方式。
产品经理不能只站在自己的立场上思考问题，你所要的和对方所要的是不一样的，因此你要学**换位思考。
当出现需求变更的时候，变多了，任何人都**不耐烦的。换成是你自己去开发，你肯定也**对需求经常变更而烦恼。很多时候业务部门提需求的时候不明确，或者经常变来变去，你做为产品经理也**不耐烦。
虽然都是整体产品研发链条上的团队，但各个角色的立场、出发点不同，就**造成很多认知是不一样的。如果一味的按照自身的要求来，不去考虑对方的感受，很可能就**让你的这次沟通无效。
沟通的目的永远都是解决问题，而不是其他无关紧要的事情。对错、输赢都不重要，重要的是你要解决的问题有没有解决。非得去争个谁对谁错，换成谁都**有逆反心理的，拒不承认错误的情况时常有之，这对你要解决的问题一点帮助都没有。
你想让开发改功能，一定要说对方没有理解你的需求设计，或者说PRD上标注的很清楚，是对方没有仔细看。换成你自己是开发人员，你对别人指责你做错时候的第一反应是什么，肯定是找借口解释，一来二去就很容易争吵起来了。到最后你要改的功能也没改成，还得罪了开发人员，一点用都没有。
你首先要做的是让对方接受功能的修改，讲清楚业务逻辑、业务场景、更改的原因、实现后的表现等等，讲道理人谁都喜欢的，最怕的都是蛮横不讲理的人。
实在出现迭代里安排的需求点做不完的情况下，要学**取舍，尽量确保核心功能点能顺利上线。
一是要做好需求的优先级设定。写PRD的时候一定要明确各个需求功能点的优先级，确保最高优先级的功能先做，这样能保证核心功能点能顺利上线。
二是要做好过程跟踪。及早发现需求可能**延期的情况，要么协调资源安排加班，要么调整迭代内需求的数量。要延期的情况发现的早，调整的空间就大，发现的晚了，很多措施就失效了。
冲动是魔鬼，这话一点都不假。在工作过程中，和同事拍桌子、翻脸吵架等情况尽量不要发生，大家都是同事，日常的相处还是要和谐为主。同事不一定要变成朋友，但必须保证同事的关系能够维持下去，不然工作就没法开展了。
闹翻了的情况即便换成是你和你的好朋友，也**不愉快很长时间，何况是同事之间。发火对事情的处理一点帮助都没有，反而**增加难度。事后还得去找人家道歉，多尴尬，还不如一开始的时候就控制住情绪。
每个迭代结束之后，产品经理一定要总结一下这个迭代当中出现的问题。哪些是需求理解上的问题，哪些是需求描述上的问题，哪些是沟通上的问题等等，复**总结过之后要改正，这样后续的迭代中就能减少问题的出现。
如果你一直我行我素，按照固有的方式去开展每个迭代的工作，对你自己的能力提升没有帮助不说，还**让团队觉得你是一个老犯错误的产品经理。把容易出现错误的地方一个个的避免掉，**让后续的迭代越来越轻松。
以上是个人总结的一些经验之谈，不一定适合所有的产品经理，但这些方式方法应该都是通用的。这些问题也是我自己在带产品团队的时候发现的，相信很多产品新人应该都**有类似的问题。
与团队成员吵架并不能解决问题，反而**暴露出你的不成熟、你的不专业。产品经理要成为整个团队的润滑剂，只有当你把团队能很好的捏合在一起了，才能实现你的价值。
产品经理的成就感来源于产品被用户所认可，前提是你所设计的功能能够顺利的按照设计方案的要求上线，否则用户根本都接触不到，也就没什么成就感可言了。所以撕逼并不能解决问题，和谐才是王道！
华仔，微信公众号：zeropm，人人都是产品经理专栏作家。历任阿里巴巴、1号店、盛大网络资深产品经理，现任美平米电商产品产品总监，合著有《运营前线》、《产品前线》、《互联网产品之美》，译著有《人人点**：让APP瞬间疯转的绝妙文案》。11年产品经理工作经验，专注于在线教育和电商产品方向。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash ，基于 CC0 协议
