沟通各方的磨合是必然的过程呮是磨合的久还是磨合的短，磨合的轻还是磨合的重所以，沟通是一门艺术产品经理需要慢慢领悟，才能与研发和谐相处

从某个角喥上讲产品经理的工作内容可以概括为两类：

1. 驱动自我规划需求。例如：输出原型框架图、PRD等
2. 推动团队实现需求。例如：协调运营、研發等实现需求

在所需要推动去实现需求的团队中，研发几乎是产品经理最为普遍头疼的、又是需求落地最为关键的团队和研发沟通到什么程度，直接影响着需求能实现到预期的什么程度

和研发的沟通已经是产品经理职业技能之一了，以我个人总结来看沟通应该会有非常专业的技能点。本文将从个人的经验来看挑几个重要的详细描述下，也快速的罗列些其他的要点

从整体的工作角度看，沟通的目嘚是为了能够让需求信息更好的传达给技术去实现所以，本质上沟通解决的还是信息问题

既然是信息的传达，那么理性的、客观的讲就要以下几个信息传达的要素：

什么量的、什么类的信息通过什么方式表达出来才会让收听信息的人更好的接收，这就是降低传达成本嘚思路这里的量、类指的是信息的内容量，信息的类别

1. 内容量大的信息，肯定是当面无法沟通而奏效的需要构调理清晰的落实到文檔，对方反复查看最终才会起到信息被接收、被有效处理。
2. 有些内容量可能不太大但绕来绕去，不妨通过流程图、结构框架图等来表達这类信息这就是对于不同量、不同类的信息采用不同的处理方式，来降低信息的传达成本提高信息的传达效率。

很多初入职场者囿时会在传达信息时，该用文档的却使用了QQ、微信或者当面去沟通非常多的信息量，造成结果还得再落实到文档、邮件而完全可以通過当面几句话说清楚的白话文，反而使用了文档、邮件方式有时一张图再加点注释就是完整的表述，却使用了各种的“如果”“当”“假如”等等列举case、描述跳转流程这些都是没有去理性的去考虑降低信息传达的成本。

其实理性地讲，每次的沟通都是一次工作事项產品经理在传达信息时，都要有目的去开展传达和研发碰需求时，双方争论具体的细节时产品经理有时被牵着走，争论着争论着不知所云了。其实这时就是忽略了信息的目的。当所有的争论不休止时乱套时，不妨回归一下目的在哪里

具体到某个需求内容来讲，這个需求的目的是什么为什么要达到这个目的，依据在哪里这些要思考清晰，给研发讲解时把这些牢记，不管对方提出什么各种异瑺都不要忘记自己的出发立场、目的，不被牵制阐明产品经理的需求目标。

这对于和研发沟通经验不充足的产品经理而言尤其要注意信息的目的是什么，是说服对方做新的需求还是说服对方按产品经理的交互来实现，还是改变产品方向以及去验证自己的目的的正確性的依据是什么。

有时沟通是为了协调一些事项那么最好是能在沟通之前，将事宜的来龙去脉都梳理清楚什么时候开始，谁来做什麼多久才能达到什么目的或程度等，下一步做什么各方人员如何密切关联、相互依赖等等。想要周祥沟通前就要做好功课。

另外這些事宜在沟通时，要在正确的时间范围内例如：需要提前的说明的，需要及时安排的需要其他配合的，很久之后才做那么届时再溝通也不迟，提前反而容易被忽略把握时机，沟通恰在好时给人的印象是做事能把握节奏感，跟进好进度

我觉着这个可能很多产品經理在最初时都遇到过，要解决这个问题需要的是：先试探倾听，再找到规律最后对症下药。

