产品经理与研发团队的协作，从来都是一场微妙的博弈。本文深度剖析7类典型研发人员的沟通风格，从技术大佬到流程依赖者，为你解锁高效协作的实战密码。掌握这些黄金沟通法则，让需求推进不再卡壳，产品与技术的配合更加丝滑流畅。
最近工作有点忙，但总觉得该写点什么，记录一下这几年和研发老师们“相爱相杀”的那些事儿。
在B/G端做产品久了，慢慢觉得，很多时候对技术本身的要求反而没那么玄乎——只要沟通顺畅，大部分事情都能商量。技术不支持或者实现太费劲？坐下来聊透，往往就有出路。
当然，这里不谈个人恩怨，只聊对公的合作模式。我遇到的研发大概可以分为这几类，欢迎对号入座，也欢迎补充。
这种老师往往是一家公司的技术天花板，经验丰富，什么大风大浪都见过。我们公司的研发负责人就属于这种。
跟他们沟通，最怕的就是你什么准备都没有，开口就是“能不能实现”。我一般会提前把背景、目标、用户痛点、用户故事都理清楚，配上初步设计和市场调研结果，再去找他们聊可行性。
大部分这类老师都很耐心，甚至能给你指出更优解。不过偶尔也会遇到他们觉得“这点小事也来找我”的情况，这时候就得自己掂量一下问题是否值得占用他们的时间了。
这种研发老师逻辑极其清晰，善于发现需求里的漏洞和模糊点。他们不轻易接受“大概”“可能”“到时候再说”这样的表述。
和他们合作，需求文档必须写得清清楚楚，流程图、状态定义、边界情况一个都不能少。他们可能会反复确认细节，有时候甚至让人觉得有点“轴”，但事实证明，他们的较真往往能在上线前避免很多坑。
沟通时最好保持耐心，用逻辑说服逻辑，他们认可了，推进就会非常顺畅。
他们平时话不多，群里不活跃，但给的任务通常都能按时完成，只是不太主动汇报进度。
对于这种老师，定期主动跟进是关键。不要等 deadline 才问，中途可以温和地问问“有没有遇到什么阻塞”“需要我协调什么资源”。他们往往不擅长表达困难，所以产品经理得多留心，主动铺好协作的路。
他们思路活跃，乐于发表看法，有时聊着需求就跑偏到技术实现细节或者新产品 idea 上去了。
和他们沟通需要适当控场，尊重他们的热情，但也要温和地把话题拉回主题。可以这样说：“你这个想法很有意思，我们记下来后续慢慢聊，现在我们先把这个版本的需求定下来好吗？”
这种人通常很好相处，合作起来不累，只是需要一点引导。
通常是刚工作不久的同学，有冲劲，愿意尝试，但经验尚浅，有时候对业务理解不够深。
和他们配合，多解释背景和为什么做比做什么更重要。他们可能需要更清晰的任务拆解和示例。适当鼓励和肯定，他们会成长得很快，也容易建立起长期信任。
他们对改动比较敏感，喜欢用旧逻辑和旧代码，容易提出“这个没必要”“原来那样就行”之类的意见。
这时候不能硬碰硬，得多从业务价值、用户反馈和数据角度说明为什么必须改。如果技术上确实有负担，可以一起讨论分阶段实现的方案，降低对方的抵触心理。
（避个雷，有时候就是需求写的不完善，想的不到位，研发老师觉得这个还是欠缺一些内容，遇到事情首先检查一下自己有没有不到位的，但如果不是自己的问题，或者自己已经尽力完善了，请不要内耗，遇到事情先尝试解决，协调不下去及时汇报领导）
最近还遇到一类老师，让我有点哭笑不得——他们的标准开场白是：“这个要提单子走流程。”
等你好不容易把流程推到位了，他们又说：“这个技术上不太能做啊。”
这时候你只好同步领导，把前因后果、技术卡点都整理清楚。领导也重视了，说：“那安排个会，大家一起看看技术难点在哪儿，集思广益一下。”
结果到了会上，研发老师突然改口：“其实也没啥困难，可以做。”
我：？？？那之前是在干嘛……
后来想想，他们可能最初并不想接这个需求，就用流程和“技术壁垒”作为缓冲；等到不得不正面讨论的时候，发现理由站不住脚，就干脆应承下来。
和这类老师打交道，尽早拉通、明确节点、保留沟通记录特别重要。必要时可以温和地问：“如果现在评估下来可以做，那我们能不能一起排一个具体的完成时间？”避免反复消耗团队信任和项目进度。
其实无论是哪种类型，总结下来就几个原则：
尊重对方的专业领域（重中之重），技术可行性一定要一起评估；
最后想说的是，产品与研发从来不是对立关系，大家都是想把事情做好。沟通的本质是协作，而不是说服。遇到问题，坐下来，开个会，点杯咖啡，往往比发一堆消息更能推进事情。
（以上纯属个人观察，如有雷同， maybe 我们合作过？hhhh）
本文由 @Serencry 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。