给程序员与产品经理的六个沟通锦囊

毕业6年,做过千万级后台的主程,也主持过亿级DAU推荐系统的架构设计,招过人带过人开过人,也曾以产品经理的角色参与过多个运营系统项目。深知程序员与产品经理的沟通始终是IT行业绕不过去的坎,不长的职业生涯里,见过程序员与产品经理沟通顺畅相得益彰双双升迁的正面案例,也见过更多的撕逼堵心相互拆台两败俱伤的反面案例。这两种职业本来不应该有如此水深火热的对立,甚至从技术转产品也好从产品转技术也好都可以找出成功的样板,那么症结在哪里?作为实现过角色转换的人,我觉得根本是二元思维的对立:程序员的游侠精神,产品经理的老板想象。那么两个如此迥异的物种如何沟通无间合作自如相亲相爱呢?以下就是我从各自角度出发的一点细微建议。

首先是给程序员的三个沟通锦囊:

学习技术不应成为最重要的目标

也许没有如同程序员一般自由的职业了,虽然经常被类比农民(码农),可真正下地干活时我们可以做到心无旁骛,带上降噪耳机循环一首不合时宜的摇滚,机械键盘奏鸣着敲下的,是你的奇思妙想,与天时与地利无关(甚至我还碰到过因为想写自己喜欢代码甘愿从leader自降为普通员工的程序员)。然而,有很多初出茅庐的程序员就会滑向另一个极端:认为追求技术的持续深入是工作中最为重要的目标,如此一来导致的坏结果就是,要是产品经理丢过来的需求没有技术含量,就不乐意接,就打心底抵制;要是产品经理插入的需求恰好要破坏这一亩三分地(代码架构)的美感,就像被要了老命似的。

公司不是学校。公司支付你的薪水,不是让你深造技术,而是希望你替老板解决问题。你的聪明才智,除了用来造一个酷炫的预测模型拟合出用户增长的趋势,除了用来搭一个华丽的网络框架支撑千百万并发的访问,自然还得用来跑一个寻常不过的活跃数据,写一个简陋不已的监控网页。因为,这些都是业务发展不可或缺的一环。而你还想学习最拉风的技术?那么请穷尽所有的业余时间,去阅读最顶尖的论文,去操练最前沿的工具,去模仿最鬼斧神工的代码。一旦回到工作场合,你的大脑应当无时不刻在思考,如何高效、准确、敏捷完成产品提出的需求,以挤出更多的时间去关注业务的全局变化、去思考新技术与既有业务的结合点、去提高其他成员的技术能力。如果能做到这一点,我相信你会迅速成为团队所倚重的技术骨干。

刻意培养对外表达能力

程序员一直是羞于言语表达的,祖师爷Linus的格言早已铭记于心:Talk is cheap, show me the code。但是公司却是各种角色的集合,像老板、设计师、HR、外包测试乃至前台,彼此间的交流仍然要通过自然语言而不是机器语言实现。所以能够适时把肚子里的聪明才智秀出来、能够恰当把眼皮底的功劳业绩拿住了、能够随时把身边的工作伙伴愉悦了,自然而然会成为受欢迎的人。随着平台的扩大,表达也不局限于一对一的单挑沟通,向上汇报、规划脑图、总结邮件、技术指南、胶片与演讲,都是现代职业人不得不学的技艺。学会了它,你的影响力将成十倍成百倍的扩散。可惜的是,我曾经看到过不下十个编程功夫已入化境的程序员倒在了这一阵,由于天性内敛敏感,加上长时间对着机器,养成了拙于表达、怯于表达的人设,导致回报与产出完全不成比例。从毕业至今,我一直坚持着一个从前任CTO那里偷师来的习惯:工作一两个小时起来走一圈,随意挑一位不忙的同事,和他聊上两三分钟,了解他近期手头的项目,顺道也介绍自己的项目,许多意料之外的成果就产生在这种貌似不刻意的小连接之上。

勇于挑战产品经理的边界