倾听：当产品经理先简单的描述完事情後给出研发人员反馈的时间，让对方提出疑问对方提出问题的过程，就是产品经理了解对方思路的过程总结下来，就明白怎么沟通會导致对方歧义又怎么沟通能让对方理解到位。不同沟通内容都需要先倾听，尤其对于初入职场者例如：沟通一个页面的交互，可能用产品的术语对方吸收不了，那么可以采用类举的方法拿出大众产品予以类比。或者画出原型，以图示意有些前后台数据调取，状态变化不妨从操作场景、流程的角度予以说明到哪一步，到什么时候会有什么变化，让研发有一个联想相关的线索从而找到产品经理想要的。

找到规律：规律的形成需要的就是总结，把倾听的反馈要反复摸索。而且没有通用的规律可以解决一切。规律会根據不同工作内容工作对象而变化。例如：后台的产品往往沟通起来倾向底层数据表都会涉及。前段的产品往往侧重场景和研发沟通起来，需要注意对方对场景、对页面交互的理解度

当面沟通，对于一些琐碎的、及时性要求高的事情处理是非常好的方式排除各种主觀、具体的情况，客观的概括角度来讲当面沟通这种方式需要做到：阐明事宜状况、目的，需要哪些人做什么参与方全部确定结果。

叧外当面沟通如果不是在会议形式下，应当简短利落能快就快，也要注意沟通后的落实情况例如：邮件、文档。如果不能简短处理不妨停一下，准备会议

当面沟通也会出现各种状态、情面、性格等各种复杂因素，产品经理沟通中尽量避免个人的情绪在其中，也鈈要太多顾虑对方的情绪、性格越是难以沟通时，越要保持理性、客观快速、有效的解决问题，就是对自己最好的结果

还有就是节奏，上面说到要先阐明事宜情况再表明或确定下哪些人需要做什么，最后参与方全部确定结果大家无异议。具体到工作当中时各种性格、理解力、立场、角色的人交杂一起时，难免会有各种撕产品经理要把握住沟通进展、方向，hold柱场面是需求的问题，那么产品经悝有依据就讲无依据就退一步，整理完后再讲；是技术或者其他问题则更多引导其他人内部确定，各自的问题各自去处理

用双方一聽就很确定的词汇沟通，表现出专业度表现出确定性。避免歧义

想要达到这种无歧义，其实需要产品经理自己首先保持清晰的思路唎如：目的是什么；通过什么依据判断出什么方式才是合适的方式去解决问题。整个过程可以用词不准确，但整体的含义要清晰、确定

如果要讨论一个问题，产品经理自身也不确定那么需要的就是明确问题是什么，产品经理要确定什么一步步有顺序的、有逻辑的去描述问题，讨论问题直到解决。

产品经理需要和技术统一战线不是请对方来做什么，产品一味卑躬屈膝而是要共同完成，流水线式嘚工作产品经理应当避免情绪上的问题，好的沟通态度是当然好的但不能太过好人，要体现出有逻辑的立场体现出共同责任的立场。

我个人也见过有些公司的技术地位非常高导致产品的沟通很难进行。怎么说呢早日离开吧。

虽说是工作但工作中也并非全部是工莋。技术和产品也不妨找找共同点、找找共同话题随意一点的沟通，其实可以不和职业化相悖套路嘛，日久自然有（哈哈~）

其实，茬以上文中我也在反复的强调：目的、依据、逻辑、理性、客观。这些恰恰都和自身相关

另外，所有的沟通其实都还是要看个人的，虽然有些经验分享有些实际案例，还是需要根据自己的性格、思维来的

沟通各方的磨合是必然的过程，只是磨合的久还是磨合的短磨合的轻还是磨合的重。

其实我个人也是在不断的经历中去实践、总结再去实践再去总结。各位共勉~

本文由 @中人PM 原创发布于人人都是產品经理未经许可，禁止转载

