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

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