若干年前我曾写过一篇倍受欢迎的理想的程序员,讲到理想程序员比普通程序员突出的六个一点点,就有一点是Never Say No,这引发了很热烈的争辩,也有读者误解为全盘接受产品提出的需求,当然不是!我只是鼓励程序员尤其是新手程序员以开放的心态去面对需求,并不意味着合理的不合理的需求都要一昧接下。在我看来,除了表达能力之外,程序员最该培养的第二项技能就是产品思维。技术工作的本质,无非就是通过技术实现用户或客户的需求,产品经理恰好是承担了连接技术与商业的职责,如果连接器没发挥好,即便技术完美达成了,也是无用功。除了产品经理之外,整条互联网流水线上的所有角色尤其是负责实现需求的程序员,都应该是需求的把关者,都应该具备敏锐的产品意识。当然你一开始或许不具备Say No的能力,但是接到需求时不妨多想一想需求从何而来,它真实存在吗,你是用户怎么感受,你妈是用户又怎么感受。长此以往的死磕之后你的产品意识会越来越好,程序员懂产品,好比流氓会武术,并不是你一定要和AllenZhang一样转行去做产品经理,但至少你在产品经理心目中的话语权和专业度会涨好几个段位,需求也会越接越少,越接越精,腾出更多时间去建设你的技术影响力。

然后是给产品经理的三个沟通锦囊:

产品经理不是经理

记得毕业前问一位同学为什么选择产品经理这个职业,他打趣道因为这大概是惟一能给应届生提供的经理职位,许多人也许有类似的误解,觉得产品经理比程序员地位更高。一个产品经理尤其是新手产品经理,如果带着这么一种心态去与程序员沟通结果无疑是悲惨的。产品经理与程序员一样要从螺丝钉做起,无非一个的职责是写代码,另一个则是写需求。虽然产品经理有更多与老板对接的机会,但切记一定不能把自己代入为老板。请看某产品菜鸟A与程序员菜鸟B的失败沟通案例:

A:现在有一个超级紧急的需求,X总说今晚就想上线,加个班兄弟?
B:@!#$%^&*

再来看产品大牛C与程序员菜鸟B的沟通就顺畅多了:

C:我们最近看了数据,发现在左侧加个导航栏能增加10%的聊天功能活跃,和X总沟通过之后他觉得这个功能也挺重要的,上线这个功能之后今年的KPI也就有谱了,这个模块你最熟,能不能评估需要多久改完?虽然X总很着急,但是我们肯定要先保证质量,人力方面有困难的话我帮你去协调。
B:有理有据,无法拒绝。

C与B的对话,虽然目的同样在于传递一种要求,但有更多的平等交流的味道,能让对方了解到更多的背景信息,让对方感觉是在为共同的目标工作,而不是把对方当成下达指令就能开动的机器

主动为程序员寻找资源

罗振宇曾经把产品经理比喻为一个连接器,这个连接器除了连接上文提到的技术与商业,还需要连接团队中的不同角色。通常产品经理所掌握的信息是最多的,但是许多产品经理并不知道信息必须要充分流动起来才能成为资源,比如哪里有现成的组件、谁做过类似的工作、哪个组可能有空缺的人力,这些信息都是有潜在价值的,一旦供应方的信息和需求方的信息匹配上,就会形成资源的优化配置。一个合格的产品经理,应该为程序员留心和协调资源的引入,帮助他们减轻工作负担、提高产出效率。而一个优秀的产品经理,还应该为程序员的职业发展路径考虑,帮助不善言辞的程序员向上请功,帮助醉心技术的程序员争取更多与大牛交流的机会,帮助堆砌业务的程序员挖掘更多的技术亮点。毕竟你帮助别人更多,别人自然也就更愿意回报你。产品经理与程序员,从来就是相依为命,「狼狈为奸」。

做团队的最强大脑

产品经理这个职业相比程序员,最有趣的一点就是除了决定怎么做,还能决定做什么当然程序员这个职业太多更有趣的地方,容我卖个关子,以后专文写)。所以,一个差劲的产品经理将成倍放大团队的人力耗费,降低团队的运作效率。有许多经验帖都谈到产品经理与程序员的矛盾症结在于改需求,其实改需求只是表象,互联网本来就是一个快速变化的行业,改需求不可避免,根源在于产品经理是否有独立思考的能力和意识,改需求是人云亦云,是老板Push,还是实践过后从观察数据洞悉人性得来的深刻启发,这里大不相同。因此产品经理除了要当团队的连接器之外,还得锻炼自己成为团队的大脑,不仅是大脑,而且还得是最强大脑。只有你把需求想踏实了,想细致了,想全面了,才有足够的底气去应对各方各面的挑战,让程序员们信服你,追随你,死心塌地为你改需求。

下次去找产品经理(程序员)对需求之前,不妨带上我的这三个沟通锦囊,真心期待你们能碰出新的火花,携手走向下一个职业巅峰。