【长文】产品经理如何更好地与程序员、设计师沟通和合作- 大数跨境

电商产品

2015-04-16

导读：这是一篇对产品经理特别有帮助的文章，经常私下推荐给觉得很有潜力的行业新人的，虽然讲的是产品经理的沟通，但实际上程序员、设计师等同学读来，也有触类旁通之妙效。

会想到写这个话题，是因为近期在非常忙碌的同时做N个大需求，又有些需求反复大小更改，但又与程序员、设计师等各类角色也算能交好关系、树立口碑和信誉。同时见到有些朋友和同行在这方面似乎存在犹豫和不解，时常出现多方角色各自觉得己方最苦最委屈的情况，与我初时刚从做策略转为做策划和推动时的疑惑迷茫有些类似，便考虑将自己的些微心得写来抛砖引玉。

产品经理是个需要懂很多东西的万金油角色，与各类岗位相处、合作和推动，是产品经理工作的重要部分。在与各类角色（常见的有程序员、设计师，还有公关、法务、客服，以及商务、其他部门等）的合作中，我将自己的感受梳理，觉得产品经理与其他角色相处合作时，秘诀便是“三解”（kant注，这其实与我朋友交往的原则也类似）

第一解是互相了解

互相了解是有效沟通和相处的基础，甚至是一切的基础，非常重要。互相了解是件只要你愿意做，就很简单的事情。没错，只需有一方愿意做，便可实现双方互相了解，介于程序员、设计师们工作切实，总是追赶timeline而加班苦逼，这个事项必须由产品经理担下来。

产品经理总觉得自己很忙，其实也确实忙得啥事情都要跑着做（至少我是这样），但在不了解你的开发看来，你就是花5分钟写好邮件发给设计师，让出设计稿后，给开发看看，没问题便开发去写代码，产品便闲下来了。这是产品经理大叫冤枉但程序员认为就这么回事的情况了。产品经理除了上面这些，还需反复思考设计稿、与设计师反复PK、与各级上级沟通确认、继续思考设计稿、出设计终稿、给出并确认所有细节和文案、与各相关人确认方案有效性、查漏补缺、一切杂事。

程序员也觉得自己很忙，确实每天加班到晚上4点的我的室友就确实累得像条狗一样（经常我2-3点下班都等不到他一起回）。但在不了解程序员的产品经理看来，似乎你提的需求简单无比，你觉得1天就做好了，程序员还要拖一个星期来做，因为对大公司程序员来说，每隔10分钟解答一个小白产品的小白技术问题，每隔30分钟被拉去参加一个会，几乎没有完整有超过1小时写代码的时间。就我自己而言，我也是晚上10点以后，才能专心开始深入写代码。除了时间碎片化的问题（事实上这对于智力密集型的coding工作已经很毁灭性了），还有方案全面性的问题，产品经理在提需求时只会提正常情况下的处理，但程序员要做业务逻辑之外，还需考虑高并发、多线程、各类异常、各类安全性问题、请求是否会被伪造如何鉴别，高数据要求下的自动对账、数据备份和上报等。当然，有些比较随便的程序员，或者实在时间紧迫的情况下，就不会考虑那么周全了。

设计师也是类似的，就不罗列了。

如何互相了解？实施起来很简单，无非是多观察、多咨询、多表达，加一个自学习和自尝试。

多观察、多咨询就是产品经理要多观察程序员、设计师的工作，在闲时多咨询程序员、设计师工作具体在做什么、技术方案考虑了哪些方面、设计稿为什么会拖延交付日期、为什么这种方案实现起来比较复杂而那个做法简单得多。

多表达就是产品经理要将自己在做什么表达给其他人，让他们知道你不是真的在打酱油（如果你真的在打酱油，那想办法假装不是）。表达方式有很多种，不要做得太突兀，自然一些，这种表达，其实也可帮助你将情绪、负能量抒发出来。

自学习和自尝试对我个人而言不太需要（有过几年代码经验，做过一些项目，对设计师的工作也有粗浅了解），但对于没有技术背景、没有设计背景的产品经理来说，为了更好地合作，你必须通过自己的学习和尝试，了解别人的工作。

第二解是互相理解

做到互相了解，基本上已经能让其他角色对产品经理很包容、吐槽得少了。但这还不够，可以做得更好，便是互相理解。

互相理解就是了解对方的痛点和难处，尽量不让对方为难。

