没经理权利的产品经理如何做好“经理”的事儿?

编辑导语:产品经理往往要对工程师提出各种各样的需qiú,而这些需qiú就会转化为工程师的工作量,因此在产品经理与工程师之间就存在着一定的博弈。对于没有经理泉力的产品经理来说,如何才能调动工程师的积极性、满足他们的需qiú,从而顺利的推动项目的进度呢?来看本文作者的分析吧。

产品经理苦“经理”久已,想必每一个产品经理在工作中都或多或少的遇到过被怼的情景。

其缘由大多也都是怼我们的人认为我们产品经理没有经理的X,却总是行使“经理”的X提各种各样的需qiú,那做为一个没有经理X的产品经理如何做好“经理”的工作呢?

一、影响做“经理”工作的因素

在做“经理”工作前我们要分析影响“经理”工作的因素都有哪些,就像X向我们提出需qiú时,我们要先分析需qiú的背后本质的是什么一样,只有挖掘出需qiú的本质才能设计出让用户满意的产品。

在产品经理的工作中会经常X的且要行使“经理”X的角sè一般有X人员、设计人员及工程师。

拿与产品经理“积怨已久”的工程师举例:产品经理与工程师的对立的原因是在工作liú程上处于工程师的前置位,所会对工程师提很多需qiú;而每一个需qiú都会转化为工程师的工作量,需qiú的多少决定着要做的工作量的多少,这就形成了天然的形成产品经理与工程师博弈。

在这场博弈中工程师注定是要失败的,因为产品经理往往带着X人员、老板的加持,让工程师不得不接受产品带来的需qiú,由此种种产品经理与工程师的对立油然而生。

但这种对立也只是表象,产品经理与工程师对立的本质的产品经理是在与人性对抗。因为人性的本质是懒惰的,X的发展就是满足人性的懒惰,不然不会有马车以及更快的马车——汽车、不会有外mài、不会有……

但人性也是积极的,前提是要有合理的动机,作为一个合格产品经理如何调动人性积极一面来行使“经理”的X的重要不言而喻。

我们经常用马斯洛需qiú分析我们产品是否能满足用户的某一需qiú,同样的在做“经理”的工作的时候也同样适用。我们可以把团队中的其他成员当成我们的用户,分析我们如何满足他们的需qiú从而推进项目的进度。

马斯洛需qiú的五个层级从低到高分别是:生理需qiú、安全需qiú、爱与归属、尊重需qiú、自我实现。五个层级又分为两大类,其中生理需qiú与安全需qiú为缺失性需qiú,爱与归属、尊重需qiú、自我实现为成长性需qiú。

如下图所示:

生活在和平年代的我们已经满足了缺失性需qiú,但成长性需qiú却是伴随我们终生的。

下面我们从成长性需qiú的爱与归属、尊重需qiú、自我实现三个方面聊聊如何对抗人性的懒惰,给予人性积极的一面以合理动机,让产品经理能愉快的行使“经理X”。

二、归属感之信息共享

与团队成员共享有关项目的所有信息,让团队成员感觉的到是大家一起在做事情,而不是某一个人在做事情,从而产生归属感。

产品经理的岗位是获得信息的最多的一个岗位,因为我们经历了一个功能从需qiú的提出、到功能的设计、再到功能最终定稿的完整liú程。所以我们知道为什么要做一个这样功能、做这个功能能满足什么样的目的、这个功能是否值得我们做等相关的显性及隐性信息。

但当我们与工程师评审时往往会比较简单的讲需qiú的原因及目的,更有甚者可能就是一句带过,然后直接讲功能的逻辑及要qiú。这就到导致工程师的感知是——又来任务啦,这个需qiú着急上线又要加班了。

对工程师而言,产品经理又派给我们更多的工作。

当我们讲完需qiú后经常得到工程师的反馈不是“这个功能做不了”就是“你的给的时间太短了最少需要两倍的时间才行”,面对这样的永远有做不完的工作时候,不要说是工程师了,相信每个人都会消极懈怠的。

那怎么做才能让工程师积极响应你的需qiú呢?

X马斯洛需qiú中的归属感可窥见一二,那就是要与团队共享信息,让大家知道做一个功能的前因、后果以及要达到什么样的目的、和未来的规划;而不是需要用到那个人的时候才让TA参与其中,搞得每个人都是一头雾水的在做事,觉得做好眼前的事情就行了,其他跟我无关,更不要提什么归属感了。

所以要让团队每一个成员都了解项目的动态,从而营造团队成员的归属感。

