Java开源生鲜电商平台-程序员的沟通的方式与方法

java开源生鲜电商平台-程序员的沟通的方式与方法

今天看了一张图，有感而发。

 

 

这个是一个实际的截图，内容是否真实，我们不得而知，但是这张图引起了我的以下思考：

 

1. 沟通能力。

2. 沟通的方式。

3. 沟通的方法

 

1. 为什么会出现最后骂娘，而且要离职的一种裂变结果呢？

2. 从这个沟通的对话中，如何理解程序员与产品经理之间的方式与方法呢？

3. 为什么会出现这样的沟通方式与行为呢？这个背后到底发生了什么事情呢？

 

其实，我觉得还是一个沟通的思维问题，行动是思维的最终结果。

 

那么实际沟通中，到底会出现那些沟通的问题与障碍，以及有什么办法可以克服的呢？

1. 需求评审前、中、后期与技术人员沟通

需求评审前：

1. 产品团队内部先达成一致，考虑业务影响面，异常情况
2. 评审会前3天发送开会邮件给各与会人员，附件包含prd等资料文件，督促开发查看，有疑问的点记下来
3. 开会前2天找技术leader沟通，讨论业务影响面、技术实现方案，并再次告知开会时间
4. 开会前1天做最后调整，准备好开会资料，会议室设备，告知与会人员时间

需求评审中：

1. 为什么做，做什么，做的价值
2. prd讲解，尽可能的详细，按照功能模块-线框图-需求用例-tc（test case）的流程讲
3. 记录好技术的问题，5分钟能解决的就解决掉，解决不掉的记下来会后讨论修改

需求评审后：

1. 准备1-2天后的交互评审
2. 对会议中的问题总结修改
3. 发送会议记录邮件cc给与会人员
4. 交付改后的prd给ux同事（在交互评审前准备好高保真原型图）

2. 交互评审中技术评估交互实现可行性

需求评审会后增加交互评审会议，让技术参与到交互评审中，对高保真原型图进行评估，减少开工后沟通成本、实现成本，小公司通常没有交互设计师的岗位，或者没有交互评审会议，但是增加交互评审会议的目的，是为了减少后期沟通成本，避免返工。

3. 技术评审中的技术方案、实现细节

1. 确定需求的技术实现方案，实现细节
2. android和ios达成一致，避免上线后结果不一致。
3. 对技术的代码梳理，从延展性，影响面，性能方面去考虑

4. 项目跟踪过程中debug、release版的进度和质量

1. 随时跟进debug版的进度和质量，保证基本demo方向，逻辑一致
2. 跟进release版的进度和质量，保证可用性测试，test case测试通过，产出的版本与设计一致，保证android和ios一致性。

5. 数据埋点需求

埋点分3种
- 代码埋点：技术人员按照pm的统计要求在代码中加入统计代码
- 可视化埋点：无须rd协助，pm、运营可自行在sdk后台加入统计代码，无须发布新版本
- 无埋点：技术人员在app中所有的按钮事件都加入统计代码，耗时耗力，对网络有性能要求
如果使用的第三方sdk不支持可视化埋点，则得请技术人员协助解决，如友盟只支持代码埋点，growing、诸葛支持可视化埋点，则无须技术人员协助

6. 学会尊重

首先，产品经理只是产品的经理，不是各职能角色的经理，和开发、测试、ui同事同级，并不具备领导权利。因此，在和技术人员沟通需求时，一定不要表现出经理的样子，以大压小只会使你离的更远，给予技术充分的尊重，平时呢，多和技术聊聊工作、生活上的事，给予鼓励，认可其工作成果，多担当，尊重技术的能力，一起协助解决问题。所以，以下的话就千万别说了。
- 别人app能实现啊
- 这个是老大的需求

7. 体现价值

大家都是来上班想做好事情、实现个人价值的（某些混日子的不在讨论范围内），讲清楚每一轮迭代，为什么做，做什么，做的价值，只要做的东西对公司、对客户有价值，那技术也会认可需求，只是具体实施过程中，怎么去结合团队现有资源做到最优，也就是mvp，因此，做好需求优先级很重要，从定性和定量的角度去分析需求，让各职能角色认可需求，使大家达成一致推进迭代。

 

最终所有的结果都是自己造成的，怪不得他人，我们需要的是冷静的处理所有的事情，所有的工作，善待他人。