三个案例讲述产品与研发的沟通方法如何提升沟

  产品经理(下文简称●◇▪•…●“PM◁★▷▼▼■”)在▷工作中○●,不可避免要和研发(下文简称•▽“RD…▪◁▲•△”)打交道▪●-△。本文将通过笔者的=三个亲身经历☆▪•,讲述这几年从事PM工作时与RD沟通的心得体会▲▷▼…●,希望能对=读者有所启发▪◆。

  由于双方所处的立场不同▼==,看问题的角度也不同△◇★■☆,所以出现矛盾是在所难免的▷△。笔者在此想通过三个◆◆▽案例□…◁◆★,来讲讲PM和RD在沟通中出现分歧□•■◇○、争吵时■□◁▪-,该如何处理■○,以及通过案□例◇总结出的经验•与教训▲…▪◆•。

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

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

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

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

  虽然我自认为言之有理△•○…△,但是最后并未说服☆对方▪□▽▷…,甚至还让他产生了●抗拒情绪☆☆●。考虑到项目上线时间紧急…▷▪◁◁,如果坚□持争执▼•◁★=▲,只会耽误项目进度=…▷▲,造成双□输的结果-△○★。

  因此我和他○说可以发邮件☆▪▲=□○,甚至在邮件中说明▷是需求变动了▷…▪●▪,但是项…目必须要按时完成=•,不能因此=耽误进度=▲▷●□-。在得●到我的保●证后▪▷□○•,大家继续▼讨论了方案▽★◆,然后各自按照讨论的结果去执行了■☆=•◆◁。

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

  因此-◇●,PM在和•RD沟通时要着眼全局来思考■▽,把项目的进度放在首位○▪☆◆=▽,不要过于在意一时得失和责任归属•▪▲。就算一时争吵赢了▼▽▲▷,从长远的角度来讲□△,也是双输◁的局面☆…▽◆★★。毕竟PM是设计方案▲的人-□,RD才是实现设计方案的人-•★◁。

  对◁大多数RD来◇讲▼★▲,看到的是眼前自己负责的系统•★,想到的是如何实现功能▷=▪-、要多久才能▽…实现=★、性能如何等◆▪□◁▲。

  而对于PM…▽★☆,从需求的角度来讲☆▷◆☆,要考虑用户的使▼用场景☆▪▪、用户的痛点◇-、用户的■使用☆习惯◆…▷-=、使用后△的反馈等○▪★☆△。从项□目进展的角度来讲◇◇◁◇•,要协调项目资=源★☆、保证项▲目进度•-□、解决项目过程中的问题•-◇,还有些PM甚至要考虑成本▼▼☆▪○、盈利★等问▲题▷•▪▲,这都需要从整体的角度来看待项目•□。

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

  这里所说的宏观层面-▼☆,并非是市场走向▷□、公司战略这类的▽…•☆◇■,而是产◇品的定位=△、策略-●●•■、用户==、场景•☆☆◁▲、需求等◁•▪◇▷。这么做的目的是为了让RD对需求有一定了解★●□•◁▽,能感受到自己的工作为用户解决了问题◆□□,为公司带来了收益-▷▼。

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

  其实不单是需求评审◆▷◇★,平时的▲沟通中…◇◆▼▼•,像上述案例中的处理bug○▼○,开发…过程中的需求调◁整•◇…▽□•,或是平时开会讲的产品路线●▷▲,都可以讲讲宏观层面的内容△★▪=★,让RD了解到自己工作的价值-•△●◇…。

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

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

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

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

  1△★▲. 不把本次争论的重点放在事情的对错上☆★◁==■,而是关注如何尽快解决数据修复的问▷题▼○▪。在之后的需求评审中重点关照下这位同事★▼☆◁•▪,多问问他对需求的理解△◁,听听他的意见和反▼馈◁●△-◆▪。

  2=◇▲■▽. 和QA沟通◆▽,告知他之前测●试过的项目有问题■■★☆,今后需要再仔细些☆●◆▽。同时在进行验收时■▽…,我也会◁更加●认真◁•□,尽量把每一个点都验收到■-◁-。

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

  如案例二所述■◆=◆,与RD沟通不能解决问题▲▼,叛逆期孩子的沟通技巧就需要从QA着手•▽•,加强QA对•工作的重视△•,从而倒逼RD按照文档来做◇■★▪。这种做法看起来好像是在为难RD▪•▽◆☆,但是从全局出发□●…,是为了避免出现因为功能问题而回滚或者需要修复的情况▽-=…。

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

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

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

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

  所以笔者认为★▽-▽★▷,一个好的产品经理所维持的沟通氛围◆○•-○□,应该■是人人都愿意畅所欲言=…○▼,人人都把处理问题放在首位△▷◆■◁★,人人都愿意承担责任的◆▽。

  最近新上线的项目△-△★•,由于某些原因存在很多问题◆▽◁■。这个项目上线前已经忙了两个多月•■•■◇,大家为了它●停了手▷里的不少工作▲■◁▲-,原以为上线后可以松一口气•▽◁=…,可是谁想到是这个样子=◆■,每个▼人心头都憋着火=▪…▪▽。

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

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

  最后让每个=人明白●•■■◁▼,项目做了●这么久很辛苦-=-,上线后出现问题大家心里都不舒服…■☆=,这个可•△以理解••◇•▪。但是有问◆题必须要解决▼☆,所以希望每个人在遇到问题时把注意力放在问题上■▷•,尽快把问题解决完○▷=,这样一个项目才算做的有始有终▽•▪…□。

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

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

  上述案例中△▷▪◆,项目上线后出现问题•□▼=◆,挽回男友人心浮动时◁□•…=-,PM要及时给项目组的成员鼓劲▷☆=☆,告诉大家出现问题不可怕◇□•○,只要按部就◁班解决问题就▽好○•。当团队成员出现矛盾★◁、分歧时■▽★=,PM要能站出来搞清楚问◆题的所在◇▼△▼,帮助大家解决问题并时刻提醒大家牢记项目的最终目标☆★△=◁。

  受篇幅和案例所▽限…▲△□-◇,还有一些沟通◇方法和沟通时需要了解的注意事项◁■☆□,就不•一一列出了●◇○▽。本文的目的是抛砖引玉●◁▪•-,希望-◆对读者能有启发▪▷▼=□,也希望读者能留言说说自己的沟通方法△▷,不论是站在-PM的角度还是站在RD的角度◇▽▼。

  以前一点不理解你们这些产品经理的官方术语…▪,不理解☆什么测试▲◇,什么改bug=-。自从面试产品助理后◇=▽,原来这些都是根据需求来验证的技术测试▽▪○★•。

  产品菜鸟一只▽■◆,刚从实施转产品◆▼★▪,恰好研发技术经理对业★务和客户超级熟悉▽△◆•■…,经常做的设计被开发拒绝★☆■,也是比较郁闷•-•△=…,不过能意识到是自▼己对于产品的熟悉程度不够=■,还是要努力•学▪▷习◇★▽,不过还是亚历•山大哦

  我的观点■●●,任何的矛盾根源都是彼此推卸责任•★△,害怕担责•◆…▼▽•,都是因为大家目标不统一▼•△,意识不统一●◆,更重要的在于产品经理或者开发负责人无责任意识◁◆•●•△,最终导致对于不团结▽…=▽▪,项目延期▲=,产品上线

  人人都是▽▽产品经理(是…以产品★经理▷◁▽▪☆●、运营为▼核心的学○习▼▼▪□-、交流◇••、分享平台▼•…,和客户聊天技巧话术集媒体▷★◆、培训▽▼…★▽、社群△为•一★体▼▼▲,全方位服务产品人和运营人□●▼◇▷,成立9年举办在线+期☆…□…,线+场★…◆…◁,产品◁经理▪大会◆▼、运营大会20+场=◇☆▼▪☆,覆盖北上广深杭成都等△15个城市□…=▼,在行业○有较高的影响力和知名度•◇◇☆。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监△◇…☆●▪,他们在这里与你一起成☆长○■▷•■。三个案例讲述产品与研发的沟通方法如何提升沟通技巧极速体育下载