沟通场景
1. 需求评审前、中、后期与技术人员沟通
需求评审前：
- 产品团队内部先达成一致，考虑业务影响面，异常情况
- 评审会前3天发送开会邮件给各与会人员，附件包含PRD等资料文件，督促开发查看，有疑问的点记下来
- 开会前2天找技术Leader沟通，讨论业务影响面、技术实现方案，并再次告知开会时间
- 开会前1天做最后调整，准备好开会资料，会议室设备，告知与会人员时间
需求评审中：
- 为什么做，做什么，做的价值
- PRD讲解，尽可能的详细，按照功能模块-线框图-需求用例-TC（Test Case）的流程讲
- 记录好技术的问题，5分钟能解决的就解决掉，解决不掉的记下来会后讨论修改
需求评审后：
- 准备1-2天后的交互评审
- 对会议中的问题总结修改
- 发送会议记录邮件CC给与会人员
- 交付改后的PRD给UX同事（在交互评审前准备好高保真原型图）
2. 交互评审中技术评估交互实现可行性
需求评审会后增加交互评审会议，让技术参与到交互评审中，对高保真原型图进行评估，减少开工后沟通成本、实现成本，小公司通常没有交互设计师的岗位，或者没有交互评审会议，但是增加交互评审会议的目的，是为了减少后期沟通成本，避免返工。
3. 技术评审中的技术方案、实现细节
- 确定需求的技术实现方案，实现细节
- Android和iOS达成一致，避免上线后结果不一致。
- 对技术的代码梳理，从延展性，影响面，性能方面去考虑
4. 项目跟踪过程中Debug、Release版的进度和质量
- 随时跟进Debug版的进度和质量，保证基本Demo方向，逻辑一致
- 跟进Release版的进度和质量，保证可用性测试，Test Case测试通过，产出的版本与设计一致，保证Android和iOS一致性。
5. 数据埋点需求
埋点分3种
- 代码埋点：技术人员按照PM的统计要求在代码中加入统计代码
- 可视化埋点：无须RD协助，PM、运营可自行在SDK后台加入统计代码，无须发布新版本
- 无埋点：技术人员在App中所有的按钮事件都加入统计代码，耗时耗力，对网络有性能要求
如果使用的第三方SDK不支持可视化埋点，则得请技术人员协助解决，如友盟只支持代码埋点，Growing、诸葛支持可视化埋点，则无须技术人员协助
沟通方法
1. 同理心
同理心（Empathy），又叫做换位思考、神入、共情，指站在对方立场设身处地思考的一种方式，即与人际交往过程中，能够体会他人的情绪和想法、理解他人的立场和感受，并站在他人的角度思考和处理问题。主要体现在情绪自控、换位思考、倾听能力以及表达尊重等与情商相关的方面
我认为同理心是产品经理的第二大核心能力，在日常工作中，产品经理会和各职能角色沟通，产品经理要想把需求从设计到实现，需要技术角色协助，换位思考很重要，和技术沟通时，要站在他的角度思考问题，当技术说不这样做的理由是什么？做起来很难的理由又是什么？性能方面影响的面有哪些？后期为什么难扩展？现在的代码low在哪里？等，当遇到这些问题时，如果能换位思考，站在技术的角度去考虑需求，结合现有资源，做出最优解的方案，那才是优秀的产品经理。因此，懂技术知识，有技术背景的产品经理尤其受技术同事欢迎，在技术选型、成本预估、和技术同事沟通上占有强大优势。
2. 尊重
首先，产品经理只是产品的经理，不是各职能角色的经理，和开发、测试、UI同事同级，并不具备领导权利。因此，在和技术人员沟通需求时，一定不要表现出经理的样子，以大压小只会使你离的更远，给予技术充分的尊重，平时呢，多和技术聊聊工作、生活上的事，给予鼓励，认可其工作成果，多担当，尊重技术的能力，一起协助解决问题。所以，以下的话就千万别说了。
- 别人App能实现啊
- 这个是老大的需求
3. 价值
大家都是来上班想做好事情、实现个人价值的（某些混日子的不在讨论范围内），讲清楚每一轮迭代，为什么做，做什么，做的价值，只要做的东西对公司、对客户有价值，那技术也会认可需求，只是具体实施过程中，怎么去结合团队现有资源做到最优，也就是MVP，因此，做好需求优先级很重要，从定性和定量的角度去分析需求，让各职能角色认可需求，使大家达成一致推进迭代。
4. 找到对的人
如果实在和某些技术员工沟通不了的，则请教其他技术同事或者技术Leader，找到实现方案，注意喔，这里不是越权，而是团队里面各技术角色技术能力不一，实现方案优劣、所需时间长短、技术延展性往往不一样，所以，找其他技术同事或技术Leader沟通解决方案更优更快，当然，产品经理是跟具体技术人员沟通还是技术Leader沟通，这个得看团队的管理方式了。
