作者: 陈勃,文艺青年一枚。产品策划岗供职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个要点称之为“产品和开发沟通的三板斧”,并一直在工作中使用,对自己的工作也起到了很大的帮助。


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