《产品经理必懂的技术那点事儿》—— 阅读内化（13）

一．这本书的核心观点/思想：

产品经理为什么需要懂技术：

• 同理心：产品思维侧重从用户和商业的视角出发，而工程师的技术思维则侧重在技术实现和系统架构层面，而两者的交叉点就是产品的需求、设计和产品功能。由此可见产品经理和工程师在沟通时，双方的利益出发点往往是不一致的，所以产品经理懂一些技术的目的就是为了和工程师处于同一语境，并且引导双方去找到交叉点；
• 保证设计落地：产品经理所谓的“懂一点技术”是懂到什么程度？至少是需要清楚产品的“技术边界”。所谓“技术边界”是指现有技术水平下，可以被技术实现的需求范围，超出范围的设计无法落地。清楚地了解“技术边界”，就需要知道什么样的设计在今天能被满足，但同时也不要受制于技术边界，想象的空间无限大，在思考层面需要无边界。

数据库的一些基本概念：

• 数据库：数据库运行在服务器中，类似于一个进行数据存储的仓库，数据按照一定的规则存储，可以对数据库中的数据进行增、删、改、查的操作；
• 数据模型：一种基于关系模型的数据库，关系模型折射现实世界中的实体关系，将现实世界中各种实体以及实体之间的关系通过关系模型表达出来，关系之间的对应关系可以是一对一、一对多、多对多（从《决胜B端》来看，数据模型的设计是产品抽象到具象过程必须的一环）；
• 数据库和表格的关系：在数据模型中可以通过数据库表和表之间的关系具象地表示这种模型，表就是我们常用的二维表格，有表的名字，表的各项标题名，字段名等；
• 数据库操作语言：数据库一般使用SQL（结构化查询语言）来操作关系型数据库，通过一些对数据库的操作命令来实现数据库的增、删、改、查。

客户端的一些基本概念：

• 客户端：客户端是指普通用户使用的终端，用户通过客户端接触并使用产品；
• 对原理知晓的意义：产品经理对客户端原理知晓，不但能提高和工程师沟通的效率，以及出现问题时更精准定位问题所在，甚至能自己进行一些客户端上的调整从而更快捷地把握产品感受；

服务器的一些基本概念：

• 服务器：两个客户端之间的信息互动和数据传输是由服务器来完成的，服务器起到了中间核心处理者的作用，它负责处理复杂的业务逻辑并对数据进行存储管理，客户端和服务器借助网络进行数据传输，数据传输基于基本数据传输协议，定义数据传输的规则通常叫做接口，客户端与服务器需要进行很多功能和数据的交互，也就会有很多个数据接口，每一个接口都处理一个功能逻辑；
• 服务器的基本架构：服务器也叫云端，也就是云服务器，云服务器指的是物理机房托管的第三方，而不用自建机房，其中每个机房都由应用服务器、数据库服务器、交换机、网络端口、外网光缆构成。实际生产中的架构图会根据具体的业务形态和技术架构有不同的架构方式。首先，是从互联网接入，互联网的另一端实际就是客户端，客户端通过互联网请求访问服务器，请求进来后首先经过负载均衡服务器，负载均衡好比是一个调度中心，流量大的时候起到分流的作用。一个客户端请求经过负载均衡服务器的动态调度之后，会被分配到某一台API服务器，通常也叫做应用服务器，API服务器主要根据不同的客户端请求进行相应的业务逻辑处理，并将处理完成的结果返回客户端。
  
• 数据接口：数据接口是指客户端与服务器进行数据传输和交互的数据协议，数据接口是一种数据交换的标准，一般数据交换的格式有JSON、XML；

如何与工程师正确沟通：

• 了解工程师：工程师的思维以及性格的核心是“理性”，理性的外围主要体现在严谨、挑剔、逻辑性强、固执等具体表现上。从外表上看，工程师所表现出来的是简单、直接、抽象、完美，他们的思维方式是一种线性而逻辑性比较强的方式，考虑问题或者做出行动时往往会按照严密的顺序和逻辑进行，他们认为一件事情肯定是按照固定的流程执行，不喜欢中间突然变化或者出错，因为这会使他们感到沮丧。同时，工程师又是一群极为“自负”而追求极致的人，这种“自负”并不是贬义的自负，而是一种对自己所做的东西的自信，这种自信超出传统的自信，所以用“自负”来描述这种超额的自信；
• 沟通前的准备：产品经理在构思产品设计时，从抽象到具体模块这个节点，具体模块中所需功能以及其可行性可以先和工程师进行沟通，做到心中有数后再继续具象，而到PRD环节，产品经理需要先检查并保证功能逻辑、异常情况都已经考虑完善，再与工程师进行PRD的需求描述，在描述PRD时尽可能采用“第三方讲述法”来述说功能，让自己处在一个中立的立场上和工程师一起来看这个方案，而不是以自己为中心对工程师进行灌输和辩驳；
• 一些常见的场景：
  • “这个功能做不了”：反问“这个产品需求在现有的技术条件下是否能实现”→“既然是可以实现的，那做不了的原因是不是我们目前不具备这样的技术”→“既然不存在技术边界也不存在技术储备不足，那是因为排期上还是什么其他的因素导致无法开发”；
  • “这不是BUG”：在工程师的世界里，“BUG”就是一种贬义词，产品经理在遇到问题时，不要急于去大喊“XX你的功能出BUG了”，而是自行根据自己的逻辑去判断一下，再向假设的负责人询问“XX有空来帮忙看下这是什么情况，出现了YY问题”。

产品经理快速解决问题的思路——问题定位模型：

• 问题是否可以控制：这是对自身能力边界的认知，将可以控制的问题迅速解决；
• 问题不能控制但是否可以影响：这是一种借力的思维，巧妙地放大自己的能力边界，将问题过渡到可控制的范围内，再进行解决；
• 问题不能控制也不能影响：这是意识到“无知之知”后采取转换的思维，达到目的利用不同的手段，不必执着于一条路径。

二．我的收获：：

• 作者清晰地讲清楚了所谓产品经理所需要懂的技术，不是需要去懂得如何写代码去搞清楚各种公式推导，而是要清楚技术边界，能做什么不能做什么，这是最重要的，其次是通过对基本技术的概念以及原理有认知，能够与工程师顺畅沟通，保证产品设计思路的落地；
• 其中我反思了自己写PRD的思路，我之前只做了两层的对象分级，即“产品团队”、“技术团队”，所谓“产品团队”就是PRD的最前端关于“战略层”以及“范围层”，我会描述功能的目的以及设计思路，让上司以及同事了解我的设计思想；其次第二部分“技术团队”是写给工程师的细节方案是关于“结构层”以及“框架层”用于开发。但是，产品在落地过程中还有两个很重要的环节，即“美术团队”和“QA团队”，“美术团队”关心的是“表现层”，这而“QA的团队”关心的是所有层级的合理性（甚至会倒逼到“设计目的”），所以在之后的PRD要有意识去将后两者的利益点照顾到（比如对于美术，会分离出交互和UI的需求至PRD底部清楚描述，对于QA会分离出各层级的测试点至PRD底部并加以备注），做到更高效地沟通（其中加粗概念见《用户体验要素》）；
• 而关于最末尾提供的解决问题的框架“问题定位模型”非常好用，也非常易于形成直觉，在产品经理遇到问题时可以有意识去抽象问题，定位其层级，再去想解决方案，做到事倍功半。