|
Note：写于2015年7月9日，整理于2017年2月12日清晨。本文是我早期于简书发表的文章，语言文字难免显得有些生涩，不过确实是一个产品经理梦想开始的地方，谁又曾想到这一坚持就是两年！  有效的沟通是一切工作的基础！很多朋友都强调沟通的重要性，不仅是因为沟通本身确实很重要，还因为这一路踩过了数不尽的坑，经历的辛酸苦楚，简直就是一把辛酸泪。沟通只是一种手段，而不是目的，沟通的本质是要解决问题，关键是要在身处撕逼、纠结、矛盾的处境下，依旧能保持一份良好的心境心态/心情。 两点要义：要点一：好心情是沟通环节的基础保证，谁愿意看到一张[人人都欠TA钱]的臭脸？ 要点二：好心情才有可能活得更久，才能有时间做一些自己喜欢做的事情。谁会嫌命长？ 工作、生活，开心就好！ 这段时间感触颇深，产品V2.0新版上线本该是件令人高兴的事情，可随之而来的不是赞誉，不是鲜花，更不是心心相念的项目奖金。等待你的只有无尽的撕逼/吐槽。甚至说连我自己都忍不住想吐槽几句——WEB2.0改版真地是非常糟糕，不过幸运的是这并非出自我之手，否则真的是无颜见江东父老。 解决问题之前，有必要对整个WEB2.0产品过程做一个全面的复盘。凡事预则立，不预则废。既然问题已经出现，只有寻求解决方案才是唯一值得做的，此刻有些朋友肯定是按捺不住想着怎么划清界限、逃避责任，这些都是人之常情、无可厚非的。下面将着重回顾下早已埋下祸根的产品过程： 阶段一：BOSS/业务/市场/营销/运营/技术同事提需求，反正TA们能想到的都提了，恨不得再多一点。事实上，这不是需求的正确提出方式，我看到只是[吐槽]！ 阶段二：产品经理有求必应，只要你敢提，我就敢接。很显然，产品经理已经自己挖了很多坑，甚至说已经自己跳到坑里去了。 阶段三：产品经理需求评审，算是尽职尽责，反复评审后得到需求方的确认签字。我看见的只是划清界限、摆脱职责，而不是真正的需求评审回归。 阶段四：需求范围确认后，产品经理完成相应的产品输出，评审交付工程师继续接下来的技术实现。我看见的只是一个过程性交付，并没有一丝业务的扭转传递。 阶段五：产品追踪是产品经理后期工作的侧重点，产品经理务必管控产品推进进程，确保产品细节的还原度。如果出现严重的实现走位，下场只有一个：集体挨批/走人！ 一旦产品/用户需求交付到产品经理手中，产品经理将对需求拥有最终的解释权，产品经理才是需求的唯一合法管控者。就好像与一个姑娘交往，必须本着负责任的态度待之，否则就是耍流氓。互联网信息时代，大多数公司普遍存在跨部门/跨区域的协同办公需要，搭建良好的沟通机制显得异常重要，甚至说良好的沟通协作流程直接决定公司的发展走向。 很多人都说，团队间需要多沟通、多交流。一句看似平常的话，谁又知这背后藏了多少辛酸苦楚、隐忍执着。以下几个问题是任何一个团队都必须面对的客观事实： 事实一：团队成员跨部门、跨区域协作，人与人之间的沟通、信息交相传递必然存在时间和空间二维的失真/偏差。 事实二：不同人看待问题的立场角度、理解问题的思维方式都存在差异，那么想要对问题保持客观、公正的态度是一件不容易的事情。 事实三：陈述事实、描述问题，不一样的表达方式导致问题传递过程中的难以保证信息准确性、时效性。一个事实：不是所有人都愿意听完对方观点的！ 事实四：问题/需求的反复多变，无法保证信息的相对稳定，致使理解难度加大。需求的数量加大加大了个人工作压力和思维负担，对需求的理解产生系统误差。 不论潜伏着问题的产品管理流程，还是不得不面对的客观问题，最终都要将沟通问题解决。解决问题才是，沟通的目的，而解决沟通本身的问题是前提。为了保证工作的高效性、解决上述的各种亟待解决的问题，结合自我的工作实践和公司已有实施流程，制定了一套需求管控规范流程。如下图：  产品沟通的工作流 是否可以解决这个问题：遵循完善的沟通机制就能解决产品管理中的沟通困境？显然，答案是否定的。那么问题来了？既然拥有沟通机制都无法解决问题，沟通还有什么意义呢？ 生死看淡，不服就干！ 沟通流程不是纸张上的成文规定，因为那毫无意思可言，反倒束缚了大家的手脚。沟通流程是团队之间约定俗成的精神契约，是为了规范过程/时间，而不是单纯为达到某个目的而存在。 我很不喜欢看见：起了个大早，赶了个晚集！很多公司上演了这一悲剧，就连巨头公司（比如：微软）也没有幸免，优先踏进移动终端，却铩羽而归。说了这么多，产品沟通只有三个精益要素： -> 说清楚待解决的需求 -> 听清楚解决方的想法 -> 保持沟通、协商解决 《孙子·谋攻篇》中说：“知己知彼，百战不殆；不知彼而知己，一胜一负；不知彼，不知己，每战必殆。” 我是王伟 很开心和大家分享，而我想把开心一直继续！希望对大家有点帮助！ 著作权归作者所有
|
|
|
