产品汪如何与程序猿沟通

fruit

　　今天要说的是IT互联网行业由来已久的恩怨情仇，产品汪和程序猿之间相爱相杀的故事。作为产品经理如何与开发高效和谐的沟通。
　　一
　　沟通很重要
　　一个产品从孕育到诞生，到实现商业价值，为公司盈利，为用户解决需求乃至解放生产力改变世界需要多种角色、不同工种参与高度协同。而产品经理在这个过程中扮演着主导和推动协调的作用，这就需要产品经理具备业务、技术、设计运营等多方面的知识，并且可以良好的与这些不同专业的人员进行高效的沟通。如下图。PMI给出的统计，一个项目平均90%时间都是用在沟通上，而时间就意味着成本，从项目管理上，高效的沟通就意味着更低的成本，和更小的风险。

　　产品经理的知识也是一个杂货铺。产品的方方面面啥都可以管可以指手画脚的感觉很爽，但这也同时意味着很大的责任和压力因为任何方面除了问题，PM责无旁贷。多工种高度协同是一个系统性的复杂问题，本文从将讨论这个问题的一个小方面，产品与开发间的沟通，力图减少产品经理因与开发工程师沟通不好引发的种种负面结果。
　　二
　　用什么语言交流
　　沟通一词英文是“Communication”，它的词根来源于拉丁与“communis”意为共同的。产品经理想要与开发高效地和谐的沟通，需要产品经理了解工程师所说所习惯的语言，或者可以理解为描述问题的方式。这就需要产品汪了解程序猿的文化，知道他们习惯的沟通方式。
　　在程序员圈子里，流传着这一样一个对联，我想可以从中了解他们的沟通文化。
　　上联：Talk is cheap
　　下联：Show me the code
　　横批：No can no bb
　　程序猿喜欢有助于他们迅速技术实现落地的沟通，单纯的语言表述是苍白的。当然，PM 无法每一次都去 show code，毕竟PM的开发能力有限。
　　01
　　原型图
　　原型图是产品与开发沟通的一个高效由有力的手段，相对于语言描述，原型图可以快速直观的让开发人员理解你想要一个什么东西。需要注意的是，对于产品业务逻辑比较复杂的情况，单单原型图并不足以充分的描述需求设计的细节。这时候就要配以与原型相关的流程图和规则说明，或者摘取PRD中相关章节和开发人员一起研读。
　　02
　　Demo
　　对于一个新的功能或者小技术点，有时候开发人员之前没有做过，PM如果可以在技术博客、GitHub等资源上找到对应产品需求的Demo程序，与开发一起讨论。可以帮助开发更快的理解功能并降低他们的压力。看到已经有现成的Demo可以参考，开发的压力也会相对小了，这也减少了在沟通新需求时开发的抵触情绪。
　　03
　　5W1H
　　产品多数时间与开发沟通的对一些细节问题的非正式沟通，沟通的方式可能是线上聊天，开发GG的工位旁边，或者是吸烟区一起散烟的时候。相比正式的会议，会后有详细的纪要，在非正式沟通的时候需要注意做到5W1H，来保证讨论为题和结论的有效。5W1H即：
　　Why-问题的背景和意义
　　Who-谁来干，输出给谁，上下游
　　What-集体问题
　　When-时间点
　　Where-使用场景、部署环境等　　How- 方案
　　在和开发哥哥聊完后，回顾一下是内容否包含了5W1H，以便出现纰漏。可以再发个邮件备案一下。
　　三
　　沟通背后
　　01
　　了解程序猿
　　想要和开发小哥哥们好好的沟通，还需要了解他们的性格，比如他们的对于用技术改变世界的骄傲。对于反复修改需求的痛恨。开发小哥哥到多为人直率，遇到问题会直接指出不拐弯抹角，能怼你的时候不会惯着你。但正因为这些特点，他们可能会帮助产品经理找出产品设计中的弊端和一些忽略的点。对于爱思考有owner精神的开发小哥哥，PM要常怀感恩，就事论事。不要为了所谓的“面子、领导力”而做个杠精嘴上不饶人，寸步不让。有错误主动认错，尊重知识、尊重专业，一切为了推动产品开发进度，为用户输出更好的产品。
　　02
　　腹有诗书气自华
　　优秀的产品经理，他们在沟通的时候可以从专业的角度去以理服人，表达自己的想法，要从说明需求的原因让开发人员明白需求的意义，而不是简单粗暴的“老板说的”或者“业务要求的”。产品经理需要不断的学习，丰富自己的各方面技能，这样才能在沟通的时候更令人信服。所以要做好知识管理，多读书~
　　六
　　总结
　　沟通是一个很大的学问，本文只提了其中的几个方点，还有几个需求要找开发哥哥改一下O(∩_∩)O哈哈~，时间关系未完待续~
　　最后想说的是，产品汪和程序员之间的相爱相杀，爱可以更多，因为我们都是为了一个共同的愿景，打造更好的产品。愿产品成为我们爱的结晶。
　　图片源自网络，侵删~