产品管理 | 产品沟通的精髓

2017-02-13 10:31:00

Note：写于2015年7月9日，整理于2017年2月12日清晨。本文是我早期于简书发表的文章，语言文字难免显得有些生涩，不过确实是一个产品经理梦想开始的地方，谁又曾想到这一坚持就是两年！

有效的沟通是一切工作的基础！很多朋友都强调沟通的重要性，不仅是因为沟通本身确实很重要，还因为这一路踩过了数不尽的坑，经历的辛酸苦楚，简直就是一把辛酸泪。沟通只是一种手段，而不是目的，沟通的本质是要解决问题，关键是要在身处撕逼、纠结、矛盾的处境下，依旧能保持一份良好的心境心态/心情。

两点要义：

要点一：好心情是沟通环节的基础保证，谁愿意看到一张[人人都欠TA钱]的臭脸？

要点二：好心情才有可能活得更久，才能有时间做一些自己喜欢做的事情。谁会嫌命长？

工作、生活，开心就好！

这段时间感触颇深，产品V2.0新版上线本该是件令人高兴的事情，可随之而来的不是赞誉，不是鲜花，更不是心心相念的项目奖金。等待你的只有无尽的撕逼/吐槽。甚至说连我自己都忍不住想吐槽几句——WEB2.0改版真地是非常糟糕，不过幸运的是这并非出自我之手，否则真的是无颜见江东父老。

解决问题之前，有必要对整个WEB2.0产品过程做一个全面的复盘。凡事预则立，不预则废。既然问题已经出现，只有寻求解决方案才是唯一值得做的，此刻有些朋友肯定是按捺不住想着怎么划清界限、逃避责任，这些都是人之常情、无可厚非的。下面将着重回顾下早已埋下祸根的产品过程：

阶段一： BOSS/业务/市场/营销/运营/技术同事提需求，反正TA们能想到的都提了，恨不得再多一点。事实上，这不是需求的正确提出方式，我看到只是[吐槽]！

阶段二：产品经理有求必应，只要你敢提，我就敢接。很显然，产品经理已经自己挖了很多坑，甚至说已经自己跳到坑里去了。

阶段三：产品经理需求评审，算是尽职尽责，反复评审后得到需求方的确认签字。我看见的只是划清界限、摆脱职责，而不是真正的需求评审回归。

阶段四：需求范围确认后，产品经理完成相应的产品输出，评审交付工程师继续接下来的技术实现。我看见的只是一个过程性交付，并没有一丝业务的扭转传递。

阶段五：产品追踪是产品经理后期工作的侧重点，产品经理务必管控产品推进进程，确保产品细节的还原度。如果出现严重的实现走位，下场只有一个：集体挨批/走人！

一旦产品/用户需求交付到产品经理手中，产品经理将对需求拥有最终的解释权，产品经理才是需求的唯一合法管控者。就好像与一个姑娘交往，必须本着负责任的态度待之，否则就是耍流氓。互联网信息时代，大多数公司普遍存在跨部门/跨区域的协同办公需要，搭建良好的沟通机制显得异常重要，甚至说良好的沟通协作流程直接决定公司的发展走向。

很多人都说，团队间需要多沟通、多交流。一句看似平常的话，谁又知这背后藏了多少辛酸苦楚、隐忍执着。以下几个问题是任何一个团队都必须面对的客观事实：

事实一：团队成员跨部门、跨区域协作，人与人之间的沟通、信息交相传递必然存在时间和空间二维的失真/偏差。

事实二：不同人看待问题的立场角度、理解问题的思维方式都存在差异，那么想要对问题保持客观、公正的态度是一件不容易的事情。

事实三：陈述事实、描述问题，不一样的表达方式导致问题传递过程中的难以保证信息准确性、时效性。一个事实：不是所有人都愿意听完对方观点的！

事实四：问题/需求的反复多变，无法保证信息的相对稳定，致使理解难度加大。需求的数量加大加大了个人工作压力和思维负担，对需求的理解产生系统误差。

不论潜伏着问题的产品管理流程，还是不得不面对的客观问题，最终都要将沟通问题解决。解决问题才是，沟通的目的，而解决沟通本身的问题是前提。为了保证工作的高效性、解决上述的各种亟待解决的问题，结合自我的工作实践和公司已有实施流程，制定了一套需求管控规范流程。如下图：