RD喜欢和怎样的PM共事？

RD喜欢和怎样的PM共事？

1. 不要只告诉研发做什么，还要告诉研发为什么，收益和价值是什么。千万别说“老板说要这么做”，“运营希望有这个功能”，大家坐一条船，不希望产品是传话筒，大家的目标是一致的，技术想知道这么做的价值。

2. 不要帮研发评估工作量。千万别说“我评估过了，开发工作了应该很少，明天上线没问题吧？”，特别是技术出身的产品经理，技术真的不喜欢这样。

3. 别质疑研发的专业性，就像研发不会质疑产品的专业性一样。千万别说“这个功能微信也有，我们为什么做不了”，“QQ邮箱附件无限制，为什么我们只能只能2G”，希望能有一点技术的sense，理论上，“别人家”技术能实现，我们的技术也能实现，但确实可能没有“别人家”的资源。

4. 尽量别修改需求。互联网的快速迭代节奏技术能理解，但提前想清楚，真的能大大大大减少延期的风险，同时能大大大大加强彼此的信任。技术真的不喜欢改需求。

这里，也为产品经理稍微解释一下，为什么会有这么多需求变化，本质是产品与技术的角色和思维方式不一样：

产品：产品的迭代是一个试错的过程，只要有一个方案成功了，产品可能就成功了，而产品本身试错的成本不高

技术：编码是一个逻辑严谨，无比精密的过程，出一点错也不行，而且试错的成本很高（产品一句话“帮忙改一个交互”，技术从前端后端开发/联调/测试/上线，成本极高）

于是，造成了这个矛盾，解决方案：需要产品经理在前期考虑得更清楚和完善一些。

5. 更加开放的心态。在一些把握不准的点上，能够尝试和技术讨论。产品经验丰富，但希望能够听听研发同学的建议。

6. 别在需求评审完就push我们承诺时间点。产品需要设计方案，技术也需要设计方案；产品需要需求评审，技术也需要技术评审，特别对于复杂度较高的产品功能。

7. 上线后一定要有数据跟踪，效果评估。产品作为舵手，技术希望航向是正确的。技术加班加点，希望知道产品/项目的效果，希望知道付出有价值。

产品技术本一家，只能相爱，不能相杀。

架构师之路--沈剑老师写的一篇文章