经常听产品经理说自己是打杂的，虽然这种说法有自我调侃的意味，但用这词来形容产品经理的工作也颇为贴切。产品经理在一个公司中扮演的角色决定了他要做的事情多而杂，在一个产品诞生的过程中，从idea的诞生，产品的规划，UI设计，前端制作，程序开发，然后测试上线，上线后产品的优化等，产品人员一方面要全身参与，另一方面也要一直跟进。产品经理负责推动公司idea的实现，所以在一家公司产品经理总是要跟很多部门打交道，沟通能力对于一个产品经理来说非常重要。
1）跟需求方沟通；
在公司中，产品部门的需求可能来自于两方，一是来自于产品内部自己的Idea，二是来自业务部门。前者的优点在于可以充分发挥产品人员的想法，但是产品的风险性比较高；而后者的优点在于需求比较明确，产品人员只需给出解决方案即可，缺点在于沟通成本会比较高，对于产品人员自身想法的发挥也会有局限性。而至于说到业务部门具体指哪些，可能是产品运营和公司领导，也可能是来自于市场或者商务等，这由公司的性质或业务决定。以我个人的从业经历为例，我在公司中经常要跟两方打交道，一来自于产品运营，二来自业务部门，例如客服、财务和市场部门。产品运营方的需求，大致可以划分为两类，一类是明确的提出一些新功能，二是反馈用户需求。所以说对需求的描述可能是自己在工作中遇到的困难，希望通过开发产品来提高工作效率，也可能是转述用户的需求。不管是前者还是后者，都需要产品人员主动分析。对于后者——用户的需求，需要寻找满足需求的方法，而这时候也分两种情况，如果没有满足用户的需求就要衡量是否有必要开发新产品满足，如果已有产品能够满足那就要寻找现有产品的缺陷，继而优化改善。
对于前者，运营方之所以提出需求，通常都是在工作中遇到了比较大的麻烦。在向产品人员提需求的过程中，运营方会说明自己在工作中遇到的问题，但是具体的解决方式就要靠产品人员了。我曾经做过EDM系统，其中有一个细节给我的印象很深，运营方把他们的一个需求描述的很复杂，还跟我描述了他们做邮件营销的整个流程，其实终归他们只是需要查询当自己做一期邮件营销的时候需要看一看时间上跟别的产品是否有撞期的情况。互联网行业中职能差异的产生，很重要的一点就是源于个人思维的差异。
我个人将产品人员与需求方沟通总结了一个原则，就是：听他的，但不跟他走。听他的——要听运营方的需求，毕竟产品的最终目的是要满足他们的需求。不跟他走——虽是满足运营方的需求，但是产品人员不应被牵着鼻子走。而且产品人员与需求人员在合作的过程中各司其职，需求人员负责的是功能和内容能否满足，而产品人员则需要决定内容的排版和功能的满足方式。但是当产品人员的设计与需求方的设想有出入的时候，多半还是要产品方作出让步。
面向不同的需求方，对我们的产品设计也会有所影响。运营方提的需求，很大程度上也是供公司内部使用，属于管理后台之类，目的是使其他部门的同事工作能够更高效、更便捷。在产品设计中，我们有一条原则是先有后优，所以本着优先上线、缩短开发成本的原则，而且因为是管理后台，所以对于产品的交互和美观性方面的要求都会相对低一些。如果是产品运营人员的话，因为互联网的意识比较强，所以无论对于一些概念还是功能的使用上都会更加熟知。但相对而言，市场、客服这些部门对后台的易用性要求就会更高一些，工作中你会感触跟他们沟通起来的成本也会更高。
在工作中如果业务部门在跟产品部合作的过程中，双方都能够积极的配合，会使得产品推动的过程更加顺利。反之，则需要产品人员的主动意识和责任心更强一些。
2)跟设计师沟通；
产品原型完成后下一个环节就要交给设计师了，一个产品最终的模样决定权也在设计师手上。美观性是给用户的第一印象，如果产品的美观性不够好的话，那么产品给用户的印象也会打折扣。其实在做产品原型的时候，很多公司都会要求高保真原型，高保真原型要从两个角度去评判，第一是原型的界面做的很逼真，在原型上就已经添加了色彩元素，这样的做法会使得需求方更易理解产品。第二是原型的交互，原型中加入更好的交互，会使原型更加真实，一来利于更好的表达产品人员的想法，第二也便于后续利用原型做用户测试。但是在工作中我会发现，如果在原型中加入色彩元素太多的话对设计师来说会是一种干扰。于设计师而言，产品就是需求方，所以设计师可能想当然的以为原型中的色彩元素就是产品喜欢的，自己设计的过程中也会采用这种颜色。况且互联网公司中常常会有这样的场景，因为产品急着上线而把时间卡的很紧，这时候设计师往往会因为时间紧，而难以产生好的想法，设计出来的页面也难免不会太理想。所以我在制定产品排期的时候也总是希望尽量给设计师多留一些时间。不过话又说回来，像我刚才所说的这种情况，也要因设计师而言，能力优秀或者经验丰富的设计师还是会完全发挥自己的才能。
说到设计评审，我个人的原则一直是尊重设计师的想法。设计前一定要跟设计师详细的做产品介绍，讲解产品中的功能点和文字，以及产品背后所隐藏或希望表达的含义。虽然说UI设计师负责的是美化界面，但是美化的背后也要有其思想，而且这样的沟通后，也便于避免设计师设计出来的页面与期望的有较大出入。产品人员对于UI的设计也会有一些自己的想法，设计前可以与设计师沟通，但是就我个人而言一直都不希望产品人员过多的把自己的想法强加给设计师，甚至精确到页面中某个地方画个什么图案，虽然说这样可能设计出来的东西比较符合期望，但是长期以来这样的做法会束缚设计师，而且也可能会引起设计师的反感。所以可以先让设计师自由发挥，毕竟设计师是专业的，他们的想法或许会超过产品人员。而产品人员可以在设计师设计了几版之后仍不满意的情况下才与设计师详细的沟通自己的想法。
2）跟开发人员沟通；
有时候在面试的过程中，面试官总是会问产品经理一个问题，当产品提交需求给开发的时候，开发人员以无时间作为理由拒绝怎么办？这种情况肯定是产品的新需求与开发人员手头的项目撞期了，解决的办法很简单，就是根据需求的优先级来调整开发排期。每个公司在招人的时候都有其标准，寻求价值观相同的人，所以我一直都相信开发人员并不会无故找理由拖延。不过在工作过程中当产品人员跟其他部门提需求或是沟通确认的时候也不排除其他同事未及时回复的情况，为了确保项目上线也为了争取资源，这个时候就需要产品人员更加主动一些，所以产品人员有时候还需要脸皮厚一点。
总结而言，在跟开发人员沟通的过程中，产品人员要做的工作主要有三点：第一是跟开发人员讲解产品需求；第二是怎么去说服开发人员信服产品人员的想法；第三点就是跟进开发，避免开发出来的产品与预期不符。我从来都不觉得第一点有难度，难点在于第二点和第三点。在原型设计完后，产品都会组织开发人员一起开会做产品的讲解，这时候总是会面临的一个问题就是如何说服开发的同事。因为每个人都是有思想的，看到产品规划后，开发人员也总是会提出一些自己的看法，所以产品需要去说服技术，在跟开发讲解产品的时候也要适当的画饼，描绘一下产品上线成功后的美好未来，这样会带动起开发人员的积极性。个人在工作中总结了一点，就是平时可以跟开发员多聊聊天，增进了解，多观察开发人员经常上的哪些网站。在沟通说服他们的过程中，可以拿他们经常上的网站举例，这样的话他们本身对那个产品更熟悉，自然也更好理解。至于说到第三点，项目跟进，这需要产品人员极大的责任心和积极性。一个项目立项后，公司通常会把参与人员列为一个小组。产品需求文档是开发人员开发的依据，但即便文档再详细，在开发过程中也难免需要当面沟通。产品人员需要根据开发排期跟进开发进展，验收产品功能是否与产品期望一致。这个过程产品人员的工作往往会比较繁琐，也会比较忙，同时也会极大锻炼产品人员的沟通能力。
当提交一个产品无论是给设计还是开发部门制定排期，你会发现他们都会把时间定的很充足。也许你会因此对其他同事有看法，但其实在工作中都是这样子，每个人都不会为自己的时间安排的太紧张，而且大家要考虑过程中可能会出现的风险因素，例如请假的情况。当然也并不是让开发人员越快越好，所以最好是产品人员根据上线时间与开发人员定一个时间结点，让开发人员在该时间前完成即可。
沟通是个艺术活，同一句话的同一个意思，不同的人、不同的情境、不同的语气说出来效果可能都会有所不同。每个人处理事情的方式各有差异，时间长了，大家在工作中都会总结一套适合自己的沟通方法。而且沟通只是个过程，好的沟通是为了产生好的结果。