这对于很多人是很难的，很多人只觉得自己痛、难，相对无视别人的痛苦和难处，这类性格大致不太适合做产品经理了。产品经理需要快速把握其他角色的人，真正在意和痛苦的是什么，需求方案中真正的难点在哪里，为什么会被PK和挑战。

举个例子，假设一个需求方案，由A、B、C三个关键逻辑，和D、E、F三个细节逻辑或设计点组成。

对于ABC为什么很关键，它们影响了什么，涉及多大比例的用户、或者是什么级别的老板已经拍板决策无法变更，产品经理有义务表达清楚，让其他角色（程序员和设计师）理解，实际上这也有利于对方理解方案的本质和产生更好的自发驱动力。这是让程序员和设计师理解产品经理。

产品经理也要理解程序员和设计师，比如DEF三个细节中，设计师提出来说D不符合一贯设计规范，而你硬是认为D这样设计用户体验最好，寸步不让，说不定便造人厌恶，实际上D这样的细节对于用户体验的影响又实际微乎其微或者用户完全不在意。又或是，EF这2个点，程序员希望可以换种做法，因为原方案的技术难度很高、时间成本较久，带来的影响是譬如产品界面略有变更、在某些极端流程和场景下会产生不大的不便。这时，产品经理要理解程序员和设计师的难处，理解对方的辛苦，对不重要的细节适当退让。

切记不要在任何时候进入了“我怎么总是被PK下去了，不行我要赢一次”的心态，记住，你不是为了输赢，你就是做事。

第三解是互相谅解

若是做到了互相了解和互相理解，基本上你已经是一个受其他角色欢迎，备受好评，像我这样的产品经理了。但你如果还愿意深入，便继续来互相谅解。

很多时候产品和功能上线后，经常会发现产品方面没考虑清楚，或技术方案扛不住压力挂了，或视觉设计很难看，或重大BUG没被测试发现。这时需要互相谅解。

互相谅解是在遇事时，双方互相谅解对方的失误和错漏，优先解决问题，而不是立马站出来撇责任。

理想情况当然是大家和和气气，解决问题，谁也不喷谁。当然“理想情况”就是不太可能的意思。正确的做法是，产品经理要敢于站出来直接承认错误，承担责任，不要什么都推给“这是老板要求的做法”、“技术方案顶不住我有什么办法”什么的，殊不知产品经理就是产品的负责人，必须为一切错误负责，需对老板的方案提出可能影响大局的问题，毕竟老板不会深入想细节，你有责任告诉他，也需对产品和功能的性能有预期，告诉开发这个功能大约多少人用，也需要做半个测试人员。产品经理每天就动动嘴皮子写写文档（至少很多开发是这样认为你），如果遇事不扛下来，还有个屁用。

互相谅解的另一个角度是需要夸奖，在没出问题时夸奖，比如邮件总结时夸奖、在会议上夸奖、在对方领导面前夸奖等。夸奖是有方法的，空乏的夸奖没有意义，并且惹人厌烦。这里引出一个我常用的夸奖的方法，FFC原则，即Feeling感受，Fact事实，Compare对比。

举个例子，设计师做出来的稿子不错，你想夸奖她，不要说“做得好，真好”，说“我去这个稿子肯定妥了，我一看就心里踏实了，你看流程从之前的5步一下到了3步，还每一步都很易懂”。这便是FFC。

类似的，没有女朋友的你，长长心，夸妹子不要说“你很好看”，说“你今天走过来的时候我被穿这件衣服的你震住了啊，宽松衬衫加热裤搭起来，一走过来，那群开发狗一个个伸着脑袋在那瞟，哪有其他女生走过来的效果”。

基于上述这些办法，我成为工作圈里面相对让人觉得靠谱的产品经理，也有人匿名赞为“不改需求的产品经理”（有人问我，你老板不改需求么，我没回答，其实是老板当然会改，但是即使这样，你也可以成为一个程序员感觉你不怎么改需求的好产品），想起来近期朋友圈在分享一个靠大胸美腿等这些方面优势来与程序员搞好关系的文章，产品狗们痛呼我没有大胸美腿怎么办，希望这篇文章可以帮到你。

电商用户体验是唯一同时关注电商和用户体验的公众号，长按下图“识别图中二维码”

↓点击下方「阅读原文」查看更多精彩文章

【声明】内容源于网络

电商产品

来，这里都是互联网人需要的干货。

内容 295

粉丝 0

电商产品来，这里都是互联网人需要的干货。

总阅读0

粉丝0

内容295