【带着情商做产品系列①】产品经理与开发沟通的三板斧

作者： 陈勃，文艺青年一枚。产品策划岗供职6年。写得了文档，编得了文章，做得了诗词，玩得了金属。

经常和开发（简称开发gg）开玩笑说，产品经理是一个高危职业，随时面临着被砍、被炒、被集体攻击、被要求请吃饭等，真是用绳命（生命）在工作。对此多少让人有些啼笑皆非。

但是玩笑归玩笑，仔细想想，产品经理面临的这种种“威胁”，从两方面提高注意力，应该能够避免：一方面是自身能力问题，更重要的一方面，是要考虑自身和外界的沟通问题。

本文主要是想和大家分享一下自身和外界沟通这方面，我对于“产品经理和开发gg沟通”这个问题的理解：从三个方面把控，提升沟通质量（权且称之为“三板斧”）

一、需求细节的把控

这里所说的细节把控，尤其是指在产品经理策划“提供给开发gg的PRD”时需要注意的：要将自己能考虑到的细节均描述在内。举一个很基础的例子：

如果是要实现一个注册页面，仅有用户名、邮箱、密码三个字段，如下图的视觉设计效果所示：

看起来简简单单的4个输入框和1个按钮，但对于产品经理而言，在策划PRD时，需要考虑的细节要素不下15个，我可以简单罗列一下：

用户名的格式要求、邮箱的格式校验、密码的长度要求、密码包含的字符要求、两次密码输入时的一致性校验、按钮默认显示状态、用户输入信息后按钮颜色变化效果描述、四个输入框用户输入错误时的报错提示文字、提示文字的摆放的位置、页面格式根据提示文字的变化，需要有怎样的视觉效果、用户不小心点击了左上角的返回按钮后的提示文字、误点之后的下一步动作描述、用户点击立即注册时在网络较慢的情况下，页面和按钮如何响应、是否要加锁屏浮层等等。

虽然以上细节要素中，有一些是需要交互设计和视觉设计给出效果图的，但是产品经理还是需要对一些动态效果、点击响应事件效果等进行详细描述。

假想如果产品在不告诉开发gg这些细节的情况下，开发gg应该怎样去理解和实现这些效果呢？如果开发gg专心做这一个项目，那么他耐心和产品经理反复沟通一下，也能达到预期效果。但是当开发gg身兼多职，业务异常繁忙时，就很难确保效果了。这不但影响开发gg心情，也难免会影响到产品经理自己的耐心。

近期我也有个经历，做一个注册功能：用户先是登记邮箱信息，登记成功后，系统自动给用户的邮箱发送一个登记成功的邮件验证码，用户用此验证码完成注册。

我非常认真的描述了整个登记和注册流程，提交给开发gg。当我正在庆幸自己考虑的很周全时，开发gg很无奈的说：“文档只描述了登记信息和注册流程，没有描述发送给用户的邮件。例如标题、邮件展示内容、展示字段、有问题如何反馈等”。这时我才恍然大悟：需求细节，没有最细，只有更细啊！

把控好需求细节，有3方面的好处：

一是可以在开发执行时，尽量减少开发gg和产品经理进入状态和跳出状态的时间成本。意思就是当一个人沉下去专注做一件事儿的时候，尤其是写代码或写文档这类，中间再跳出来做沟通的事儿，大脑会有一个进入状态和跳出状态的转换过程，这个过程需要时间。

二是减少开发gg在沟通过程中的“耐心”和专注精力的消耗。凯莉.麦格尼格尔在《自控力》一书中说，每个人的自控力每天都是有限的，而这里所谓的自控力，就是耐心和专注的精力。这也是为什么忙碌的人们往往会在下午五六点的时候脾气变差。

三是辅助功能，协助后期产品经理当作备份文档来查看自己的产品细节逻辑，尤其是逻辑复杂的产品。

通过细节的把控，可以给到开发gg更多的时间、更好的心情去做你的需求，那何乐而不为呢？

二、要有同理心

同理心，就是愿意站在对方角度考虑问题。

我们身边不乏这样的案例：PRD提交给开发gg之后，不再和开发gg讨论能否实现、如何实现、可否有更好的优化方案。而是直接定一个deadline，告诉开发gg说需求紧急，急到头脑生烟、双脚磨烂，必须此前完成，否则就杀人了。

