蔡思贝,朱可儿,谢菲尔德大学-好习惯学习社区,为学习铺平道路

频道:最近大事件 日期: 浏览:257

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

声明:该文观念仅代表作者自己,搜狐号系信息发布渠道,搜狐仅供给信息存储空间服务。
热门
最新
推荐
标签