首页> 关于产品经理需不需要懂技术，这是一个被反复拿出来讨论的问题。
我的观点是：“产品经理无需具备技术能力，但需要具备技术思维”。
先想想这些场景你有没有经历过：
是否体验过被工程师问住的感觉？
谈到技术点，就有种话到嘴边就是说不出的堵塞感，很不好受！
聊产品价值、用户需求好好的，结果来一句“这个写死了，要改架构”，想摔电脑的心都有……
这个时候你会想，我要是会懂技术该多好，至少可以diss回去！
今天老原就从3个方面来聊聊产品经理和技术的关系：
1、产品经理要懂技术吗？
2、对技术要了解到什么程度？
3、要如何培养技术思维（必会的10个技术名词）
01
产品经理要懂技术吗？
在以前，「技术」在产品经理的能力模型中是加分项；放在今天，应该是必须项。
01 懂技术有什么优势？
不懂技术的产品经理吃过的苦只能自己咽，而懂技术有多香呢？
首先，做过开发的产品经理在沟通上占优势。
其次，掌握适当的开发知识便于我们提需求的时候可以考虑技术的可行性与投入成本，在跟开发沟通、转达需求的时候能够更有效率。
02 产品经理成长必备能力
项目经理除了和需求文档、原型图打交道，就是需求沟通，团队协作了。
与工程师沟通需求、讲解设计逻辑、跟进开发状态、随时解决工程师的疑问，这些占据了初阶产品经理的大部分时间和精力。
不是每一位工程师都有产品思维，别太指望工程师能使用用户语言和产品语言来和你沟通。
如果你碰巧碰见了，那是你的幸运。我以前也遇到过这样的工程师，那种感觉怎么说，心里暖暖的，让人觉得非常欣慰！
所以，掌握「技术语言」是非常关键的。技术思维+产品思维去解决问题，是初阶产品经理成长的第一步。
接下来，你成为高阶产品经理，已经不需要亲自去和技术人员互动沟通，更多是在战略、商业的角度去思考问题。
但此时，好的技术思维同样可以在你判断产品机会时有所助益。毕竟互联网产品都是基于技术发展的。
看到这，你觉得产品经理需要懂技术吗？
02
要懂到什么程度？
“产品经理无需具备技术能力，但需要具备技术思维”。
懂技术，不是让你从入门到精通掌握一门技术能力，而是需要具备基本的技术思维。
技术思维=技术原理+基本概念
举个例子，可以跟着我的思路来感受一下。
当你想要让开发在用户信息中添加一个字段。基本的流程是什么？
1、界面增加一个位置显示这个新增字段
2、在数据后台的数据结构中添加一个字段记录相关信息
3、需要前端来解析这个新的节点
4、需要后端修改好接口。
5、考虑到新旧版本的兼容。
而如果你在想要达到一个功能时，能有这样一条清晰的步骤在脑海里，那你基本上具备技术思维，这里需要你去敲代码吗？并不需要。
因为你了解数据结构、前后端交付模式以及数据兼容，你可以很顺利的去协同处理产品问题。
03
掌握「技术名词」是技术思维的第一步
那要怎么培养技术思维呢？
思维和能力不同，能力可以通过参加培训、多做技术练习来入门和提高；
但思维，在掌握基本的原理后，根据每个人的经验特点加以融合。
你要重复实践，积极复盘，复盘得到的结论不断积累，形成属于你自己的技术思维。
虽然每个人的认识和理解都不尽相同，但如果有个老师指导，会让你少走弯路。
今天老原为你整理了10个基本技术概念，助你形成自己的技术思维。
01 数据接口（API）及数据传输格式（XML、JSON）
1、API全称应用程序接口。是客户端与服务端之间的通信接口，比如登录功能，发起方式客户端，调用服务端开放的登录接口，然后进行数据传输和验证，期间完成数据请求和数据响应。
API是服务端开放出来的应用能力，例如登录接口、支付接口、分享接口等。
举一个形象的例子，接口就是墙壁上的插头，有两口的也有三口的，这项能力是由电网对外开放的能力。
2、JSON和XML都是数据传输格式。客户端向服务端发起请求后，需要将客户端的数据传输给服务端，而JSON和XML就是扮演数据载体的角色，JSON和XML是一种数据格式，好比两种不同格式的信纸，同一种数据内容分别可以以这两种不同的格式来进行传输。
02 高并发
高并发指的是web系统在短时间内遇到大量请求的情况。
比如双11活动、春晚抢红包活动。
高并发会导致系统在这段时间内执行大量操作，比如对数据库的操作、对资源的请求。如果高并发处理的不好，可能会导致请求响应过慢，甚至系统崩溃。
解决高并发的问题一般需要通过各个方面进行优化，包括增加服务器、限流、降级非核心功能、算法优化、数据库优化等方式。
03 日志
日志是开发为了跟踪用户行为和代码异常而打的记录。当一个请求到来时，后台一般会登记以下几种日志：
1、第三方服务日志。
如果后台调用了第三方服务，比如接入了公司内的统一登录服务，当调用该登录服务时，就记录这些行为。有利于排查问题时区分本服务日志和第三方日志。
2、SqlLog-数据库查询日志
一般会记录SQL查询语句、数据库名表名、查询耗时等指标。可能会用于排查SQL错误、优化SQL语句。
3、AccessLog - 用户访问日志
一般会记录请求URL、请求参数、用户ID、行为发生时间、接口返回值等几个关键指标。
4、Exception-代码异常
代码异常一般会记录报错信息、报错发生的代码是哪一行、报错发生时间等指标。代码异常日志是最重要也是经常要看的日志，根据报错可以快速定位到发生错误的原因，快速地修复问题。
04 定时任务
定时任务是：指定每到一个时间点，就执行一个固定任务，这个任务一般是一个计算脚本。
比如指定每天晚上凌晨，把一个库的数据通过一定的计算规则，把数据转换后，再同步到另一个库。定时任务是后台用来批量处理数据的常用方式，并且是实时性要求不高的批量数据。
05 同步处理和异步处理
同步和异步是开发技术中的两个概念，计算机通过解析和运行程序完成相应的操作。在程序执行过程中会涉及同时处理多个任务或者同一时间只处理一个任务的情况。
1、同步处理：同步处理比较好理解，就是同一时间只执行一个简单任务，任务处理完后再执行第二个任务，同步处理适用于一些顺序执行的任务，例如流水线处理就是典型的同步处理，流水线上的一个环节处理完成后再处理下一个环节的任务。
2、异步处理：在一个登录操作过程中分别执行两个任务，这个过程就叫作异步处理。异步处理不会造成线程阻塞，相当于各自处理各自的任务。
06 什么是“脚本”
“脚本”这个词在工程师口中出现的频率比较高。当需要对数据库进行批量处理时，工程师会说“跑一个脚本统一处理一下”；当需要查询某一数据报表时，工程师会说“用一个脚本批量查询”。
脚本也是一种被计算机执行的程序，为什么叫脚本呢？
可以把脚本理解成拍戏用的剧本，剧本里会按照角色及对白把要拍的戏清晰地列出来，导演和演员会严格按照剧本表演。
脚本就是一种面向计算机的剧本，是一个可被计算机执行的文件，文件里是一系列计算机指令，这些指令会按照顺序被计算机解析并执行。
07 工程师口中的“打印”是什么意思
在与工程师的配合中，你一定听说过“打印”这个词，通常场景是在调试产品问题或进行开发测试时。
工程师口中的“打印”一词，表示的是一种结果输出，只是这种结果并不会输出到现实世界，只是将程序运行的结果“打印”到命令控制台上。
工程师在调试问题程序的过程中，也会经常用到打印技术，将每一块代码的执行结果输出到控制台，用来查看具体问题出在哪个环节。
因为代码的运行过程是不可见的，所以通过“打印”的方式能让代码的运行过程和结果可视化。
08 工程师口中的“写死”是什么意思
在与工程师讨论产品需求或者工程师相互讨论技术方案时，经常会听到“写死”这个术语。
“写死”这个词严格来说不算一个标准的技术术语，而是工程师用来描述一种技术实现方案的说法。
例如，要设计一个下拉选择框用来切换不同的城市，这个产品需求在技术层面有两种实现方案：
第一种是将城市数据放在服务器端，客户端通过请求数据接口将城市数据获取回来再显示在下拉列表中。第二种是将城市列表数据存放在客户端，客户端从本地读取城市列表并展示在下拉列表中。
第一种方式是一种相对灵活的方案，当城市数据有变化时，只需要调整服务端的数据内容即可，客户端不用做任何修改，但需要开发一个专门的数据接口获取这部分数据。
第二种方式就是工程师所说的“写死”，将数据集写死在本地，这样可以省去数据接口的开发，也能快速实现想要的效果。
这两种不同的实现方式在很多产品设计环节中都会体现，例如一些客户端的文案或者图片会经常变化，这时就不太适合将需要变化的数据“写死”在本地，合理的方案是将变化的数据存储在服务端，客户端通过数据接口灵活地获取这部分数据。
当然，也不是所有的数据都不适合“写死”在本地，例如性别数据，无非就是男和女，不必专门为了它开发一个数据接口，我们得根据具体需求和使用场景判断哪些数据应该写死。
09 内存泄漏
服务器会分配一份内存给我们的应用程序运行。如果代码写的有问题或者执行耗内存的任务时，可能会导致程序占用的内存过多无法立即释放，当再继续消耗内存时会出现内存不足，程序崩溃的场景，这就是内存泄漏。
10 透传
“透传”从字面上看是：透明无感知地传输数据的含义。
举个例子：
发短信功能（利用第三方服务腾讯云的发短信接口）：当用户输入手机号码点击发送验证码时，先调用我们自己后台的发短信接口，然后我们后台调用腾讯云的发短信接口，把用户从前端传过来的手机号码再继续传给腾讯云接口。
数据传递的链路是：前端->我们后台->腾讯云。后台没有对数据做任何修改就直接传给腾讯云的这个过程就是透传。
我的观点是：“产品经理无需具备技术能力，但需要具备技术思维”。
先想想这些场景你有没有经历过：
是否体验过被工程师问住的感觉？
谈到技术点，就有种话到嘴边就是说不出的堵塞感，很不好受！
聊产品价值、用户需求好好的，结果来一句“这个写死了，要改架构”，想摔电脑的心都有……
这个时候你会想，我要是会懂技术该多好，至少可以diss回去！
今天老原就从3个方面来聊聊产品经理和技术的关系：
1、产品经理要懂技术吗？
2、对技术要了解到什么程度？
3、要如何培养技术思维（必会的10个技术名词）
01
产品经理要懂技术吗？
在以前，「技术」在产品经理的能力模型中是加分项；放在今天，应该是必须项。
01 懂技术有什么优势？
不懂技术的产品经理吃过的苦只能自己咽，而懂技术有多香呢？
首先，做过开发的产品经理在沟通上占优势。
其次，掌握适当的开发知识便于我们提需求的时候可以考虑技术的可行性与投入成本，在跟开发沟通、转达需求的时候能够更有效率。
02 产品经理成长必备能力
项目经理除了和需求文档、原型图打交道，就是需求沟通，团队协作了。
与工程师沟通需求、讲解设计逻辑、跟进开发状态、随时解决工程师的疑问，这些占据了初阶产品经理的大部分时间和精力。
不是每一位工程师都有产品思维，别太指望工程师能使用用户语言和产品语言来和你沟通。
如果你碰巧碰见了，那是你的幸运。我以前也遇到过这样的工程师，那种感觉怎么说，心里暖暖的，让人觉得非常欣慰！
所以，掌握「技术语言」是非常关键的。技术思维+产品思维去解决问题，是初阶产品经理成长的第一步。
接下来，你成为高阶产品经理，已经不需要亲自去和技术人员互动沟通，更多是在战略、商业的角度去思考问题。
但此时，好的技术思维同样可以在你判断产品机会时有所助益。毕竟互联网产品都是基于技术发展的。
看到这，你觉得产品经理需要懂技术吗？
02
要懂到什么程度？
“产品经理无需具备技术能力，但需要具备技术思维”。
懂技术，不是让你从入门到精通掌握一门技术能力，而是需要具备基本的技术思维。
技术思维=技术原理+基本概念
举个例子，可以跟着我的思路来感受一下。
当你想要让开发在用户信息中添加一个字段。基本的流程是什么？
1、界面增加一个位置显示这个新增字段
2、在数据后台的数据结构中添加一个字段记录相关信息
3、需要前端来解析这个新的节点
4、需要后端修改好接口。
5、考虑到新旧版本的兼容。
而如果你在想要达到一个功能时，能有这样一条清晰的步骤在脑海里，那你基本上具备技术思维，这里需要你去敲代码吗？并不需要。
因为你了解数据结构、前后端交付模式以及数据兼容，你可以很顺利的去协同处理产品问题。
03
掌握「技术名词」是技术思维的第一步
那要怎么培养技术思维呢？
思维和能力不同，能力可以通过参加培训、多做技术练习来入门和提高；
但思维，在掌握基本的原理后，根据每个人的经验特点加以融合。
你要重复实践，积极复盘，复盘得到的结论不断积累，形成属于你自己的技术思维。
虽然每个人的认识和理解都不尽相同，但如果有个老师指导，会让你少走弯路。
今天老原为你整理了10个基本技术概念，助你形成自己的技术思维。
01 数据接口（API）及数据传输格式（XML、JSON）
1、API全称应用程序接口。是客户端与服务端之间的通信接口，比如登录功能，发起方式客户端，调用服务端开放的登录接口，然后进行数据传输和验证，期间完成数据请求和数据响应。
API是服务端开放出来的应用能力，例如登录接口、支付接口、分享接口等。
举一个形象的例子，接口就是墙壁上的插头，有两口的也有三口的，这项能力是由电网对外开放的能力。
2、JSON和XML都是数据传输格式。客户端向服务端发起请求后，需要将客户端的数据传输给服务端，而JSON和XML就是扮演数据载体的角色，JSON和XML是一种数据格式，好比两种不同格式的信纸，同一种数据内容分别可以以这两种不同的格式来进行传输。
02 高并发
高并发指的是web系统在短时间内遇到大量请求的情况。
比如双11活动、春晚抢红包活动。
高并发会导致系统在这段时间内执行大量操作，比如对数据库的操作、对资源的请求。如果高并发处理的不好，可能会导致请求响应过慢，甚至系统崩溃。
解决高并发的问题一般需要通过各个方面进行优化，包括增加服务器、限流、降级非核心功能、算法优化、数据库优化等方式。
03 日志
日志是开发为了跟踪用户行为和代码异常而打的记录。当一个请求到来时，后台一般会登记以下几种日志：
1、第三方服务日志。
如果后台调用了第三方服务，比如接入了公司内的统一登录服务，当调用该登录服务时，就记录这些行为。有利于排查问题时区分本服务日志和第三方日志。
2、SqlLog-数据库查询日志
一般会记录SQL查询语句、数据库名表名、查询耗时等指标。可能会用于排查SQL错误、优化SQL语句。
3、AccessLog - 用户访问日志
一般会记录请求URL、请求参数、用户ID、行为发生时间、接口返回值等几个关键指标。
4、Exception-代码异常
代码异常一般会记录报错信息、报错发生的代码是哪一行、报错发生时间等指标。代码异常日志是最重要也是经常要看的日志，根据报错可以快速定位到发生错误的原因，快速地修复问题。
04 定时任务
定时任务是：指定每到一个时间点，就执行一个固定任务，这个任务一般是一个计算脚本。
比如指定每天晚上凌晨，把一个库的数据通过一定的计算规则，把数据转换后，再同步到另一个库。定时任务是后台用来批量处理数据的常用方式，并且是实时性要求不高的批量数据。
05 同步处理和异步处理
同步和异步是开发技术中的两个概念，计算机通过解析和运行程序完成相应的操作。在程序执行过程中会涉及同时处理多个任务或者同一时间只处理一个任务的情况。
1、同步处理：同步处理比较好理解，就是同一时间只执行一个简单任务，任务处理完后再执行第二个任务，同步处理适用于一些顺序执行的任务，例如流水线处理就是典型的同步处理，流水线上的一个环节处理完成后再处理下一个环节的任务。
2、异步处理：在一个登录操作过程中分别执行两个任务，这个过程就叫作异步处理。异步处理不会造成线程阻塞，相当于各自处理各自的任务。
06 什么是“脚本”
“脚本”这个词在工程师口中出现的频率比较高。当需要对数据库进行批量处理时，工程师会说“跑一个脚本统一处理一下”；当需要查询某一数据报表时，工程师会说“用一个脚本批量查询”。
脚本也是一种被计算机执行的程序，为什么叫脚本呢？
可以把脚本理解成拍戏用的剧本，剧本里会按照角色及对白把要拍的戏清晰地列出来，导演和演员会严格按照剧本表演。
脚本就是一种面向计算机的剧本，是一个可被计算机执行的文件，文件里是一系列计算机指令，这些指令会按照顺序被计算机解析并执行。
07 工程师口中的“打印”是什么意思
在与工程师的配合中，你一定听说过“打印”这个词，通常场景是在调试产品问题或进行开发测试时。
工程师口中的“打印”一词，表示的是一种结果输出，只是这种结果并不会输出到现实世界，只是将程序运行的结果“打印”到命令控制台上。
工程师在调试问题程序的过程中，也会经常用到打印技术，将每一块代码的执行结果输出到控制台，用来查看具体问题出在哪个环节。
因为代码的运行过程是不可见的，所以通过“打印”的方式能让代码的运行过程和结果可视化。
08 工程师口中的“写死”是什么意思
在与工程师讨论产品需求或者工程师相互讨论技术方案时，经常会听到“写死”这个术语。
“写死”这个词严格来说不算一个标准的技术术语，而是工程师用来描述一种技术实现方案的说法。
例如，要设计一个下拉选择框用来切换不同的城市，这个产品需求在技术层面有两种实现方案：
第一种是将城市数据放在服务器端，客户端通过请求数据接口将城市数据获取回来再显示在下拉列表中。第二种是将城市列表数据存放在客户端，客户端从本地读取城市列表并展示在下拉列表中。
第一种方式是一种相对灵活的方案，当城市数据有变化时，只需要调整服务端的数据内容即可，客户端不用做任何修改，但需要开发一个专门的数据接口获取这部分数据。
第二种方式就是工程师所说的“写死”，将数据集写死在本地，这样可以省去数据接口的开发，也能快速实现想要的效果。
这两种不同的实现方式在很多产品设计环节中都会体现，例如一些客户端的文案或者图片会经常变化，这时就不太适合将需要变化的数据“写死”在本地，合理的方案是将变化的数据存储在服务端，客户端通过数据接口灵活地获取这部分数据。
当然，也不是所有的数据都不适合“写死”在本地，例如性别数据，无非就是男和女，不必专门为了它开发一个数据接口，我们得根据具体需求和使用场景判断哪些数据应该写死。
09 内存泄漏
服务器会分配一份内存给我们的应用程序运行。如果代码写的有问题或者执行耗内存的任务时，可能会导致程序占用的内存过多无法立即释放，当再继续消耗内存时会出现内存不足，程序崩溃的场景，这就是内存泄漏。
10 透传
“透传”从字面上看是：透明无感知地传输数据的含义。
举个例子：
发短信功能（利用第三方服务腾讯云的发短信接口）：当用户输入手机号码点击发送验证码时，先调用我们自己后台的发短信接口，然后我们后台调用腾讯云的发短信接口，把用户从前端传过来的手机号码再继续传给腾讯云接口。
数据传递的链路是：前端->我们后台->腾讯云。后台没有对数据做任何修改就直接传给腾讯云的这个过程就是透传。
粤公安备案 44010602008731号