举个在X系统中bǎng定X卡功能开发的例子:

背景:X部门反馈很多客户还款的时候原来bǎng定的X卡没钱想让扣从另外一个卡里扣,我们现在只支持bǎng定一个X卡,想加个功能像支付宝一样可以让用户bǎng多张卡,这样扣款的时候就从多张卡里扣了;如果多张卡都扣不到的话,还能分别从多张卡里扣不同的金额凑够应还的金额,这样客户就不用麻烦来回转钱了。

如图所示:

经过一番深入灵魂的需qiú挖掘,发现用户是因为各种原因导致原来bǎng定X卡不能用了,想换一个X卡,还款时从换的卡里扣款。

其他需qiú如bǎng多张卡、多张卡轮liú扣、或者从多张卡里分别扣一定的金额,都是X人员自己的想fǎ,结合当期系统的功能梳理好逻辑后与X人员沟通。

产品:你提的需qiú我根据系统的实际情况梳理了一下逻辑跟你沟X下,bǎng多张卡功能可以实现,而且也不太麻烦,因为我们已经开发过bǎng卡的接口了。

但实现多张卡轮liú扣款的功能有点难,因为我们要改产品的全部扣款逻辑,这个需要挺长的开发时间的;还有另外一个问题是如果按这个逻辑去做,每个人都可能要扣多张卡会。导致我们每曰批量扣款的时间特别长,如果用户量太大,有可能一天都扣不完。

另外一个从多张卡里扣不同金额凑够应还金额需qiú,首先每张卡里扣多少,很难确定。因为我们不知道卡里的余额,如果扣不到再降低扣款金额,这个逻辑就更复杂了

其次阶梯性扣款这个做fǎ不合规,我们不能做这个功能。我这边有一个解决方案,就是让用户换一张bǎng定X卡,只需增加一个换卡功能就能搞定,开发时间也能满足你的近期上线的要qiú,而且没有合规问题。

X:嗯嗯,只有能在客户还款遇到问题是有办fǎ解决就行,就按这个方案做吧!

经过一番精心设计后,拿着原型开评审会。

产品经理:这个需要的来源是……..(讲与X沟通中得到客户在使用中遇到的困难,导致产生的问题),因为我们当前系统………(讲为什么设计换卡,而不是设计bǎng多张卡的思考过程),所以设计了这个功能,大家有什么更好的方案吗?或者这个功能的逻辑有没有问题?

工程师:这个方案挺好的,用户还卡的逻辑其实再bǎng一张卡,我们X记录这张卡的信息,那原来的卡要解bǎng吗?

产品经理:设计时没考虑到这点,要解bǎng的。从客户的感知来讲是换了一张卡还款,原来的卡bǎng定关系已经没了,所以还是要解bǎng的,不然可能万一扣错了客户会投诉的。

最终和大家讨论完所有的可能性,形成一个团队认可的方案然X入开发阶段。

假设X部门在提需qiú时我们直接拒绝说做不了,对方肯定会觉得这么简单的功能都做不了?是不X吧!

在评审时如果不讲前因后果工程师对新增工作量肯定也有抵触情绪,所以与团队其他成员共享你的得到的所有信息,让团队成员了解提需qiú的始末及目的并与大家一起讨论问题的解决方案。

让团队成员感觉到是大家一起在做这件事儿,从而让团队成员产生归属感。

三、尊重之共识

在设计之初就要多与团队成员沟通寻qiú他人的意见以表尊重,并对就最终解决方案与团队成员达成一定的共识。

相信大家都遇到过评审时与工程师剑拔弩张的场景,原因大多都是因为某一功能开发与否或开发周期未能与工程师达成共识,且大家都认为自己的想fǎ是合理的。

而问题的争论可能从一开始的就事论事,到最后成了为证明自己对的而争论了,而这种争论对项目的进度却没有任何帮助的。

所以为了尽量避免这种场景经常发生,我们在做设计之初就要与工程师就新功能的逻辑达成一定程度共识,不用完全达成共识。

那如X设计之初与工程师达成共识呢?

我们以X产品的还款liú程为例:

背景:很多用户可能会在还款曰忘记往卡里打钱,导致还款失败,X一般都会在上午扣款失败后告知客户,今天是还款曰,该往卡里打钱啦。

由于时常发生客户向X卡打钱时间晚于第二次扣款时间,导致客户X卡里有钱,但还是没有当曰还款状态还是失败;虽然有宽限期,但客户还是会担心逾期上征信,就会打X给客服让扣款。但因为系统当前支持批量扣款,只能等第二天才批量扣款才可以。

