赢得研发信任的日常动作：PM的软实力清单

微信扫一扫，分享给好友

关闭

First Round Review对大量产品与研发合作案例的访谈中反复出现一个主题：PM与研发的关系质量，不取决于大项目上的配合，而取决于日常的小动作。信任是在没有大事发生的日子里攒出来的——等上线出事的那天才想建立信任，已经晚了三个月。

研发眼中PM的四个扣分项

• 需求反复：文档今天一版明天一版，且不解释为什么改——改需求本身不是罪，不解释才伤信任
• 越级拍板：和某个工程师私下改了方案，第二天其他人才知道——团队的共识被绕过，比方案本身错得更伤人
• 只在要资源时出现：平时的沟通只有「这个什么时候能好」——PM在研发眼里的角色退化为催单员
• 不懂装懂：用含糊的技术名词掩盖不理解，被拆穿后信用清零——说一句「这块我不懂，你讲讲」反而加分

五个加分动作

• 带着上下文来：「为什么做」讲清楚，工程师常常能想出比PRD更好的「怎么做」——用户价值给足，实现路径放开
• 当面说不清楚的事，写成一段话发出去——但别把文档当甩手掌柜的理由；写完再当面过一遍，三十秒的事
• 把锅接住：上线出问题时PM第一个站出来面对老板和用户，研发会记很久——内部分工技术原因，对外口径产品负责
• 学会一点技术阅读能力：不用会写，但要能看懂方案讨论里的关键词——听得懂「缓存击穿」和「主从延迟」，讨论的深度立刻不同
• 公开致谢具体化：不说「研发辛苦了」，说「这次老王提前发现的并发问题帮我们避免了一次事故」——具体的名字加具体的事，才有记忆点

一个反面案例的教训

某PM习惯在周会上直接给技术方案提修改意见：「这个用个定时任务不就行了？」两次之后，技术评审再也没人主动解释方案权衡，研发只等他举手提问。后来这位PM学了一招：把「我建议改成X」换成「我担心的是Y问题，现在的方案是怎么考虑的？」——同一个担忧，前者是越位，后者是提问。信任的裂缝往往就是从一句越位的话开始，且几乎不可逆。

一个测试关系质量的问题

问自己：上次你带来一个模糊的想法时，研发的反应是「先把需求写清楚」还是「来聊聊想法」？前者是流程关系，后者才是信任关系。

写在最后

信任的积累没有捷径，但有复利：高信任的团队里，需求评审会短一半，返工少一半，好的工程师愿意抢着跟你做项目。这些日常动作就是复利的本金。