产品经理的技术能力要求.docxVIP

产品经理的技术能力要求 （WORD文档，下载后可编辑修改） 在产品路上这几年，有一些对于非技术背景的产品经理想说的话，或许对每一位产品经理都可作为参考。 我们从三个问题开始： 经常会有朋友问我：产品经理要学编程吗，是不是也要会写代码才比较好啊。 其实，这就是很多人都关心的一个话题：产品经理要懂技术吗，如果要，懂到什么程度才合适？ 如果把产品比喻为建筑，那产品经理就是建筑设计师。 如果设计师不懂基本的建筑结构设计和施工原理，那么设计出来的建筑很可能就是无法落地的空中楼阁——理想的设计和物理的限制必须有机结合。 首先我们来看一下什么是产品思维和技术思维： 产品思维侧重从用户和商业视角出发，技术思维侧重在技术实现和系统架构层面，两种思维方式的交叉点是产品的需求、设计和产品功能。 由此可见，当产品经理与工程师讨论产品时，各自的思维出发点是不一样的： 工程师和产品经理虽然基于同样的产品需求和设计进行讨论，但双方的思维模式不同会影响共识性的达成；所以对产品经理而言，掌握一些技术思维，学会从技术视角看待产品设计，能更有利于产品工作的进行。 明白了这两种思维模式的差异，作为产品经理，而且作为产品的主导者，需要学会用技术思维去理解产品，并且能通过技术思维与工程师进行沟通。 对于产品经理而言，置身互联网领域设计互联网产品，每一个设计都应该在现有的互联网技术框架下可被实现。 产品经理懂得一些基本技术知识，了解技术边界，通过技术思维与工程师有效沟通，对实际开展产品工作有非常大的益处。 我们明确第一个问题的答案：作为一名产品经理，懂技术是非常必要的。 但需要区分的是：技术思维不等于技术能力；产品经理无需自己上手写代码，也无需对每一个技术知识点了解到与工程师一般精通。 如果进入这个误区，那就顾此失彼了。 产品经理需要学习和懂得的是技术思维，在了解技术知识和原理的基础上，能运用技术思维进行产品方案的选择和工程量的判断。 例如，当有一个产品方案，需要决定用原生系统开发实现，还是用H5开发实现时，作为产品经理，需要理解的是这两种技术方案在实现难度、工作量、资源投入上的区别。 对于大部分产品方案，H5的开发成本更低，且在工作量上只需要H5工程师开发一遍；如果是原生系统开发，那至少需要Android和iOS工程师各自开发一遍，工作量和资源投入要高。 在快速试错和需要灵活应变的场景下，H5的技术方案不失为一种好的选择。 这种选择是基于产品经理对不同技术方案原理的理解。 例如为什么H5能做到灵活应变？是因为H5页面都是运行在服务器上，客户端只是通过浏览器去访问。 为什么原生系统实现需要每次都发版？那是因为客户端程序都是写死在客户端安装包里。 基于对这些基础技术知识和原理的理解，产品经理就能通过技术思维去判断产品方案，也能以此去与工程师进行沟通。 类似的场景还有很多很多。 所以，第二个问题的答案是：产品经理懂技术的程度，需要达到具备技术思维的条件下能对技术方案和产品方案进行综合评判，而不需要具备写代码或者做架构的技术能力。 二、不同领域产品的技术能力要求 根据行业领域和产品类型的不同，产品经理对技术的学习侧重点会各不相同。 1. 电商产品经理 以目前我所在的电商领域为例，电商类产品的特点是重业务流，从商品信息流、物流、资金流闭环角度去进行产品设计。 例如用户下单后，系统会根据商品归属的商家、所在仓库、配送方式等不同维度对订单进行拆分，俗称“拆单”。 在直观感受上，大家平时下单支付完成后，在订单详情里会看到，之前一起结算的商品被拆分成了几个子订单，俗称“子单”，而被拆分以前的订单统一叫“父单”。 以京东为例，京东目前经营的商品分为自营和第三方经营，如果按是否自营商品进行拆单，拆单后，自营商品由京东自有仓发货，而第三方商家的商品由第三方自主发货。 从技术角度去理解上述拆单的过程，首先得从商品维度去理解系统是如何对自营商品和第三方商品进行划分的。 这里就引出了数据结构的概念。 在电商产品的数据结构设计中，商品数据是其中一个主体，包括了商品编号、名称、型号、颜色等各种属性，这些都可以被称为商品的数据字段；在这些字段中，我们需要为商品增加一个字段，这个字段就专门用来标记是自营还是第三方。 同理，商品有数据结构，订单也有自己的数据结构，例如订单编号、配送信息、商品信息等。 注意：订单数据里是包括了商品基本信息的，但不会包括完整的商品信息。 例如订单里我们能看到商品编号、名称等，但其他的完整信息是在商品数据里存储的——这里就引出了数据库表和表之间关联结构的概念。 产品经理需要对什么是数据结构、数据库表、表与表之间的关联关系进行理解，从技术角度理解原理后，再回到业务和产品角度来看问题，很多底层理解就和工程师基本一致了。 至于究竟如何建立数据结构以及如何操作数据库，就不在产品经理应该关注