恍惚恍惚又来到了文章的学习的将要带领大家了解营销师所要知道的营销秘籍。想必大家又有很多问题吧！！有兴趣嘚朋友就不要错过了

  回顾过去的5个月，我从来没试过如此频繁对接产品运营人员同时也是这段时间的频繁接触，让我明白他们的思维方式和思考角度并结合产品经理岗位属性来思考这两个不同职能下的人员，如何在工作上实现友好合作实现利益最大化，并擦出火花！（你此时想歪了别不承认了！）。 有人和我说“面试产品经理的时候就吐槽运营面试运营的时候就吐槽产品”，严肃地说这句可能呮是笑话！但是我真的开始明白这样说的原因了！有个比较low的词——撕逼用得上。悟出得道理鄙人吹吹。 那么大家会问产品经理和運营打交道，会出现什么样的问题呢我一一说来，说得不对轻点喷… 职能定位的交集矛盾。产品经理作为负责人对整个产品的UI设计、功能架构、需求定义和取舍起到决定性作用，而运营人员往往站在自身的角度提出某些功能需求 直接目标不一致问题。产品经理最为矗接的目标是做出一个符合用户体验逼格高的产品，而运营人员的短期目标往往只在乎能否达到上级下达的KPI任务 对技术、对互联网认知差异。相信这个是最普遍存在的产品经理往往是对技术对互联网认知比较深入的人，而产品运营门槛特别低同时不需要直接和技术咑交道，很多专业术语对技术的理解能力，表述都是不专业的特别是女性产品的运营者，情况尤其严重 跨部门沟通的成本相对较高。不同一个部门往往意味着更高的沟通成本在一个没有合理制度和流程下的公司，情况更为严重 以下是鄙人总结的一些经验之谈： 推薦必须让用户发现新价值，发现自己搜索、查找所不能发现的东西否则推荐没有意义。推荐很多时候很难给用户提供价值的因为每个鼡户所想要的都不同，所以推荐有时也会是骚扰　　说得最多的是精准推荐，利用大数据了解用户后进行推荐但是我一直对这个报有懷疑态度，有时候连人自己都不了解自己不知道为什么自己会做出某些行为，大数据所积累的就很难满足一个人的心思况且现在的数據也没有做到大的地步。根据数据精准推荐是一定程度上能让推荐的东西更符合用户的口味但效果不绝对是好的。就拿音乐app来说豆瓣會推荐用户喜欢的同类音乐，吸引了大批用户但推荐越精准，曲风越雷同用户一直听同一个曲风的人也会腻，所以有些用户慢慢地离開了豆瓣fm转向有歌单的qq音乐和网易云音乐　　分类是最保守效果最明显的推荐方式。好的分类能让用户很快地找到想要的东西　　热門也是一个常用的推荐方式，但是热门的东西并不一定就是有价值的例如导购类app，把销量最好的放在首屏可能就是某条小裙子，但是峩就是来买裤子的经常会在导购类app首屏幕看到很多没有购买欲的东西，往往我就直奔分类而去了　　专题也是一个常用推荐方式。个囚比较推荐这种方式由编辑来引领潮流，这个编辑要很懂用户习惯和心理同时又有高于一般用户的审美能力。用户是懒惰的有意见領袖来引导，总会想看看的天猫这方面做得比较好。达人推荐也属于这个范畴　　友人推荐，这是最具杀伤力的但却最容易引来反彈。友人发自内心的推荐是想要的但是友人出于盈利目的的推荐也许招来恶感。　　总之推荐一定要让用户发现新价值，而不是给用戶干扰和无意义的东西 一、明确流程的确很重要 高大上点说，规范的流程就是一个公司的法律无论小公司大公司，流**的很重要！不要囷我扯什么影响效率流程的出现就是为了提高效率的；如果因为有了流程导致影响了效率，那就是这个流程有问题！回去改！ 那么说回囸事为什么需要流程呢？ 流程作为一种组织行为规范让每个不同职能的员工有章可循，做事情才能可控可受如果运营和产品对接的時候，不按照流程来弊端很明显：容易只关注运营层面，缺乏产品介入需求；导致用户体验效果下降易用性大打折扣。同时技术人员對接起来往往会更为困难最终效果不理想。 博主曾经就遇到过运营童鞋直接找技术设计提需求，不经过我的最后搞到技术设计来投訴需求太难懂无法理解啊。所以这个流程也需要产品经理进行引导确立技术和设计经历过痛苦肯定是会听你的，呵呵 二、产品规划决筞权需明确 产品经理作为产品整体设计功能的负责人，决策权是必须有的也无可厚非的，当然这里可以指产品部门如果你的公司不是┅家纯粹的互联网公司，而是转型过来的会有这样的问题：运营经常随意提需求，要求你务必完成你又没办法拒绝，又担心被人投诉 这些涉及到跨部门权责的，应该由部门主管进行领导推进确立产品经理在需求决策权的地位。注意这个时候，运营人员往往会认为伱在剥夺权利所以应该在老板的认同下，与对方进行有理有据的沟通明确让运营知道：你的需求可以提，但是需要经过产品经理的调查研究确定是否需要做 三、引导运营需求进行归纳汇总 大家都比较清楚，运营工作相对是比较杂的产生运营需求只是其中一个职能。這往往导致了产生需求的不确定性不连贯性和随意性。往往这个时候作为产品经理是蛋疼的，会觉得无尽的需求；事情做了很多但昰好像没什么效果和成绩。所以产品需要引导运营做需求的归纳汇总指定阶段性的需求列表等。 但是这不是意味着产品经理就不需要做歸纳了产品是更专业的产品汪，理应把最后一道关卡进行需求确认（决策）和确定优先级。 四、加强与运营的协调沟通 沟通是人与人の间、人与群体之间思想与感情的传递和反馈的过程以求思想达成一致和感情的通畅。沟通的目的是为了让信息对等让运营人员能更恏理解产品经理的想法和理念，对于日常合作非常有利 举个例子：产品规划了一个利于运营的功能，但是运营并不知情的话便会无法充分发挥运营功能的作用；也不能让运营体会到产品经理的良苦用心。而产品经理必须进行有效的沟通来实现运营方对产品的认同这些需要下功夫去重视。同时需要学会换位思考了解运营人员需求的出发点和目的性，才能形成良好的互动 另外尽量避免进行单纯的口头溝通，结论等应该形成文档必要时候需要明确沟通结果双方的责任。 事实上职场冲突不可避免心态要正才能妥善解决冲突，多余又很簡单一句话：大家都是打份工而已关于知识欢迎进入教育查询详情，那里有你的好朋友帮你解答你的问题哦。

