这是我的第89篇原创文章—— 产品和开发是相爱相杀的一对，我们经常在需求评审、开发过程中遭到开发的质疑和吐槽，尤其是新手期会感觉做错了事情，特别害怕。那么能力要达到什么样的程度才不会被吐槽呢？是不是产品经理懂技术，就能减少很多沟通障碍呢？怎么才能让他们乖乖听话，认真做完需求呢？本文就教你一些技能。
1、产品经理经常犯的错误
产品和开发是整个项目中配合最频繁和紧密的，覆盖了从开始的需求评审到最后上线的全项目周期，所以双方会在日常工作中产生大量的交集，需要做很多沟通。
产品经理需要向开发传达需求背景、产品方案、产品设计细节等，因此首先要求产品经理的沟通能力和原型设计一定要过硬。
沟通能力弱
在和开发 GG 的沟通过程中，你需要清晰的、结构性的、无逻辑错误的表述你的产品需求，所以很多问题你要提前想清楚，避免凌乱的、无结构的、错误百出的需求语描述。
产品经理最常犯的几个问题：
- 你表达的和开发表达的不在一个维度，导致无法交流
- 你讲完后以为开发理解了，事实是开发理解错了
- 没有背景、条件、原因，直接来个问题或者结论
- 讲述没有结构性、顺序性，想到哪讲到哪，导致逻辑混乱
- 自己并没想清楚，需求充满漏洞，就传达给了开发
这些问题都会导致开发和产品的沟通成本剧增、双方意见分歧增大、反复频繁确认、传达错误信息，最终导致整个协作过程内耗过大，效率过低。
举个例子
举个反例：
产品经理直接和开发说：“用户需要秒杀功能，一个月之内能做完吗？”
开发就会想：功能是什么样的我都不知道，怎么能告诉你一个月做不做的完呢？
举个正例：
产品经理和开发说：“用户需要秒杀功能，大致流程是这样的：用户创建活动，选择参与活动的商品，客户在微店上进行购买，商家处理订单。商品管理模块，订单系统我们本来就有了，改动不大。活动管理模块是这次要新增的。我把具体的原型文档发给你，你评估下工作量，看一个月之内是否可以完成？”
开发拿到文档后就可以进行详细的评估了，给到的工作量也会比较准确。
2、沟通的正确姿势
想要不用跪着聊需求，就要先定好规范。
- 原型设计前需要先和开发沟通下大概的方案
- 在原型设计时规避一些实现成本很高的方案
- 开发前的详评让开发仔细评估，避免大的逻辑问题
- 开发过程中及时沟通需求细节，修订方案
- 提前介入产品验收，不要堆积到最后快要上线前提出问题
这其中一份可读性强、规范性的原型是基础 举例：原型+标注
3、产品经理要懂技术吗？
要有一些基础技术知识积累
因为开发在遇到需求难以实现时、或技术实现难度很大、或在开发过程中遇到技术困难，都会来跟产品经理进行商量，告知产品自己在技术方案实现上遇到了什么问题，希望和产品共同讨论寻找一个合理的解决方式。要么变更需求，要么换技术方案，要么两个都改。
首先，懂一些基础的技术知识，既能让你更好的和开发沟通功能实现的技术细节，使得双方的沟通更顺畅无阻且高效，能够轻松理解对方的意思；也能让你在设计产品时进行预判，机智地回避一些研发性价比很低的、或者研发难度很大的设计方式，使得整体产品设计更加合理和科学。
此外，在具体的研发过程中，遇到开发抛出他的技术实现方案的思路时，懂技术的产品经理也能够敏锐的发现：技术上是否存在过度设计，是否有更合理的技术方案等。
最后，懂技术还能帮助产品经理大致估算开发时间。
提前有一个需求实现周期的预期，能和开发自己评审的时间做个比较，避免一些工时估算的猫腻。
估算方法：一个轻度不复杂的前端页面，1天
既然懂技术有这么多好处，那么作为一个合格的产品经理，需要懂哪些技术原理呢？
产品经理要懂技术原理
1. 接口，这个是用到最多的。
接地气的描述是：两个不同的系统或一个系统中两个特性不同的部分相互连接的部分。
一般互联网公司内的接口都是由后端工程师提供，提供给前端、给外部，前端通过调用接口获取后端返回的结果（数据），而接口内往往隐含着一堆代码块（业务逻辑）。
看个微信的接口范例：获取用户基本信息（包括UnionID机制）开发者可通过OpenID来获取用户基本信息。使用https协议。
参数说明
返回说明正常情况下，微信会返回下述JSON数据包给公众号：
参数说明
错误时微信会返回错误码等信息，JSON数据包示例如下（该示例为AppID无效错误）:
即第三方开发者通过微信接口input 3个入参，由微信返回多个出参（字段数据）给到开发者。
这就是一个非常简单、易于理解的接口文档。
2. 数据库、数据表结构、数据关系
数据库：顾名思义就是存数据的地方，绝大部分公司目前都使用SQL数据库，数据库是部署在服务器上的。
3. Web的数据请求是如何实现的？
Web请求的工作原理可以简单地归纳为：
- 浏览器通过 DNS 把域名解析成对应的IP地址；
- 根据这个 IP 地址在互联网上找到对应的服务器，建立 Socket 连接；
- 客户端向服务器发送HTTP协议请求包，请求服务器里的资源文档；
- 在服务器端，实际上还有复杂的业务逻辑：服务器可能有多台，到底指定哪台服务器处理请求，这需要一个负载均衡设备来平均分配所有用户的请求；
- 还有请求的数据是存储在分布式缓存里还是一个静态文件中，或是在数据库里；
- 当数据返回浏览器时，浏览器解析数据发现还有一些静态资源（如：css，js或者图片）时又会发起另外的请求，而这些请求可能会在CDN上，那么CDN服务器又会处理这个用户的请求。
- 客户端与服务器断开。由客户端解释HTML文档，在客户端屏幕上渲染图形结果。
一个 HTTP 事务就是这样实现的，看起来很简单，原理其实是挺负责的。需要注意的是客户端与服务器之间的通信是非持久连接的，也就是当服务器发送了应答后就与客户机断开连接，等待下一次请求。
4. 同步&异步
同步：当客户端发送请求给服务端，在等待服务端响应的请求时，客户端不做其他的事情。当服务端做完了才返回到客户端。这样的话客户端需要一直等待。用户使用起来会有不友好。
异步：当客户端发送给服务端请求时，在等待服务端响应的时候，客户端可以做其他的事情，这样节约了时间，提高了效率。
存在就有其道理，异步虽然好，但是有些问题是要用同步用来解决，比如有些东西我们需要的是拿到返回的数据在进行操作的。这些是异步所无法解决的。
5. 前后端渲染：
后端渲染：后端的程序在把html页面给前端之前，先把html页面上的特定区域，特定符号，给用数据填充过，再扔给前端，这就是后端渲染，所谓渲染，你可以理解一种修改，渲染这词最早来源于游戏领域，游戏领域又来源于现实画画，渲染嘛，拿着颜料往纸上涂便是。以前绝大部分服务器都是这个模式
前端渲染：后端的html页面作为静态文件存在，前端请求时后端不对该文件做任何内容上的修改，直接以资源的方式返回给前端，前端拿到页面后，根据写在html页面上的js代码，对该html的内容进行修改（涂颜料）。这就是前端渲染。
6. 各套环境的目的？
（文章选自星球课程：B端产品实战宝典（进阶版），可以加入星球，查看更多课程。）
7. 其他一些基础技术原理，例如缓存
缓存分浏览器缓存和服务器缓存，顾名思义就是一个存在浏览器本地，一个存在服务器云端。
一般读取数据的时候都是从服务器的数据库中读取，当我们发现需要读取的数据没有实时性的要求，且读取频率很高的时候，我们往往可以把数据存在缓存中，便于提升数据读取的速度，从而使得页面响应速度提升，所以缓存的主要作用就在于此。
4、注意事项
和开发相处的注意事项
Q1：开发往往会说这个功能实现不了？
A：产品需要有能力辨识不能做是什么原因，不会做？还是实现成本高？还是技术难度太大？Q2：确认开发真的实现不了
A：如果产品方案无法妥协，找能解决的人，向上汇报（技术leader）Q3：出现可能影响上线日期的问题
A：出现问题，及时拉相关人员开会确定解决方案并落实，影响较大或自己无法定夺则上报领导Q4：需求变更通知到位
Q5：如何面对开发砍需求？
Q6：耐心听取开发建议，鼓励多提业务建议。
Q7：开发经常会问，客户真的有这个需求吗？真的有这个场景吗？
Q8：开发提出两套方案，需要产品经理做选择和决策
Q9：尊重开发，不要当面质疑能力
（文章选自星球课程：B端产品实战宝典（进阶版），可以加入星球，查看更多答案和课程。）
好了，看到这里，你心里大概有点底了吧。
