做一个懂技术的PM？

产品经理可谓是一个需要各方面能力的岗位：罩得住程序猿、哄的住设计狮、要怼得过客户，还得应付得了老板。要不要学技术，更是一个老生常谈的话题。笔者根据平时积累的经验做一些分享，希望和大家多多交流。

首先简单介绍自己：九零后学生物非技术出身目前搞云计算的产品经理。所以，在学习相关专业技术的方面有一些心得体**，和大家分享一下。希望给一些非技术出身的产品新人一些经验，如有不足之处也欢迎各位产品大牛给予指正。

问题

• 作为产品当你给研发小伙伴提需求后，肯定听过这几字：实现不了！如果你脸皮够厚的话肯定**反问一句，不就是根据手机壳换个APP主题颜色么，有啥实现不了的……
• 即便研发同学说可以做！但是研发成本比较高，需要xxx个人天的工作量才能开发完，现在其他需求排满了没有时间做，你内心又想改个颜色需要这么长时间么。

其实也都是开玩笑的例子，但是在现实工作中，一个需求提出来，可能是老板提的、客户提的或者是产品自身提的，作为产品首先需要评估这个需求的优先级以及可行性。而在评估的时候不需要明白需求具体的代码实现方式，但是大方向的实现逻辑一定要懂，只有这样才不**和研发提出一些不合逻辑的需求：

• 比如设计列表的筛选条件的时候，要知道列表的查询都是通过SQL语句实现的，你得明白SQL是什么，通过SQL语句大致都能对数据进行哪些操作。
• 对接第三方系统的时候，第三方提供哪些API，可以实现什么功能最好要做到心中有数。
• 从另一个方面来说，你想实现什么功能，需要什么API来实现需要和研发沟通后，让第三方进行提供（首先是第三方能提供定制化的API作为的前提）。当然这种情况一般产品只需要把需求讲清楚，需要哪些API是研发来输出即可。但是，如果产品懂一些的话**很大程度上提高沟通的效率。

类似于这样的例子不胜枚举，总之产品这个岗位，个人认为还是需要懂一些技术的，下面就大概讲一下如何学习技术方面的相关知识。

如何学习？

笔者本身是非科班出身（大学中计算机公共课只学习了一些计算机的基础知识，语言学的还是VB……）。学习技术知识首先要有高效学习的方法。其次需要根据自身情况确定一个学习的范围。

学习方法

• 最高效的方法还是参考前辈们的经验，笔者在刚转行的时候买过一些书籍，其中也介绍了一些产品为什么要懂技术，大概都要学什么东西，对于当时还是产品&技术小白的我受益匪浅，叫什么名字就不提了以免打广告。
• 其次，如果你需要了解需求的底层技术，去一些技术论坛搜一下如何实现相应的功能，一般都**有一些文章，多看看几篇了解基本的原理即可。
• 在平时工作中你的研发小伙伴也是你的良师益友，遇到问题虚心请教，一般情况下大家也都**知无不言的。

总之，学习方法千千万，我说也并不一定适用你，一定要找到适合自己的一套学习方法，才能更高效提升自己。

学习范围

需要学习什么内容是需要根据公司产品情况、负责的项目、负责的功能模块有针对性的学习。

• 比如：负责的产品是APP，一定要了解IOS/安卓的客户端知识，二者的区别，交互规则都是怎样的。
• BS架构的产品，客户端则是web浏览器，用户操作界面当然也是依托浏览器进行，相应可以了解前端的相关知识，比如：html、CSS、JavaScript等相关知识。
• 客户端只是做页面可视化的展示和少量的事务处理，而应用主要的事务逻辑在服务端实现，这又引入了服务端的内容，服务器是什么？前后端是如何发生交互的？接口是什么东西？
• 有的时候服务端将前端提交的数据处理后需要保存到数据库中，数据库顾名思义当然是保存数据的东西，其中比较常用的是关系型数据库，例如MySQL。
• 现在很多云服务商也提供很多对象存储的产品，用于存储非结构化的数据（图**、视频、音频等）如有需要也可以了解一下。
• 笔者所在公司的业务是做云计算的，与公司业务息息相关的知识更需要学习，例如：云服务器、云数据库、弹性公网IP、对象存储、负载均衡等等。