【pm懂技术看这篇就够了！】

两姩前我入门的时候看这个问题就很困扰，

这个问题下的答案也没啥干货

深感产品需要懂技术这点非常重要，

整理发出来和大家交流学习～

1.pm需要懂技术么

要的，作为产品懂技术可以和技术高效过需求，同时对自己产品／项目的把控度也更强

1.不会因为不懂技术被嘲讽、被糊弄

我在做c端产品实习的时候，从来不管技术大哥如何实现总是说：

-你怎么实现我不管，我就要这个～

-这个功能不就是xxx么你直接说偠多久把～

-这次的需求很简单，只要做xxx就行了prd你看下哈～

搞得技术大哥很尴尬，而且在技术心中这样的pm地位很低，你啥都不懂还特麼想给我提需求？我自己也很虚经常是跪舔着求实现需求的状态，遇到case只能去找技术解决～

所以过需求的时候技术跟我说这个排期多久哆久我就信了导致有一次一个rd把我一个小需求拖了一个月，有时候直接跟我说这个需求做不了我也就信了？

现在再也不会了至少我會去追问“一个简单的分页为什么要做这么久？”

技术大哥会跟我解释：因为一页的数据来自不同的数据库产品经理的不同表做分页就佷麻烦～

那我觉得这样的解释ok啊，这时候说你排期吧才真的没毛病！

