本文主要是想和大家分享一下自身和外界沟通这方面，我对于“产品经理和开发gg沟通”这个问题的理解。供有意愿和开发gg共谋大事的产品经理参考。
经常和开发哥哥（简称开发gg）开玩笑说，产品经理是一个高危职业，随时面临着被砍、被炒、被集体攻击、被要求请吃饭等等，真心是用绳命（生命）在工作。对此多少让人有些啼笑皆非。
但是玩笑归玩笑，仔细想想，对于产品经理面临的种种“威胁”，个人从自身工作经验角度感觉，有两方面需要注意：一方面需要考虑自身能力问题，更重要的一方面，是要考虑自身和外界的沟通问题。
对于自身能力问题，我早些时候有写过一篇《成熟产品经理必备的特质》，在此就不罗嗦了。本文主要是想和大家分享一下自身和外界沟通这方面，我对于“产品经理和开发gg沟通”这个问题的理解。供有意愿和开发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角度，考虑一下他们需求调整具体涉及到的字段、代码之间的关系和逻辑是怎样的，也许就不会有后来的“人人得而诛之”了。
所以说，千万不能拿deadline给开发gg施加压力，并抱着侥幸心理等待deadline之后能出一个华丽丽的需求，而是需要站在开发gg角度，跟他们一起战斗，一起优化，一起完成。自己看不懂的，不要给他，自己觉得不可能的事儿，也不能强压给他，这就是产品经理的同理心。这里就引起了另一个问题，有人会问，我不懂代码怎么办？这就是下一点将会提到的“技术理解力”。
三、技术理解力
相信大家在多种渠道都接触过，腾讯公司的产品经理能力体系中，有一个很重要的指标，叫技术理解力。说白了就是，一个产品经理跟开发gg有没有共同语言，能不能听得懂开发gg在说什么。
这个能力，对于懂得的产品经理，不说也懂。但对于不懂的产品经理，怎么说可能都不太懂。也是举一个我自己的例子。
微信刚刚推出模版消息的时候，我看了手机上发出的消息，如下图：
就也想在自己的业务上实现。所以自己定义了标题、详细内容、链接地址等。直接就提交给开发gg去实施了。
当开发gg告诉我说，好像他们没办法直接实现，需要咨询一下微信的专业人士。
通过了解发现，这个需要在微信公众平台找自己业务对应的行业，并在行业中选择需要的模版，通过模版的字段才能来定义和发送。
这时候我才明白了，原来并不是我们想怎么做，就能怎么做的。而是要先了解微信对于模版消息的定义。
首先选择模版：
然后看具体模版的定义字段：
根据具体的字段，定义好相应的内容，然后再通过每个模版的ID，通过开发实现，发送给用户。
了解之后，我只需要将模版ID，以及对应每个字段需要填充的内容提交给开发gg即可。不要提交交互及视觉设计去自己弄一个模版消息的效果图，因为即使我弄了，微信公众平台中也不一定有我设计的模版样式。
这个例子说明了，如果没有一定的技术理解，也不一定能够看懂微信公众平台的模版消息涉及的定义、字段等内容。
就像我刚开始不理解，走了交互、设计、文档描述，提交开发之后才发现不能实现。了解过后才发现，只需要填写相应字段的内容，并通过模版ID就可以发送。这2种不同的需求跟进风格，一方面时间效率相差很远，另外一方面，在自己未理解的情况下，冒然把需求提交到开发gg去，也会让开发gg一头雾水。
当然这只是一个简单的例子，还有一些和开发gg一起梳理代码逻辑的例子，就不一一赘述了。
再次说明，技术理解就是和开发gg开始对话的前提，不懂的产品经理，赶紧恶补一下吧。
四、小结
