可可情感网 > 情感生活 > 文章详情

沟通案例分析(讲述产品与研发的沟通方法)

日期:2021-06-01 12:24:09作者:人人都是产品经理图片:未知人气:+

产品经理(下文简称“PM”)在工作中,不可避免要和研发(下文简称“RD”)打交道。本文将通过笔者的三个亲身经历,讲述这几年从事PM工作时与RD沟通的心得体会,希望能对读者有所启发。

由于双方所处的立场不同,看问题的角度也不同,所以出现矛盾是在所难免的。笔者在此想通过三个案例,来讲讲PM和RD在沟通中出现分歧、争吵时,该如何处理,以及通过案例总结出的经验与教训。

案例一

曾经在某个项目中,测试人员(下文简称“QA”)发现系统的某项功能不符合需求文档的要求。虽然不影响业务流程,但是影响用户体验,因此告知RD修改。RD回复说需要改代码,只要涉及到改代码的,都必须发邮件告知,否则不处理。眼看争吵渐起,我作为PM必须要站出来处理。

为了不过多占据篇幅,在此不详细描述当时的问题,简单来讲就是系统需要调第三方接口返回指令,但是指令返回有延迟,这会影响到用户登录后看到的页面状态,所以需要在调用接口查状态时延时2秒。

需求文档中只写了用户操作后的系统状态和页面展示,没有写需要延迟2秒查状态,因此RD认为这相当于提了个新需求,而不是原来代码的bug,所以需要发邮件走流程。

我们和他说,需求文档在评审时已经讲过,里面的要求是用户在操作后看到的状态必须是准确的。需求始终没有变化,至于如何实现是技术上的问题,作为PM要保证的是设计方案没有超出技术边界,而不是对每一个技术方案的实现都去深入了解。

解决方法

虽然我自认为言之有理,但是最后并未说服对方,甚至还让他产生了抗拒情绪。考虑到项目上线时间紧急,如果坚持争执,只会耽误项目进度,造成双输的结果。

因此我和他说可以发邮件,甚至在邮件中说明是需求变动了,但是项目必须要按时完成,不能因此耽误进度。在得到我的保证后,大家继续讨论了方案,然后各自按照讨论的结果去执行了。

案例总结

1. 沟通时不要忘记最终目标

上述案例中,表面上要解决的是用户体验问题,但最终目标是保证需求按时上线且功能满足要求。坚持争论到最后或许能有结果,但是会耽误更多的时间,并对项目中成员的情绪造成不良影响,可能会产生更大的风险。

因此,PM在和RD沟通时要着眼全局来思考,把项目的进度放在首位,不要过于在意一时得失和责任归属。就算一时争吵赢了,从长远的角度来讲,也是双输的局面。毕竟PM是设计方案的人,RD才是实现设计方案的人。

2. PM要明白自己与RD关注点的区别

对大多数RD来讲,看到的是眼前自己负责的系统,想到的是如何实现功能、要多久才能实现、性能如何等。

而对于PM,从需求的角度来讲,要考虑用户的使用场景、用户的痛点、用户的使用习惯、使用后的反馈等。从项目进展的角度来讲,要协调项目资源、保证项目进度、解决项目过程中的问题,还有些PM甚至要考虑成本、盈利等问题,这都需要从整体的角度来看待项目。

当然,这里想表达的并非孰优孰劣,而是想借此说明,两者负责事项的类型和考虑问题的角度存在很大差异。就像上述事例中,笔者关注的是项目的进展和用户的体验,而RD关注的是这个算不算bug,以及如果不是bug为什么让他改。只有明白了彼此关注点的不同,才能更好地进行沟通。

3. 和RD沟通时适当讲讲宏观层面的内容

这里所说的宏观层面,并非是市场走向、公司战略这类的,而是产品的定位、策略、用户、场景、需求等。这么做的目的是为了让RD对需求有一定了解,能感受到自己的工作为用户解决了问题,为公司带来了收益。

只有项目组中的每个人有共同的目标,才能激发斗志,带动工作的积极性。所以笔者一直认为,PM在评审时一定要和RD讲清楚需求背景、使用场景、解决的痛点、面向的用户等。

其实不单是需求评审,平时的沟通中,像上述案例中的处理bug,开发过程中的需求调整,或是平时开会讲的产品路线,都可以讲讲宏观层面的内容,让RD了解到自己工作的价值。

案例二

笔者至今仍记得,第一次和RD争吵时的情景。这位RD平时不喜欢看文档,更不喜欢按照文档写的做,因此总出现问题。一般来说只要不影响用户使用,我就睁一只眼闭一只眼了(那时候刚去公司,存量需求十几个,涉及三个系统,忙不过来)。

某次需要修复数据(也是因为没有按照文档开发造成的),我便给他发邮件说明需求修复的字段和内容。因为怕他遗漏,所以我特意在邮件中将需要修复的字段标红加粗,结果还是漏了一个字段。想到他之前几次不按照文档开发产生的问题,一股无名火从我心头冒出,气势汹汹前去理论。

谁知这位振振有词,表示漏的那个字段是因为我没有当面和他说,他怕改错了担责任,所以没有改。借此机会,我问他为什么平时总不能按照需求文档开发,是评审时我没讲明白,还是我对开发进度不够关注。答案让我啼笑皆非,没按文档做不是开发的问题,是测试时没有测出来。