对于小白同学来说，如果有明确的方向，那就针对性的规划学习范围；如果没有明确的方向，建议每个方面的知识都要了解一些。

说到这里想起来有一点是基本上都必须要了解的，就是一些计算机的基础知识，当下比较流行的编程语言都有什么；数据都有哪些类型，它们具体表示什么；程序是怎么进行一些逻辑判断的等等。

笔者最早也曾尝试过转型做程序猿，自学了一段时间的计算机基础知识和java编程。后来转做产品后以为当时学的一些东西没什么用，毕竟不用写代码。但是，在实际工作中逐渐发现之前积累的技术知识，对于产品设计还是很有帮助的。

踩过的坑

虽然有些技术是产品必须要学习的，但是千万不要被技术扰乱我们的产品思维。

曾经有一段时间，当我接到新的需求后，首先想到的不是用户使用场景，不是用户背后的真实需求，而是从技术的角度考虑如何去进行产品设计，想的是背后的数据库、表如何设计。可想而知，当这个需求实现后也仅仅是能用，用户体验极差，甚至做出来的东西都不是用户真实想要的。

一度为了迎合技术实现，从而忽略的产品设计的本质。为了实现某个需求，过度的关注在技术层面的东西，从而忽略了产品经理存在的意义。产品经理的存在就是保证做出来的需求是用户的真实需求，而研发的意义才是将需求变为现实。

假如说根据手机壳颜色使得APP主题颜色切换，看似是个荒谬的需求。但是，如果把他实现了公司**得到无法想象的巨大收益，那么我相信他一定能实现。至于具体怎么实现，就不是产品经理需要考虑的范围了。

举个学习例子

系统：XXX后台管理系统

功能模块：工单管理

用户：后台管理员，确切的来说是处理工单人员

需求描述：当控制台客户端提交一条新的工单后，在后台管系统中，需要有这条的工单消息提醒，以达到提醒工单处理人员对有新的工单需要处理。

当将这个需求和技术人员进行简单沟通后，我们公司的技术小牛说到：“可以用websocket来实现工单消息的实时提醒功能”。

听的我一脸懵~赶紧百度百科了一下：

WebSocket protocol 是HTML5一种新的协议，它实现了浏览器与服务器全双工通信(full-duplex)，一开始的握手需要借助HTTP请求完成。

原理

WebSocket同HTTP一样也是应用层的协议，但是它是一种双向通信协议，是建立在TCP之上的。

连接过程——握手过程

1. 浏览器、服务器建立TCP连接，三次握手。这是通信的基础，传输控制层，若失败后续都不执行。
2. TCP连接成功后，浏览器通过HTTP协议向服务器传送WebSocket支持的版本号等信息。（开始前的HTTP握手）
3. 服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据。
4. 当收到了连接成功的消息后，通过TCP通道进行传输通信。

目的：即时通讯，替代轮询

网站上的即时通讯是很常见的，比如：网页的**，聊天系统等。按照以往的技术能力通常是采用轮询、Comet技术解决。

三种技术对比分析

1）http请求

开始单纯采用传统http请求响应客户端服务器，http协议是非持久化的，单向的网络协议，在建立连接后只允许浏览器向服务器发出请求后，服务器才能返回相应的数据。

当控制台客户端提交一条新的工单后，后台管理系统中不**主动收到提醒消息，需要手动**新网页（后台管理系统主动请求服务器）后才**弹出新的工单提醒。

造成如下后果：