这样客户和客服之间很容发生矛盾导致客户投诉,因此需要增加一个可手动发起对单个客户扣款的功能。

如果产品经理直接设计好功能给工程师,工程师就不理解为什么需要这个功能,有宽限期第二天扣不一样嘛;但如果我们换个方式用上一章提到的信息共享的方式向工程师讲解需qiú场景,再讲一下如果不能解决这些客户的问题会导致客户投诉的后果,然后向工程师请教解决方案(有时候即使你已经有了解决方案也有必要这么做)。

产品经理:你觉得我们怎么做才能解决这个问题?

工程师:手动处理吧,系统只支持批量扣,只能我们手动处理了。

产品经理:能不能做个功能,让运营自己cāo作,不能总是找你们手动处理,这种事儿多了估计你们也烦。

工程师:也对!还不如做个功能一劳永逸,那就在X给他们个按钮让他们自己扣吧,那你设计设计看放哪吧。

产品经理:得嘞,我先设计下原型,设计的差不多了在跟你过下看有没有逻辑漏洞哈。

这一顿cāo作后再评审的时候工程师肯定就不会再提出更多的质疑了,因为在这之前你们就已经达成了共识,认可了这个功能必要性。

产品经理因为在工作中有承上启下的作用,如果语言和行为不当就会给团队其它成员留下你是他们X的印象,从而让其他团队成员产生X情绪。

所以要让团队成员多参与产品的设计,多向他人请教,要让团队成员感觉到你对他们的尊重,产品设计会参考他们的意见,与他们就功能设计达成共识。

四、自我实现之及时有效的反馈

X及时有效的反馈让团队成员知道自己做的事情是正确的、有价值的从而满足人性的自我实现需。

我们XX其实是一个不太善于直接表达感情的X,一般表达情绪时都比较委婉,这种方式在X一个人时会比较好用,不会让别人觉得很尴尬;但在表扬一个人时可能效果就不会太好,别人有时候可能会感受不到你在表扬他。

假如你负责的项目克服了种种困难成功按时上线了,这时X一般都是讲:大家辛苦了,希望大家继续努力。

明明是想表达表扬意思,可听起来总感觉怪怪的。之所以会形成这样的印象,是因为我们在表达感情时没有把表扬、建议分开。

而且我们在表扬一个人时总是希望积累到一定程度再一次性表达出来。

人都是有自我实现需qiú的,表扬是没有时间X的,我们应该的及时表扬以改善团队的工作状态,提高团队的工作效率。这样做的成本很低,但效果却会很好。

举个例子:

产品新版本更新的时间眼看就要到了,但开发团队因为有临时的需qiúX来导致可能要延期几天才能上线,但老板又要qiú一定要按时上线,只能与工程师沟通看能不能加班赶下进度。

产品经理:大佬咱们2.6版本下周一能按时上线吗?

工程师:不能,大概要晚2-3天。你知道的,有个X有紧急需要X来,耽误了几天。

产品经理:我知道最近X有个紧急需qiúX来,这个问题已经导致客户投诉了,优先较高只能先做这个,我理解。这次上线的功能有几个是老板提的,所以老板一直在问进度,要qiú一定要按时上线,这咋整啊?

工程师:那我们周末加加班吧,这样应该的按时上线。

产品经理:那辛苦大家了,我一直在忐忑怎么跟大家讲要加班赶项目进度了,没想到大家主动提出加班赶进度。能跟你们共事,真的让我感觉自己运气好到X。

这时候一定要及时并明确的表扬,但要注意的是不能为了表扬而表扬;如果表扬不是真诚只是为了维护团队的气氛和恭维他人,这种假意的表扬他人其实是能感受得到,往往会适得其反,所以表扬一定要是X的感受。

五、结语

X信息共享让大家都了解自己参与的项目的动态,营造团队的归属感,满足人的归属感需qiú;X讨论解决方案达成功能应该做成什么样的共识,满足人性的尊重需qiú;X及时有效的反馈,让他人感觉到自己做的是有价值的事情满足人性的自我实现需qiú。

在满足人性的成长需qiú后,你还觉得行使“经理” 的X还困难吗?

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 没经理权利的产品经理如何做好“经理”的事儿? https://www.xiongfawang.com/1880.html

常见问题

相关文章

没经理权利的产品经理如何做好“经理”的事儿?-海报

分享本文封面