微信号:gh_10a6b96351a9

介绍:坚持撰写接地气的架构文章 通往架构师之路,悠远而漫长,一路上,我们同行.

研发喜欢和怎样的产品经理干

2017-08-06 10:15 58沈剑

RD喜欢和怎样的PM共事?


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


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


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


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


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

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

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

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


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


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


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


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


ni(技术/产品)“喜欢/不喜欢”怎样的ta(产品/技术),欢迎留言。

 
架构师之路 更多文章 多对多业务,数据库水平切分架构一次搞定 关于极限头脑风暴的清单 关于高效会议的清单 SQL与索引优化合集 或许你不知道的10条SQL技巧
猜您喜欢 【Docker】利用阿里云容器服务打通TensorFlow持续训练链路 【系统消息】天文台、空调请求添加你为QQ好友 基于Kafka与Spark的实时大数据质量监控平台 JavaScript的性能优化:加载和执行 想构建一个最小可行的产品?从不重复造轮子开始