产品经理不妨多一些技术思维

一、PM与RD的恩怨情仇

先看两个段子：

段子1：产品经理被绑，蒙眼。惊问：“想干什么？”，对方不语，鞭笞之，产品经理求饶：“别打，要钱？”，又一鞭，“十万够不？”，又一鞭，“一百万？”，又一鞭。产品经理崩溃：“你TMD到底要啥？”。“要什么？”我帮你做项目，写代码的时候也想知道你TMD到底想要啥！”

段子2：

来自网络

二、PM与RD互评

PM眼里的RD分成两种：能沟通的，和不能沟通的。后者占90％。(RD们请不要对号入座!!!)

对于没有技术背景的我们来说，90%的RD是无法沟通的。好不容易搞定老板，加班加点终于把需求整理出来，以为万事俱备，只欠开工。不曾想，这只是噩梦的开始。

当我们激情澎湃的把需求宣讲一遍后，内心期待是RD们同样激动的眼神，然而事实是他们安全无动于衷。“靠谱”的RD同学们还会问“这个什么时候上线？交互什么时候出？设计稿什么时候给？”，“刺头”RD们已经按奈不住内心的愤怒“这些都是什么鬼？这个需求做过调研吗？对线上业务有帮助吗？有数据支撑吗？这又是老板们拍脑袋出来的？”。

RD眼里的PM也分成两种：有脑子的，和没脑子的。后者占90％。(PM们请不要对号入座!!!)

有没有脑子，说的是思维(思考)能力。

PM需要有自己的思考力。理想是丰满的，现实是骨感的。大部分情况下产品经理的生存环境还是很恶劣的，因为老板是最大的PM，很多的决定都是身不由己。这个时候一定千万别使用“老板说的必须要加xx功能”，直接断送了你的价值，以后会更被动。你可以把你的思考客观的告诉RD们，以及老板们考虑的角度，为什么现在要这样做。虽然这并不能改变需求，但这样起码能让RD觉得你是思考过的，并不是一味的做搬运工。

PM需要信任RD。经常遇到这样的场景：PM问这个功能需要多长时间开发，RD说需要1个月。PM开始不淡定了，内心闪过这么简单的一个需求还需要那么长时间。于是私下找玩得好的做研发同学(同事)问这个功能要开发多久。久而久之，PM与RD间仅有的一点信任荡然无存。

三、PM技术思维速成

1. 了解原理

我们毕竟不是RD，不需要知道这个接口如何实现，那个变量如何调用，是不是有内存泄露问题。但是我们要清楚知道开发实现这个功能的原理是什么，大致思路是怎么样。没吃过猪肉，至少做到见过猪跑吧。

那么问题来了，了解一个原理有多难？可能并没有你想的那么难。举个例子，我们经常和研发沟通中都会提到的http请求。这是什么鬼？打开wiki，输入http，花个10分钟就能了解HTTP原理：

来自Wiki

2. 知晓边界

哪些能做，哪些不能做，哪些将来达到一定条件后能做。比如iOS系统对应用访问系统权限做了很多限制，比如应用无法获取手机号，无法获取设备ID之类的。

这些东西需要PM平时多关注和了解些基础，比如Android/iOS平台特性之类的，官方的介绍文档是一个很好的开始。另外在日常工作中跟RD沟通中都会涉及到很多基础的知识，小本本可以记起来。经过一段时间积累后做相关的需求时，也知道边界在哪，把这些影响提前考虑到。

另外边界并不是一成不变的，随着设备的不断更新，OS的迭代。之前是边界的问题可能到了后边的版本就不是了，反之亦然。

3. 评估成本

牛逼的开发不管什么需求，给你的答复永远都是可以做，只是时间长短问题而已。实际过程中不可能存在这么理想的情况，大部分情况下PM需要去权衡投入产出比。通常情况下，PM为了追求极致的体验(一定要有追求极致的思想)，会要求RD严格按照方案开发，导致投入了大量的资源，达到了最终效果，但实际上收益却并不大。

4. 组件化

什么是组件？组件是经过设计元素解耦，具有标准规范和可复用场景的基本模块。对于一些功能比较复杂到产品比如滴滴出行，包含了很多业务线，是不是每条业务线都要从0开始呢？结论显然不是。一些跟业务耦合性不强的组件都可以排上用场，比如地图服务，冒泡服务，计价服务等等。这样可以极力解放PM的生产力，专注于业务本身，而不需要耗费额外经理去重新造轮子。关于组件化后续再做一次专题分享，这次就不深入聊。

四、写在最后

不管是RD，还是PM，最终的的属性是人。人与人和谐相处的第一前提永远是：平等、尊重与理解。多站在对方的理解思考，会有意向不到的收货。