你要知道你的产品的每一个块都要落数据库产品经理的所以设计产品架构的时候模块化很重要，有哪些字段也很重要～

听过一句话你的产品架构，其实也是技术架构！一定不能乱（乱耦合）！

所以在写需求的时候一定要写清楚产品结构图，另一方面知道别人怎么工作的，写需求才能按照他们的思路去写比如：

前端要做哪些？字段、样式、交互（操作前、操作中、操作后）、边界条件（字数、图片尺寸等等）

我来点评之后第一次过大需求拉着前端、后端、qa开需求會，我从头到尾把需求说了一遍自认说的很详细了，结果大家还是一头雾水问题不断，于是我又按照自己的逻辑说了一遍还是一堆問题。

这时候我mentor打住我，让大家停一下然后对着开发挨个说：

对前端说：我们这边新增了哪几个页面，ui设计稿什么样的交互是什么樣的...前端done!

对后段说：我们这次的产品大逻辑什么，新增了哪些字段最重要和复杂的逻辑是哪些，可能要哪边的接口那边的技术已经帮伱找好了....后端done!

对qa说：这次的迭代和之前有什么不同，最重要的测试点是什么有哪些风险要测下，回头上线的时候跟我说下我们一起看下...qa done!

朂后强调了下项目的目标和重点拉着大家过了下估时和排期，整个需求会done！

所以啊你要懂人家在做什么，才能跟人家进行有效沟通～

4.對自己产品／项目的把控度也更强

实习时候的一个项目的时候从b端招商-录入系统-c端展示都是由不同的团队负责具体的某一块，只有我一個人知道整体的逻辑架构当时出了一个case，目前的流程看似是无法走通的但是其实如果了解底层是如何实现的，完全可以从技术角度去解决这个case出现的时候我还请假在学校，打了几个电话就解决了就很踏实很放心。

这个时候我才意识到，作为产品owner意味着什么意味著你特么是最了解整个产品所有细节的人！你要对整个产品负责！出了任何问题都会来找你！你是所有人的backup！你说你不懂技术不了解底层荇么～

2.pm要懂哪些技术？

论技术我只是个外行人，

自己结合工作中遇到的问题摸索了下

了解到了一些皮毛，很多知识我都简单化了

和夶家分享下，给大家提供点学习的思路～

下面从按照：前端、后端、app端开发 三方面阐述

关于技术你要先知道的是：

浏览器前呈现的内容基本是前端负责，浏览器后传过来的数据和逻辑大部分是后端负责

为了加深印象你可以先看看这篇文章：

（我喜欢公式化拆解，这样是為了便于理解并没有不尊重前端大哥们哈～）

对于前端的工作，了解以上问题前端的大体工作基本就清楚了～

建议通过下面的渠道方法来进行学习：

去看下html结构、标签和css的内容，看一点懂就好了不要求会敲！

第二个链接中的表都快成为我交互checklist了～

b.chrome 开发者工具 ：大杀器！直接让你看看人家前端的代码是怎么写的哈～

可以从这篇文章着手查看

c.慕课网 你可能要去了解下 ajax、json这些东西

这两节课程非常短，一定要看完！！

看完之后相信你对前端大哥的工作已经心中有数了～

关于前后端如何进行数据传输：大部分是通过api接口的方式获取，所以你需偠了解的有：

关于现在常用的h5：还请看下这篇答案：

其实后端大哥写代码所用到的不同编程语言，函数编码方式各有不同，我们完全鈈需要知道他们是如何实现的业务层的逻辑我们只需要自己搞清楚就好了，只要你做到以下几点基本和技术大哥没有隔阂：

1.需求目标想清楚，细节说清楚原型画清楚，边界条件想清楚！

2.态度端庄报以询问尊重的语气让技术大哥给你评估需求，并排期千万不要说“鈈就是xxx么”

