Java开源生鲜电商平台——程序员的沟通方式和方法
今天看到一张照片，受到了启发。
这是实际的屏幕截图。我们不知道内容是否属实，但这张照片引起了我的思考：
1、沟通能力。
2、沟通方式。
3. 沟通方式
一、为什么会出现骂娘辞职的裂变结果？
2、从这次沟通对话中，如何理解程序员和产品经理之间的方式和方法？
3、为什么会出现这样的沟通方式和行为？这背后到底发生了什么？
其实我觉得沟通中还是思维的问题，行动才是思维的最终结果。
那么实际沟通中会出现哪些沟通问题和障碍，有哪些方法可以克服呢？
1. 需求评审前、中、后期与技术人员沟通
要求审核前：
产品团队首先达成一致，考虑业务影响，并在异常情况审核会议前3天向所有参与者发送会议电子邮件。附件包含PRD等信息文件，恳请开发审核。如果您有任何疑问，请在会议前2天记录下来并联系技术人员。 Leader沟通，讨论业务影响、技术实施方案，并再次告知会议召开时间。会议前一天进行最后调整，准备会议材料、会议室设备，并告知参会人员正在审核时间要求：
解释你为什么这样做、你做了什么以及这样做的价值。 PRD 解释应尽可能详细。按照功能模块-线框图-需求用例-TC（测试用例）的流程记录技术问题，如果能在5分钟内解决就解决。不能解决的写下来，会后讨论修改：
准备1-2 天后的交互式审核。对会议问题进行总结和修改。将会议纪要通过电子邮件抄送给与会者。将修改后的PRD交付给UX同事（交互式评审前准备高保真原型图）
2. 交互评审中技术评估交互实现可行性
需求评审会议后增加交互式评审会议，让技术参与交互式评审，评估高保真原型，降低沟通成本以及开工后的实施成本。小公司通常没有交互设计师职位，或者没有交互评审会议，但增加交互评审会议的目的是减少后期沟通成本，避免返工。
3. 技术评审中的技术方案、实现细节
确定需求的技术实现方案，并就Android和iOS的实现细节达成一致，避免上线后结果不一致。梳理技术代码，考虑扩展性、影响、性能
4. 项目跟踪过程中Debug、Release版的进度和质量
随时跟进Debug 版本的进度和质量，保证基本Demo 方向，以一致的逻辑跟进Release 版本的进度和质量，并确保可用性测试。测试用例通过测试，生成的版本与设计一致，保证了Android和iOS的一致性。
5. 数据埋点需求
埋点共有三种类型
- 代码埋点：技术人员按照PM的统计要求，在代码中添加统计代码
- 可视化跟踪：无需RD协助。 PM和运营商可以在SDK后台自行添加统计代码，无需发布新版本。
- 无隐藏点：技术人员对App内所有按钮事件添加统计代码，费时费力，对网络性能有要求
如果使用的第三方SDK不支持视觉跟踪，则必须请技术人员帮助解决问题。比如友盟只支持代码追踪，成长和诸葛支持视觉追踪，所以不需要技术协助。
6. 学会尊重
首先，产品经理只是产品的管理者，而不是各种职能角色的管理者。他们与开发、测试、UI 同事处于同一级别，没有领导权。因此，在与技术人员沟通需求时，一定不要表现得像个经理。以大压小，只会让自己越走越远。给予技术充分的尊重。平时多跟科技聊工作、生活。做事时给予鼓励，认可他们的工作成果，承担更多的责任，尊重技术能力，共同帮助解决问题。因此，请不要说以下的话。
- 其他人的应用程序可以做到这一点吗？
- 这是老板的需要
7. 体现价值
每个人来工作都是为了把事情做好，实现个人价值（有些磨蹭不在讨论范围之内）。清楚地解释每次迭代，为什么这样做，你做了什么，它的价值以及你只需要做什么。如果对公司和客户有价值，那么技术也会认识到需求。然而在具体实施过程中，如何结合团队现有的资源做到最好，那就是MVP。因此，重要的是对需求进行优先排序，从定性和定量的角度分析需求，让各个职能角色认识到需求，并使大家达成共识，推动迭代。