【灵魂拷问】产品经理是不是需要懂技术？

答案是：懂最好，可以不会编程，但至少要具备基础知识。

这可是我走了很多弯路总结出来的血淋淋的教训！

当我在研一刚萌生想做产品经理的想法时，有人跟我说产品经理要懂技术。

我当时就想我一定要想办法把自己的技术能力提升到一定的水平，再去找工作，不然以后就没机会学习了，至少能做出一个完整应用。

所以，我就努力搞学术，在研一就把小论文发表了，这样就可以出去实习了。

后来，我去了追光动画（王微从土豆离职之后，创办了追光动画，立志做中国的皮克斯，试问现在还有多少人记得土豆网？欣慰的是追光最近出了一款口碑还不错的动画：白蛇·缘起，恭喜老东家）实习，他们当时为了宣传动画想做一款VR产品，戴着VR头盔就能走进电影世界。这跟我的专业太对口了。

做项目用的语言是C#，后来自己在宿舍自学了JAVA教程，找了一个入门教程一段一段的敲代码。

等我真正做了好长时间产品经理之后，发现做产品其实不需要会编程。懂技术不等于会写代码。

懂技术的目的是：了解自己产品的实现逻辑，从而更好的跟研发沟通。

作为产品经理，只需要知道如下几点：

•从技术角度看，一个互联网产品的结构是怎样的，各自承担什么功能（例如：前端、客户端、后端、数据库等）。

•从技术角度看，当用户进行某种操作后，程序运行的基本逻辑是什么（例如：前端的操作控件如何提交请求到后端服务器，经过什么样的处理，如何返回结果等）。

•对其他常用的技术细节有概念。

所以，在这举两个例子，相信你就会对程序的运行逻辑有个全面的了解。

案例1：在网页上登录（B/S结构）

B/S结构即浏览器（Browser)和服务器（Server)结构。我们访问一个网站，输入正确的用户名和密码后，点击“登录”按钮，过一会儿，我们就看到了自己账户中的内容（例如余额数字）。这个过程司空见惯，但是从技术角度来讲，上述这句话描述的过程的具体实现逻辑可能是下图所示。

第1步，用户在浏览器中输入网址，按回车键，这时浏览器通过网络连接到服务器，向服务器索取这个网址所对应的网页内容。

第2步，服务器找到对应的网页内容（源代码），然后通过网络将这些内容传输给浏览器。

第3步，浏览器得到这些源代码，然后将其解析成网页展现给用户。此时用户看到两个输入框，分别是“用户名”和“密码”，同时有一个“登录”按钮。用户输入正确的用户名和密码，点击“登录”按钮。

第4步，浏览器再次连接服务器，将用户输入的内容传输给服务器，并告诉服务器，用户要执行登录操作。

第5步，服务器知道了用户的意图，获取到用户输入的用户名和密码这两个数据之后，紧接着连接数据库，将“用户名”这个内容传给数据库，要求数据库提供相对应的“密码”字段内容。

第6步，数据库找到相应的内容，然后将“密码”信息返回给服务器。

第7步，服务器将用户输入的“密码”与数据库返回的“密码”内容做对比。假设对比的结果是“一致”。

第8步，服务器找到该用户登录之后应该看到的网页内容，但是“余额”这个具体数值服务器不知道，于是它再次向数据库（注：不一定跟上一次是同一个数据库）询问这个用户的余额是多少。

第9步，数据库接到请求，找到余额数据，并返回给服务器。

第10步，服务器再次将这些网页内容（源代码，包含余额信息）传输给这个用户的浏览器。

第11步，浏览器得到这些源代码，然后将其解析成网页展现给用户。用户看到了登录后的网页上面有他的余额数字。

由此，我们可以得到下述结论：

1、一个简单的登录操作，在最简化的模型中，是由浏览器、服务器和数据库这三个环节协同完成的 (实际情况更复杂，可能还涉及 DNS解析等）。

2、浏览器可以解析服务器传来的内容，显示给用户，就成了用户看到的“网页”。点击网页上的“登录”按钮，网页可以向服务器提交数据，服务器可以处理这些数据，是因为网页和服务器上都有相应的“程序”。

3、在上面描述的过程中，浏览器就像是一个空売，其内部显示的不论是内容本身（例如“余额数字”），还是非内容的UI和功能部分（例如“‘登录’按钮”）都是由服务器传输给它的。

4、所有的关键数据都存在数据库中。

案例2：在手机客户端上的发图片(C/S结构）

C/S结构即客户端（Client)和服务器（Server)结构。如果你正在微信发朋友圈，或者发微博，从手机相册中选择一张图片，写几句话并发送，过一会儿，你的好友就可以看到这张图片和这几句话。这个过程听起来也很简单，但是从技术角度来讲可能会经历下图所示的逻辑过程。

第1步，用户A打开手机上的某社交类应用客户端，想要选择一张图片。这时，该应用客户端程序向手机操作系统（如i〇S或Android)请求访问手机相册，得到允许后，列出相册中的所有图片供用户选择。用户A选了一张，原图的大小为5MB，并写了几句话，按下“发送”按钮。客户端程序发现这张图片太大了，使用4G传输会很慢而且会耗费大量的流量，于是自动将其进行了压缩。

第2步，客户端程序使用网络连接服务器，并将压缩过的图片和那几句话传输给服务器，同时告知服务器，这些内容是“用户A”产生的。

第3步，服务器接收到客户端程序传来的内容，连接数据库，将这些内容存储在数据库中，并标记好是“用户 A”的内容。

第4步，数据库完成存储工作，然后通知服务器，存好了。

第5步，服务器接收到数据库的通知，然后通过网络将这个信息通知给用户A手机上的客户端程序。这时，客户端程序在用户A的手机屏幕上显示一个“发布成功”的提示。

第6步，这时，用户B也打开了安装在其手机上的该社交类应用的客户端程序，他跟用户A是好友，程序自动通过网络向服务器发出数据请求，要求服务器返回用户B的所有好友的内容。

第7步，服务器接收到请求，连接数据库，希望得到某个时间节点之后用户B的所有好友的内容。

第8步，数据库找出用户B的所有好友在这个时间点之后产生的内容(其中包括刚才用户A发送的图片和文字),然后按一定格式返回给服务器

第9步,服务器接收到数据库传来的数据(有图片、文字),然后将其通过网络传输给用户B的手机客户端程序。

第10步,用户B的手机客户端程序接收到数据,然后刷新用户B的手机屏幕上的内容。这时,用户B看到了用户A发送的图片和文字。

通过这个案例,我们可以得到更复杂一些的结论：

客户端软件往往不只是一个用来装内容的壳子,它还具备一些功能逻辑,例如压缩图片的功能，这些功能都是开发工程师写代码实现的。
在上述流程中,客户端程序和服务器之间交换的是纯内容数据,不包含UI和功能部分,因为后两者都已经做在客户端程序里面了
一般情况下,客户端的使用体验应该比网页更流畅一些,因为它与服务器只需要相互传输内容数据,不需要传输UI和功能。同时,网页与服务器之间的数据交互需要通过浏览器这个媒介,所以必然要受到浏览器的一些限制;而客户端则直接与服务器交互,听起来后者应该性能更好,可以做到的事情更多一些。

综上所述,我们可以看出,即便是两个最简单、最常见的操作流程,背后对应的技术实现逻辑也是非常复杂的。作为产品经理,要能够理解这些基础的技术逻辑,这样才能与工程师相对流畅地沟通。