虽然听了很生气,但是看到他的态度,我明白除非把这件事闹大,否则不可能解决。依照案例一中说的,沟通时要时刻记得最终目标,我的目标有两个:一是让RD知道我对于不按照文档开发的态度,二是解决修复数据的问题。既然目标已经达到,就没有必要再争论下去。

解决方法

1. 不把本次争论的重点放在事情的对错上,而是关注如何尽快解决数据修复的问题。在之后的需求评审中重点关照下这位同事,多问问他对需求的理解,听听他的意见和反馈。

2. 和QA沟通,告知他之前测试过的项目有问题,今后需要再仔细些。同时在进行验收时,我也会更加认真,尽量把每一个点都验收到。

3. 幸运的是当时来了个新的QA,负责我这个系统。我给他讲了不少业务、系统相关内容,他遇到的问题我也会及时帮忙解决,一段时间下来配合得很默契。再加上他做事认真有章法,不论是写测试用例还是提bug都很规范(之前的QA这些都没有),对于RD不按文档做的问题坚决指出,一段时间内居然没再出现问题。

案例总结

1. 解决问题的方式有很多,不一定要直面问题

如案例二所述,与RD沟通不能解决问题,就需要从QA着手,加强QA对工作的重视,从而倒逼RD按照文档来做。这种做法看起来好像是在为难RD,但是从全局出发,是为了避免出现因为功能问题而回滚或者需要修复的情况。

其实,这件事还有其他的解决方法,例如把问题反馈给开发团队的leader,或者等到项目出现问题引起领导层的重视后再解决,又或者放下手中的工作掰扯清楚责任的归属等。总之,不同的人有不同的解决方式。笔者认为,在项目中个人的得失永远是小事,一切的沟通和处理问题,都要以项目进展为最优目标。

2. 维持良好的沟通氛围

案例二中笔者没有选择其他几种处理方法的原因,一方面是团队文化和内部氛围不允许,但是主要原因在于想要维持良好的沟通氛围。

工作中的每个人都会犯错,设想如果PM的设计出现漏洞,RD揪住问题不停责问,PM除了不爽外,还会感到压力山大。长期这样下去很难形成稳定、良好的合作关系。这样的氛围也会让项目组内人人自危,出现问题不愿意承担责任,甚至不想接手工作。

笔者在团队中总强调一个观点,即出了问题不可怕,应该把注意力应该放在解决问题上,而不是追责。互相指责不能解决问题,只能把团队氛围搞差,如果出了问题后每个人都只想着如何甩锅,那么问题谁来处理呢。

所以笔者认为,一个好的产品经理所维持的沟通氛围,应该是人人都愿意畅所欲言,人人都把处理问题放在首位,人人都愿意承担责任的。

案例三

最近新上线的项目,由于某些原因存在很多问题。这个项目上线前已经忙了两个多月,大家为了它停了手里的不少工作,原以为上线后可以松一口气,可是谁想到是这个样子,每个人心头都憋着火。

在某一次修复问题的讨论中,矛盾爆发了,项目组内的成员发生了激烈的争吵。争吵的内容毫无意外是责任归属,双方都认为是对方在系统对接时没有交代清楚才导致的问题。虽然争论双方都是RD,这次的问题也和PM没有关系,但是我还是介入其中希望能通过自己的努力来解决问题。

解决方法

先让同事停止争吵,然后告知项目组的每一个人现在讨论的目标不是为了追责,而是要让大家集思广益,尽快解决问题。目前还没到追责这一步,如果真到了这一步,我作为PM也会站出来承担责任。

最后让每个人明白,项目做了这么久很辛苦,上线后出现问题大家心里都不舒服,这个可以理解。但是有问题必须要解决,所以希望每个人在遇到问题时把注意力放在问题上,尽快把问题解决完,这样一个项目才算做的有始有终。

由于本项目中出现的不少问题都是沟通不到位导致的,因为我表示在解决问题的过程中,有需要我去沟通、协调、确认的,可以随时找我。然后大家又讨论了处理方案及分工,就各自归位去执行了。

案例总结

通过这个案例想要告诉读者,尽管有的问题并非PM的责任,但是PM在出现问题后不要想着置身事外,而是要主动参与其中调动团队成员去解决问题。

上述案例中,项目上线后出现问题,人心浮动时,PM要及时给项目组的成员鼓劲,告诉大家出现问题不可怕,只要按部就班解决问题就好。当团队成员出现矛盾、分歧时,PM要能站出来搞清楚问题的所在,帮助大家解决问题并时刻提醒大家牢记项目的最终目标。

总之,PM可以说既是项目的指明灯,同时也是项目的粘合剂。

受篇幅和案例所限,还有一些沟通方法和沟通时需要了解的注意事项,就不一一列出了。本文的目的是抛砖引玉,希望对读者能有启发,也希望读者能留言说说自己的沟通方法,不论是站在PM的角度还是站在RD的角度。

作者:打酱油的熊,公众号:打酱油的白熊

本文由 @打酱油的熊 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议

本站所发布的文字与图片素材为非商业目的改编或整理,版权归原作者所有,如侵权或涉及违法,请联系我们删除,如需转载请保留原文地址:http://www.gzkyz.com.cn/article/42765.html

人人都是产品经理

倾诉你的情感,分享属于你们的故事
私聊 +关注

手机版 | XML地图 | 网站地图

Copyright 2005-2020 www.gzkyz.com.cn 【可可情感网】 版权所有 | 湘ICP备20010517号

声明: 部分信息与图片素材来源于互联网,如内容侵权与违规,请与本站联系,将在三个工作日内处理,互联网不良信息举报邮箱:*****@qq.com