1. 不能保证消息的时效性，新的工单信息不能被后台人员即使看到并进行处理；
2. 如果用户有紧急问题需要咨询处理，耽误时间，影响用户的业务发展，甚至可能**丢失用户；
3. 增加了后台工单系统的运维成本，工单处理人员需要随时**新网页查看是否有新的工单。

2）轮询

通过轮询在特定的时间间隔（如1秒），由浏览器向服务器发送Request请求，然后将最新的数据返回给浏览器。解决了消息时效性的问题，但是需要每一个客户端每秒都需要向服务发送请求。

通常HTTP request的Header是非常长的，为了传输一个很小的数据 需要付出巨大的代价，是很不合算的，占用了很多的宽带。

3）websocket

采用websocket后，只需要服务器和浏览器通过HTTP协议进行一个握手的动作，然后单独建立一条TCP的通信通道进行数据的传送。当控制台客户端提交一条新的工单后，后台管理系统中直接**弹出新的工单提醒。

如下优势：

1. 保证消息的时效性，新的工单信息及时被后台人员即使看到并进行处理；
2. 优化了资源利用率；
3. 减轻后台工单系统的运维成本。

小结

其实websocket应用之处还有很多，因为建立一条TCP的通信通道，利用这个持久性的特点，可以看到系统当前在线人数有多少。

而他的实时性特点，也是一些办公协同工具（在线多人同时编辑文档）所必须要用到的，等等可以实现的功能不再赘述。

看似很专业的技术知识，其实笔者也只是了解它是什么东西，有什么特点，利用他的特点能实现什么功能而已，而作为产品我认为能了解到这种程度已经完全够用了。

总结

笔者作为To B的后台产品经理，起码在这个领域的产品岗位还是需要懂一些技术知识的。

首先，To B的产品经理，需求来源方首先就是甲方爸爸，与客户沟通，对接第三方相关需求，也**涉及到一些技术相关知识。如果不懂的一点的话，沟通效率低，成本比较高。笔者之前接触过类似的与技术相关的需求，比如：集成第三方SSO单点登录服务、接入第三方用户体系、实名认证体系、接入第三方支付功能等等。

其次，前端产品经理可能更注重一些界面设计、用户体验更加的交互方式等等（个人见解，前端产品看官勿喷）。而后台产品的话更多的根据复杂的业务逻辑去呈现不同的表格、数据，对应的需要根据不同的条件去搜索数据，对接哪些API来实现需求。后台的产品设计，一些功能设计更多的是由技术进行主导。了解一些技术实现方式，对产品的理解也**更深一些。

比如：在实现系统初始化相关功能的时候，能够初始化哪些内容需要和技术同学配合进行。

技术同学提出可以配置系统中使用的短信服务的相关配置项：短信签名、模板信息，还比如可配置系统使用的邮件服务相关配置项，邮件服务地址、用户名、密码等。

但是，在后续测试过程中技术发现存在问题，系统使用的spring cloud框架已经集成了邮件配置的相关功能，在服务启动的时候必须有邮件的相关数据，否则系统启动不起来——换句话说邮件的相关配置信息需要提前配置好，不能在系统初始化中进行配置（其实和技术沟通后，也可以通过修改框架源码的方式或者通过API的方式去实现邮件的相关功能，但是综合考虑起来目前没有必要为了初始化的需求去进行其他的改动，故先将邮件的配置项从初始化步骤中删除）。

简而言之，请对技术怀有一颗敬畏之心，了解技术实现边界，做一个懂技术的PM。**让你设计的产品更合理，让沟通交流更加顺畅，让技术同学更加信任你，让你在成为PM大牛的路上事半功倍！

在产品的路上一直都是在借鉴前人的经验，是时候回馈一下社**了！以后努力把一些工作中的心得、体**分享一下，希望帮助到需要的人。

作者：天气不错，公众号：天气的朋友（friends_of_tianqi）

本文由@天气不错 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议。

给作者打赏，鼓励TA抓紧创作！

**赏

1人打赏