这个时候即使开发gg同意了，心底里也会有反弹：不但考虑如何阅读天马行空的PRD，还要考虑如何在粗糙的PRD基础上自己去做完善，更要考虑如何加班加点把代码敲完。他的心情怎么能好起来呢？他怎能不厌恶产品经理呢？

当开发gg站在产品经理的角度，帮产品经理把粗糙的PRD完善好之后，他的耐心已经耗去十有八九。那站在开发gg的角度，产品经理会怎么考虑？会静心去分析每一行代码的实现逻辑吗？

我自己有个经历：洋洋洒洒五千字描述了十页的word，效果图+逻辑图+详细文字描述，提交开发后要求在4天内将一个商品价格体系的计算逻辑调整掉。开发gg看到后惊叹无比。其实我提交这个需求时，自己心理就清楚，按照现行的方案，4天内实现这个功能是根本不可能的。但我还是执意的把需求甩给了开发gg，想通过各种压力，逼迫开发gg完成需求。自己带着一份侥幸，带着一份不屑，也带着一份战战兢兢，期待着那个deadline来临之后，需求可以华丽丽的被完成。

但是我心理清楚，即使时间延长一倍，要完成需求也是有挑战的。

最终需求延迟完成之后，我在开发gg中的口碑也已荡然无存，人人愿得而诛之。

后来开发gg跟我说，需求开发完成后我曾问过一个问题：商品价格体系调整，是不是把涉及到的几个字段捋一捋，把折扣变一变？这句话让他想到了一个更好的实现方案，需求不用延迟那么久都可以实现的。

如果我在需求实现前，就能站在开发gg角度，考虑一下他们需求调整涉及到的具体字段、代码之间的关系和逻辑，也许就不会有后来的“人人得而诛之”了。

所以说，千万不能拿deadline给开发gg施加压力，并抱着侥幸心理等待deadline之后能出一个华丽丽的需求，而是需要站在开发gg角度，跟他们一起战斗，一起优化，一起完成。自己看不懂的，不要给他，自己觉得不可能的事儿，也不能强压给他，这就是产品经理的同理心。这里就引起了另一个问题，有人会问，我不懂代码怎么办？这就是下一点将会提到的“技术理解力”。

三、技术理解力

相信大家知道，咱鹅厂产品经理能力体系中，有一个很重要的指标，叫技术理解力。说白了就是，一个产品经理跟开发gg有没有共同语言，能不能听得懂开发gg在说什么。

也是举一个我自己的例子。

微信刚刚推出模版消息的时候，我看了手机上发出的消息，如下图：

就也想在自己的业务上实现。所以自己定义了标题、详细内容、链接地址等。直接就提交给开发gg去实施了。

当开发gg告诉我说，好像他们没办法直接实现，需要咨询一下微信的专业人士。

通过了解发现，首先需要在微信公众平台找自己业务对应的行业，并在行业中选择需要的模版，通过模版的字段才能来定义和发送。

首先选择模版：

然后看具体模版的定义字段：

根据具体的字段，定义好相应的内容，然后再通过每个模版的ID，通过开发实现，发送给用户。

了解之后，我只需要将模版ID，以及对应每个字段需要填充的内容提交给开发gg即可。根本不需要自己去设计一个模版消息的效果图，因为即使我弄了，微信公众平台中也不一定有我设计的模版样式。

这个例子说明了，如果没有一定的技术理解，不一定能够看懂微信公众平台的模版消息涉及的定义、字段等内容。

就像我刚开始不理解，走了交互、设计、文档描述，提交开发之后才发现不能实现。这两种不同的需求跟进风格，一方面时间效率相差很远，另外一方面，在自己未理解的情况下，冒然把需求提交到开发gg去，也会让开发gg一头雾水。

再次说明，技术理解就是和开发gg开始对话的前提，不懂的产品经理，赶紧恶补一下吧。

四、小结

以上从需求、心态、能力三方面，分享了产品和开发沟通时的个人感悟，我把这3个要点称之为“产品和开发沟通的三板斧”，并一直在工作中使用，对自己的工作也起到了很大的帮助。

欢迎小伙伴们一起尝试、探讨和提升。