当前位置: 首页 >  微信公众号

三个案例,讲述产品与研发的沟通方法

19-11-07

产品经理(下文简称“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协议