本篇 文章讲述的适用于传统的产品经理，不适合人工智能产品经理
工程师思维
个体思维差异
每个人的成长背景，经历，个人认知导致量思维差异的形成，尊重并接受这种差异性是形成有效沟通的前提
认知鸿沟是沟通障碍的主要来源
工程师思维特点
1.逻辑性强
2.分支思维：提新需求时，工程师一般不会在主流程上改，而是将这个主干分支复制出来，开一个新的分支，相当于测试分支，这个分支和主干分支是平行的状态，互不干扰。在测试分支上进行开发或修改，测试没问题后，进行分支合并
3.遍历：查一个表中的数据，会写代码将表中的数据全部的遍历一遍
产品经理在写需求的时候可能会只考虑if这个层级，工程师在写的代码的时候，代码会告诉他会有else，可能会有更多的else，所以工程师会考虑的更完善，所以产品经理可以借用这种思维
与工程师沟通
三个原则
1.重事实：现状，问题，方案——可行性
2.讲逻辑：分支覆盖，遍历完整，冲突性——完整性
3.确定性：工作量，周期，风险预估——可控性
产品经理不仅要设计方案，也要对方案落定的过程有一个把握
如何区分现象和问题
如何高效沟通
沟通的本质是取得共识和解决问题
高效沟通的目的是寻找最短路径去取得共识和解决问题
沟通路径：
人们往往在发现问题后容易花大量的时间讨论现象，如这个问题会影响到什么什么，但它对整个过程没有促进作用，还不如将这个时间用在定义问题上，这个问题出现在哪里，这个问题是某某某
现象VS问题
让讨论以方案为导向，以共识为目的，我们花了太多时间去讨论和重复讨论现象，却恰恰忽略了定义关键问题，现象是影响，问题是原因
例如：
想象：产品登陆不上去了——问题：网络故障，后端服务故障，前端处理异常（进入到没遍历对分支）
现象：这个实现不了（千万不要把他当作一个结论）——问题：技术边界，难度，时间成本
瞄准问题打方案
定义清楚问题，就已经解决了一半
现象：产品登陆不上去了
问题：网络故障，后端服务故障，前端处理异常
方案：网络排查，前后端分别排查
现象：这个实现不了
问题：技术边界，难度，时间成本
方案：技术边界——找替代方案；难度——公关小组；时间成本——项目协调
我经常使用对一句话：你的问题是什么？
如何正确提需求
提需求的时机
根据工程师的习惯，不是每个时候都适合提需求，找准时机，让需求更容易被接受
时机分类：
上线前 X
上线后稳定运行 V
周期迭代结束 V
写代码 X
改BUG X
提交代码 V
提需求的顺序
用一个上下文完整的信息并结合问题给工程师提需求，避免干瘪的功能性需求
顺序：
需求：浅层唤醒层面，自定义唤醒词
背景（现状，问题，原因）：同时有多台音箱，且唤醒词相同，想要唤醒某一台时，其他音箱同时被唤醒。背景讲明白，一般工程师都不会反驳
方案（如何做，可行性）：在软件层面设置浅层唤醒
执行（何时做）：这个版本迭代之后，全量发布
提需求的内容
避免凭感觉式的需求描述，需求内容要具体可行
页面原型图——产品/UE
功能交互流程图——产品
接口URL及对应参数——产品/开发
视觉搞/素材/标注——UI
prd文档：
1.把背景说清楚
2.把方案定明白
流程图
带交互的原型图
接口说明
3.把材料备齐全（UI，测试用例，发布上线节奏）
在我看来没有标准的文档，文档存在的意义，是能把问题描述清楚，把需求讲明白，而不是多好看
如何评估技术工作量
技术工作包括哪些
数据库设计
接口设计
界面代码
逻辑代码
组件复用
代码注释
单元测试
前后端接口联调
bug修改
部署上线
结束工作细节远比上面看到的要多，实际过程中的不确定性极强，任何一个环节都有可能延期
按需求拆分
产品经理无需精确评估技术工作量，也评估不准，但可以把需求进行拆分评估大概周期
拆分维度：
1.系统：按不同系统拆分，例如按电商优惠券系统，促销系统，运营后台进行拆分
2.模块：按功能 模块进行拆分，例如按电商交易流程中的购物车，结算页，收银台进行拆分
3.页面：按独立页面进行拆分，例如按电商商品详情页，订单列表页，用户评价页进行拆分
根据拆分后的需求，根据复杂度，改动量，过往经验进行工作量预估
技术组件化
组件化也是能够很好帮助我们评估技术工作量的一种方式，一种工具。技术中有句话叫做，不重复发明轮子，是技术组建化的目标，不是所有的功能都需要重复开发
例如现在有三种组建：
1.定位组建
2.IM组建
3.列表数据加载组建
对于组建的使用是通过集成的方式，不需要开发的
技术思维在产品设计中的运用
运用技术思维进行产品设计
产品是感性思考与理性设计的结合体，在设计环节，加入技术思维的考虑，会更利于落地。考虑方案的 实现的原理，主要涉及：
1.数据结构调整（数据库，接口）
2.页面调整
3.逻辑兼容（新老版本兼容）
案例：短信模版
技术视角下的短信模版
产品工作：
1.定义参数
2.确定短信模版：大概在哪些环节需要使用这些参数
3.明确接口取值逻辑：接口怎么判断参数值
如何持续提升技术思维
技术思维不等于技术能力
产品经理要掌握的是技术思维，而不是技术能力，切记别顾此失彼，人工智能产品经理除外
技术思维：
理解程序和代码逻辑
设计低复杂度 界面布局
判断数据是如何在功能间流转
技术能力：
能够编写代码实现功能
实现前端界面
从数据库查询或修改数据
提升途径
技术思维的主要途径：
1.需求评审会上，对工程师的问题重点记录，反复思考，翻译成通俗的理解
2.阅读数据库设计文档（比如有哪些表，有哪些字段，关系是什么）以及接口文档，建立数据结构的基本认知
3.产品升级或设计调整时，是了解其中技术细节的最好时机，包括数据流转，接口分布等
4.进一步系统化学习时，可以参考大学教材进行基础知识补充，但不建议太深入
对产品经理来说，对产品的理解，对用户的理解，要优先于对技术的理解（人工智能产品经理除外，后面会单独讲人工智能产品经理）
建立自己的技术知识库
将复杂的技术概念，转化为自己可理解的常识性概念，持续丰富自己的技术知识库
