交流与沟通
转载自： https://www.cnblogs.com/jurendage/p/9636038.html
先直接上图：
这个是一个实际的截图，内容是否真实，我们不得而知，但是这张图引起了我的以下思考：
1. 沟通能力。
2. 沟通的方式。
3. 沟通的方法
5. 从这个沟通的对话中，如何理解程序员与产品经理之间的方式与方法呢？
6. 为什么会出现这样的沟通方式与行为呢？这个背后到底发生了什么事情呢？
其实，我觉得还是一个沟通的思维问题，行动是思维的最终结果。
那么实际沟通中，到底会出现那些沟通的问题与障碍，以及有什么办法可以克服的呢？
- 需求评审前、中、后期与技术人员沟通
需求评审前： 产品团队内部先达成一致，考虑业务影响面，异常情况 评审会前3天发送开会邮件给各与会人员，附件包含PRD等资料文件，督促开发查看，有疑问的点记下来 开会前2天找技术Leader沟通，讨论业务影响面、技术实现方案，并再次告知开会时间 开会前1天做最后调整，准备好开会资料，会议室设备，告知与会人员时间 需求评审中：
为什么做，做什么，做的价值
PRD讲解，尽可能的详细，按照功能模块-线框图-需求用例-TC（Test Case）的流程讲
记录好技术的问题，5分钟能解决的就解决掉，解决不掉的记下来会后讨论修改
需求评审后：
准备1-2天后的交互评审
对会议中的问题总结修改
发送会议记录邮件CC给与会人员
交付改后的PRD给UX同事（在交互评审前准备好高保真原型图）
- 交互评审中技术评估交互实现可行性
需求评审会后增加交互评审会议，让技术参与到交互评审中，对高保真原型图进行评估，减少开工后沟通成本、实现成本，小公司通常没有交互设计师的岗位，或者没有交互评审会议，但是增加交互评审会议的目的，是为了减少后期沟通成本，避免返工。
技术评审中的技术方案、实现细节
确定需求的技术实现方案，实现细节
对技术的代码梳理，从延展性，影响面，性能方面去考虑
3. 项目跟踪过程中Debug、Release版的进度和质量
随时跟进Debug版的进度和质量，保证基本Demo方向，逻辑一致
跟进Release版的进度和质量，保证可用性测试，Test Case测试通过，产出的版本与设计一致，保证Android和iOS一致性。
4. 数据埋点需求
埋点分3种
- 代码埋点：技术人员按照PM的统计要求在代码中加入统计代码
- 可视化埋点：无须RD协助，PM、运营可自行在SDK后台加入统计代码，无须发布新版本
- 无埋点：技术人员在APP中所有的按钮事件都加入统计代码，耗时耗力，对网络有性能要求
如果使用的第三方SDK不支持可视化埋点，则得请技术人员协助解决，如友盟只支持代码埋点，Growing、诸葛支持可视化埋点，则无须技术人员协助
学会尊重
首先，产品经理只是产品的经理，不是各职能角色的经理，和开发、测试、UI同事同级，并不具备领导权利。因此，在和技术人员沟通需求时，一定不要表现出经理的样子，以大压小只会使你离的更远，给予技术充分的尊重，平时呢，多和技术聊聊工作、生活上的事，给予鼓励，认可其工作成果，多担当，尊重技术的能力，一起协助解决问题。所以，以下的话就千万别说了。
- 别人App能实现啊
- 这个是老大的需求
体现价值
大家都是来上班想做好事情、实现个人价值的（某些混日子的不在讨论范围内），讲清楚每一轮迭代，为什么做，做什么，做的价值，只要做的东西对公司、对客户有价值，那技术也会认可需求，只是具体实施过程中，怎么去结合团队现有资源做到最优，也就是MVP，因此，做好需求优先级很重要，从定性和定量的角度去分析需求，让各职能角色认可需求，使大家达成一致推进迭代。
最终所有的结果都是自己造成的，怪不得他人，我们需要的是冷静的处理所有的事情，所有的工作，善待他人。
相关阅读
工作进展缓慢、目标不明确、来回返工、分不清工作的轻重缓急，甚至发生语言和肢体的摩擦……这些现象在职场上屡见不鲜，大
上一篇文章简单的写了一下“思考”（感兴趣的话，可以阅读一下：产品经理如何进行有效率的思考？），这篇文章我想写一下和思考密切相关的一个
如果说用户为产品之基础，恐怕不过分。尽管有不少案例告诉我们，用户可能会误导产品思路，但Cynthia认为，那也不会是用户的错，常常是我们
谈到沟通，大部分人首先想到的可能就是当面形式的一些沟通，比如1对1交谈、会议、汇报演示等，而实际上除了我们所熟知的这些沟通方式之
当拿到一个需求时，分析他的核心假设是可以确定的，还是需要线上用户验证的。如果是可以确定的，其实就不需要采用 MVP；如果是需要线上用