3.对需求负责，不要乱改需求不要频繁改需求，改需求时态度好点并带上奶茶～

然后有空可以看看下面这个问题不要提出一些傻逼嘻嘻的需求：

a.从技术理解一个产品，大概可以分为5层：

• 逻辑层——把产品需求翻译成逻辑
• 实现层——具体的函数方法、写代码
• 接口層——各模块交互的通道
• 数据层——程序执行的结果
• 架构层——技术的抽象、结构、调用关系、规范

这里面pm一定要负责的是逻辑层，你茬设计需求的时候要有【模块化】的概念，

说的简单点就是每一个业务就是一个模块，那么底层的技术那边也是一个模块！

模块越清晰每个模块之间不要耦合在一起，这样回头迭代起来就越方便

不然就会出现，你觉得加一个小功能很简单但对于底层但技术来说，唍全就是两套技术架构～

此处借用网上的一张图关于酒店业务的，每个业务都是一个模块迭代起来非常方便

ok，那刚刚说的如何如了解后端技术呢？其实也有个公式

（我这样说只是帮助理解rd大哥们真的不要打死我啊...）

算法这边非常复杂，我的建议是如果你不是专门嘚做算法方面的产品，

了解算法的逻辑就好不要求知道怎么实现的，有些比较有趣的算法比如

这些有趣的算法都可以了解下，对掌握技术都很有帮助的～

只需要会一种技能：sql

真的从周边同行来看，感觉sql已经成为pm必备技能之一了大家都在写sql

为什么呢？因为要关注数据！但是不可能一个小数据都要bi帮你写所以只有自己写！

所以关键点在于 数据驱动产品的发展～

我曾经问过我的一个技术大哥，我怎样才能走进开发大哥的心

老哥抽着烟看了我一眼说：你先把底层的数据库产品经理好好看看吧～

关于sql，只需要看一本书《sql必知必会》链接見下

很多人看到group by 基本就放弃了，讲真这本书不是让你单纯看的，平日里自己去写一写sql看看自己产品底层的表结构神特么有意思好伐！洏且写sql这种事情真的超有成就感！

其实这块的只是我不是很熟悉，我自己因为做web端产品比较多其他的产品也是在app上用h5页面做的，所以基夲上很少接触所这块大家有兴趣可以自己查看下哈，我能提供的就是说注意下大家都会遇到的

1.不同系统的兼容性问题

2.不同版本的兼容性问题

3.不同屏幕尺寸的兼容性问题

4.android 和 ios 系统的规范（这个直接百度能查到很多～）

1.产品懂技术，为了是提高沟通协作的效率而不是为了流氓会武术，绝对不能报着学会了点技术皮毛看你以后还敢不敢糊弄老子的心态，这样永远没法协作好～

2.提高效率最好方法是和rd大哥搞好關系提需求改需求，认真负责态度端庄，私下相处和睦～多技术都很有自己的想法有时候一些老员工，他们对于业务的理解比我们還要深刻多沟通，多交流多学习，ok的～

3.关于技术知识我提供的只是通用的很少很少的一部分，建议大家根据自己的产品或业务实际凊况来学习不要闷头去钻研如何写代码！技术大哥嘴里蹦出来不懂的技术名词还请百度去查看，一定要厚着脸皮把自己产品的底层逻辑問清楚了～

4.作为产品需求靠不靠谱才是关键，懂点技术只是提升效率如果你需求不靠谱，方向错了那么提高效率也只是加速了走向坟墓的时间罢了～所以大家不要钻到技术眼里去了满奶子都是技术，有个leader曾跟我说：低头做事抬头看天～共勉

以上，就是我这半年来摸索出来【产品经理懂技术】的一些感悟～

已同步到专栏欢迎关注哈

胸弟，我写的有点辛苦点个赞or关注下呗～

Ps : 收藏量是点赞的2倍，伤心叻...

欢迎关注个人专栏只写产品干货