产品和开发是整个项目中配合最频繁和紧密的，覆盖了从开始的需求评审到最后上线的全项目周期，所以双方会在日常工作中产生大量的交集，需要做很多沟通，产品经理需要向开发传达需求背景、产品方案、产品设计细节等，因此首先要求产品经理的沟通能力和原型设计一定要过硬。

沟通能力

在和开发gg的沟通过程中，你需要清晰的、结构性的、无逻辑错误的表述你的产品需求，所以很多问题你要提前想清楚，避免凌乱的、无结构的、错误百出的需求语描述；

产品经理最常犯的几个问题：

1、你表达的和开发表达的不在一个维度，导致无法交流

2、你讲完后以为开发理解了，事实是开发理解错了

3、没有背景、条件、原因，直接来个问题或者结论

4、讲述没有结构性、顺序性，想到哪讲到哪，导致逻辑混乱

5、自己并没想清楚，需求充满漏洞，就传达给了开发

这些问题都会导致开发和产品的沟通成本剧增、双方意见分歧增大、反复频繁确认、传达错误信息，最终导致整个协作过程内耗过大，效率过低。

举个反例：

产品经理直接和开发说：”用户需要秒杀功能，一个月之内能做完吗？“开发就会想：功能是什么样的我都不知道，怎么能告诉你一个月做不做的完呢？

举个正例：

产品经理和开发说：”用户需要秒杀功能，大致流程是这样的：用户创建活动，选择参与活动的商品，客户在微店上进行购买，商家处理订单。商品管理模块，订单系统我们本来就有了，改动不大。活动管理模块是这次要新增的。我把具体的原型文档发给你，你评估下工作量，看一个月之内是否可以完成？“开发拿到文档后就可以进行详细的评估了，给到的工作量也会比较准确。

原型设计规范

原型设计前需要先和开发沟通下大概的方案

• ->在原型设计时规避一些实现成本很高的方案
• ->开发前的详评让开发仔细评估，避免大的逻辑问题
• ->开发过程中及时沟通需求细节，修订方案
• ->提前介入产品验收，不要堆到最后快要上线前提出问题

这其中一份可读性强、规范性的原型是基础

举例：原型+标注

基础技术知识积累：

因为开发在遇到需求难以实现时、或技术实现难度很大、或在开发过程中遇到技术困难，都会来跟产品经理进行商量，告知产品自己在技术方案实现上遇到了什么问题，希望和产品共同讨论寻找一个合理的解决方式。要么变更需求，要么换技术方案，要么两个都改。

首先，懂一些基础的技术知识，既能让你更好的和开发沟通功能实现的技术细节，使得双方的沟通更顺畅无阻且高效，能够轻松理解对方的意思；也能让你在设计产品时进行预判，机智地回避一些研发性价比很低的、或者研发难度很大的设计方式，使得整体产品设计更加合理和科学。

此外，在具体的研发过程中，遇到开发抛出他的技术实现方案的思路时，懂技术的产品经理也能够敏锐的发现：技术上是否存在过度设计，是否有更合理的技术方案等。

最后，懂技术还能帮助产品经理大致估算开发时间。

提前有一个需求实现周期的预期，能和开发自己评审的时间做个比较，避免一些工时估算的猫腻。

估算方法：一个轻度不复杂的前端页面，1天

举例：

既然懂技术有这么多好处，那么作为一个合格的产品经理，需要懂哪些技术原理呢？

1、接口，这个是用到最多的。

接地气的描述是：两个不同的系统或一个系统中两个特性不同的部分相互连接的部分。

一般互联网公司内的接口都是由后端工程师提供，提供给前端、给外部，前端通过调用接口获取后端返回的结果（数据），而接口内往往隐含着一堆代码块（业务逻辑）。

看个微信的接口范例：获取用户基本信息（包括UnionID机制）

开发者可通过OpenID来获取用户基本信息。使用https协议。

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、各套环境的目的？

（1）开发环境

开发同学开发时使用的环境，每位开发在自己的dev分支上干活，提测前或者开发到一定程度，各个开发会合并代码，进行联调。

（2）测试环境

也就是我们测试干活的环境啦，一般会由测试自己来部署，然后在此环境进行测试。bug修复后，需要发版更新测试环境来回归bug。

（3）预发布环境

测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量。

（4）生产环境

即线上环境，用户使用的环境。一般由运维来维护，一般人没有权限去修改。

预发布环境和生产环境区别：

1）预发环境中新功能为最新代码，其他功能代码和生产环境一致。

2）预发环境和生产环境的访问域名不同。

注意事项：

1）预发布环境一般会连接生产环境的数据库，测试时要注意，以免产生脏数据，影响生产环境的使用。

另外，还有个灰度发布，发生在预发布环境之后，生产环境之前。

生产环境一般会部署在多台机器上，以防某台机器出现故障，这样其他机器可以继续运行，不影响用户使用。灰度发布会发布到其中的几台机器上，验证新功能是否正常。如果失败，只需回滚这几台机器即可。

7、其他一些基础技术原理，例如缓存

缓存分浏览器缓存和服务器缓存，顾名思义就是一个存在浏览器本地，一个存在服务器云端。

一般读取数据的时候都是从服务器的数据库中读取，当我们发现需要读取的数据没有实时性的要求，且读取频率很高的时候，我们往往可以把数据存在缓存中，便于提升数据读取的速度，从而使得页面响应速度提升，所以缓存的主要作用就在于此。

和开发相处的注意事项

Q1：开发往往会说这个功能实现不了？

A：产品需要有能力辨识不能做是什么原因，不会做？还是实现成本高？还是技术难度太大？

Q2：确认开发真的实现不了

A：如果产品方案无法妥协，找能解决的人，向上汇报（技术leader）

Q3：出现可能影响上线日期的问题

A：出现问题，及时拉相关人员开会确定解决方案并落实，影响较大或自己无法定夺则上报领导

Q4：需求变更通知到位

A：产品的需求变更是一个普遍存在的现象，需求变更不可怕，可怕的是变更完了没通知到位。导致开发、测试都不知晓，最后带着问题上线

Q5：如何面对开发砍需求？

A：首先给自己的需求定好优先级，其次自己预估一下这期功能的体量，提前预估开发能吃下多少功能，然后附带增加一些陪跑功能，它们的作用就是专门用来被砍的，以此来保证主要功能尽量多消化。

Q6：耐心听取开发建议，鼓励多提业务建议。

A：开发也有对业务发表自己看法的欲望，适当地让开发表达一些想法，既有利于双边关系和谐，也可以从开发角度吸收一些有利于产品的建议

Q7：开发经常会问，客户真的有这个需求吗？真的有这个场景吗？

A：本质其实是对产品的质疑，很多时候大家会把对方的质疑转化成情绪化争辩，失去了讨论的目的。产品经理最终需要回归到讲解清楚业务场景，和客户需求，以理服人

Q8：开发提出两套方案，需要产品经理做选择和决策

A：产品经理做决定时，依据科学、考虑周全、决策果断，向开发展现出专业

Q9：尊重开发，不要当面质疑能力

A：无论是因为开发无论理解你的需求，还是开发技术能力较弱，还是开发无法认可你的方案，都不要当面质疑开发，尊重别人的专业才能更长远的合作