关于产品经理如何与程序员、设计师沟通和合作的问题.docVIP

关于产品经理如何与程序员、设计师沟通和合作的问题 这是一篇kant认为对产品经理新手特别有帮助的文章，经常私下推荐给觉得很有潜力的行业新人的，虽然讲的是产品经理的沟通，但实际上程序员、设计师等同学读来，也有触类旁通之妙效。 　　会想到写这个话题，是因为近期在非常忙碌的同时做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这样设计用户体验最好，寸步不让，