毕业 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，还是实践过后从观察数据洞悉人性得来的深刻启发，这里大不相同。
因此产品经理除了要当团队的连接器之外，还得锻炼自己成为团队的大脑，不仅是大脑，而且还得是最强大脑。只有你把需求想踏实了，想细致了，想全面了，才有足够的底气去应对各方各面的挑战，让程序员们信服你，追随你，死心塌地为你改需求。
下次去找产品经理（程序员）对需求之前，不妨带上我的这三个沟通锦囊，真心期待你们能碰出新的火花，携手走向下一个职业巅峰。
