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

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

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

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

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

在产品经理的工作中会经常接触的且要行使“经理”权利的角色一般有业务人员、设计人员及工程师。

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

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

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

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

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

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

如下图所示：

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

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

二、归属感之信息共享

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

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

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

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

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

那怎么做才能让工程师积极响应你的需求呢？

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

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

举个在信贷系统中绑定银行卡功能开发的例子：

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

如图所示：

经过一番深入灵魂的需求挖掘，发现用户是因为各种原因导致原来绑定银行卡不能用了，想换一个银行卡，还款时从换的卡里扣款。

其他需求如绑多张卡、多张卡轮流扣、或者从多张卡里分别扣一定的金额，都是业务人员自己的想法，结合当期系统的功能梳理好逻辑后与业务人员沟通。

产品：你提的需求我根据系统的实际情况梳理了一下逻辑跟你沟通过下，绑多张卡功能可以实现，而且也不太麻烦，因为我们已经开发过绑卡的接口了。

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

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

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

业务：嗯嗯，只有能在客户还款遇到问题是有办法解决就行，就按这个方案做吧！

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

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

工程师：这个方案挺好的，用户还卡的逻辑其实再绑一张卡，我们后台记录这张卡的信息，那原来的卡要解绑吗？

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

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

假设业务部门在提需求时我们直接拒绝说做不了，对方肯定会觉得这么简单的功能都做不了？是不想做吧！

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

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

三、尊重之共识

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

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

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

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

那如何在设计之初与工程师达成共识呢？

我们以信贷产品的还款流程为例：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

举个例子：

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

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

工程师：不能，大概要晚2-3天。你知道的，有个业务有紧急需要插进来，耽误了几天。

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

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

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

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

五、结语

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

在满足人性的成长需求后，你还觉得行使“经理” 的权利还困难吗？

本文由 @Mr.Yan 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议