Tech：产品与研发的沟通相处

新人小朋友问

做产品工作三年，遇到过不少程序员，我不懂代码，遇到不擅长表达的程序员就很难打交道。但我觉得产品经理应该只需要关注需求本身吧。如何能够最省人力地解决问题，才是最终目的。至于代码问题定位排障之类的，应该由开发和测试人员确认（不过也应该学会查看基本系统工具，例如开发调试工具）。

研发人员眼中的好产品经理

我不是产品经理，所以可能无法直接回答这个问题。但是可以从研发人员角度说几句。

两者之间的沟通越简单越好，通常就是三板斧。

有数据谈数据。没数据就谈逻辑。如果既无数据又无逻辑，那只能谈感情了。

谈感情靠什么？靠颜值？肯定不全是。更多的是靠历史过往合作口碑，也就是“靠谱”。

所以有时候产品需求直接抄袭竞品，对于研发人员来说，也不是坏事。毕竟竞品大概率是有数据有逻辑的。总比遇上“不靠谱”的产品经理胡编乱造牵强附会的好。

研发人员眼中的坏产品经理

1. 狐假虎威型
   “这是xx高管的指示，就这么做，立刻上线”。
   “这是xx总亲自提的需求（问题），必须最高优先级解决”。
   “我已经对上对外承诺了上线时间，你们必须做到”。
   这种都是大SB产品经理。

2. 击鼓传花型
   最近见到的一个案例。
   “这是公司高层重点战略方向，关注度极高。需求PRD已经写好了，你们两天开发完成上线”。
   这个项目确实是重点，不是狐假虎威。但是从高层提出到产品需求完成，一个多月过去了。流转到研发人员这里就期望一周内上线。
   搞得好像是击鼓传花，研发人员最后捧到了炸弹。

3. 极端数据驱动型
   “数据驱动”本身没错，但是也掩盖了一些弱者产品经理的肤浅思考和决策无能。产品方向上广撒网，ABTest恨不得穷举所有分支，然后根据数据挑好看的结果。

4. 金鱼脑型
   用户投诉A方案，马上就换B方案。用户投诉B方案，马上又换A方案。就像只有几秒记忆的金鱼似的，只关心当下短期，缺乏中长期规划方向。

---

至于是否需要掌握代码问题分析排障。其实不需要。我们研发人员也没奢求产品经理做到这一步，我们自己能搞定。只需要当问题发生时，产品经理能快速准确的界定清楚范围即可。