据说，持有这四种工作态度的产品经理们可保性命无忧，可保不受白眼，可被人人喜欢，以及可带团队玩耍。你，想知道吗？

最近看到知乎上一个问题，“外科医生为什么很喜欢讲黄段子？”在大批答案下，默默地收获了好多之前没看到过的专业污段子，果然一污更比一污深，小女子还是“太连清”。

虽然好像答不对题，但是我也好想回答一下这个问题：

什么外科医生喜欢讲黄段子呀，明明是人多的地方都喜欢讲呀，尤其男人多的地方，金融呀、互联网呀，都一样，套路都“婶婶”的。

比如，我今天中饭又点了上海人家的仔排年糕外卖，旁边的骨哥就感叹了一下，“你爱上了上海人家。”，一下子不得了了，套路都来了：

“你们说，‘你爱’是谁？”

“那个‘了’又是谁？”

“难道你们已经知道‘海人家’是谁？纯纯的我并不懂呀！”

卧槽，已经脑洞了一整部人体蜈蚣了好咩……

知道俺们测试环境的图片都是啥咩？都是漂亮妹纸们，中国的日本的美国的泰国的（真的不是18禁）哪天要是看不到妹纸皂片了，还以为自己进错正式环境了；

知道俺们平常码代码吐血了怎么办咩？分分钟就有老司机开起小火车，不赶紧上车都不行啊！

话说到这儿，成功迎来产品汪们保命的第一招：

集体火车开起来，污污更和谐

不是说真的一定要讲黄段子啦，重点在于，要和开发们在非需求条件下还关系融洽。

什么叫“非需求条件下”？就是不做需求的时候，大家关系还是比较好。

为啥要关系融洽呢？先说说大家选择一家公司的目的是什么好了，无非几点：

• 公司给得了利
• 公司给得了名
• 公司总体气氛不错
• 团队气氛好、靠谱
• 团队小伙伴有意思

利与名都和公司有关系，我们没有办法改变。但是，团队的气氛如何？伙伴有木有意思？我们还是可以影响的嘛。非需求情况下的我们，友爱兼有爱那是极好的。

至于怎么个友爱且有爱，这个就各自发挥了：

• 一起吃个饭啊
• 一起污一污啊
• 一起讨论业务碰撞火花啊
• 一起团个建啊
• 一起吐个槽啊
• 一起色个诱啊
• 一起搞个基啊

方法千千万，就不多赘述了。

码prd、搞设计、撸代码，正常情况下，不太可能连续高度集中转一小时以上，这种情况下咋整？一起活跃下气氛嘛，缓解下脑补压力，顺便不知不觉中增进点团队感，多好。

刚刚讲了“非需求情况下”的关系和谐，以下再来讲三个“需求情况下”的关系和谐必备三招：

需求别乱提，要有理有据，我们是需求的百度百科

看起来感觉是废话，对咩？其实并不是的。太多产品汪们其实并不知道这个意味着什么。

1、需求要对自己有理有据

决定做一个需求前，自己要想清楚为什么要做、做了有什么好处、怎么去检测好处、如果做错了怎么办等等。

把这个版本根据产品现有状况想做的需求都列出来，它可能是这样的：

• 产品要做的需求1
• 产品要做的需求2
• 产品要做的需求3
• 产品要做的需求4
• 产品要做的需求5
• 产品要做的需求6

然而，产品狗们都懂的，事实离以上相差甚远，实际上很有可能是这样的：

• 产品要做的需求1
• 产品要做的需求2
• 公司层面要做的需求1
• 公司层面要做的需求2
• 项目负责人要做的需求1
• 项目负责人要做的需求2

在这种情况下，你要去理解公司/项目负责人为什么要这么做、原因是什么、是否和现有的产品方向违背、是否和现有的产品节奏违背。

• 如果你能理解并且支持，那么自然是最好的，可以有理有据去做需求；
• 如果你能理解但不支持，那么以上层决策大于个人决策的基本法，在沟通依旧无效的情况下，还是只能放下个人想法，但依旧可以有理有据去做需求；
• 如果你不能理解但支持，那无法对自己有理，虽然有据，这个需求就没办法做下去了；
• 如果你不能理解也不支持，那感觉您可以从公司撤退了。

很多产品经理在第三种、第四种的情况下还依旧把这个需求丢给开发，这其实是非常不负责任的。

因此，务必让自己处于前两种状态中。

2、需求要对对接方有理有据

产品经理们要端正一个态度，那就是：不要把设计师们当做作图工具、不要把开发们当做代码工具。其实，他们也感兴趣自己做的到底是个什么东西、到底为什么要这么做。

所以，在出来一个需求的时候，需要在和他们沟通具体逻辑的前面，先和他们沟通为什么要这么做。

同时，这么做还能无形中带来一些好处：身处需求中的设计和开发，能够慢慢从对做的产品有业务概念上的认知到对用户需求的认知。虽然这个时间可能比较长，但是建立在实际理解的基础上做出来的东西和没有理解基础上做出来的东西，无论是做的过程还是做的结果，都会有比较大的差别。

那怎么和对接方们沟通需求背景（为什么做）呢？可以从公司决策上、从业务上、从数据上等单方面或者多方面结合的看人下菜进行讲解。

举个我们自己遇到的实例：

其实昨天下午，这个讨论就在我们团队里发生了。在我讲完几个需求之后，听讲的飞哥和韩哥哥提出了一个质疑和一个建议：

• 为啥我们要做这些需求呢？
• 是否可以在确定这些需求之前让我们参与讨论呢？

然后翻墙仔也说了自己的看法：“你不能单从用户的数据角度就说我们要做这个需求呀。”

然后，我就突然发现还不能单从一个角度去说服他们，所以又从业务、从公司的角度来描述了一遍做那几个重要的需求的原因，最后他们表示理解了。

同时，我们也暂时约定了在定下需求列表但未进入确定的需求分析的时候，就告知他们这些，同时可以征求大家的想法。

我觉得这种氛围在小团队里其实很好，每个人都参与，是一份子，而不仅仅是你递交需求，我实现需求的关系，这样也更容易在“需求条件下”双方关系和谐。

需求别乱接，要接接完整，我们是需求的人肉过滤器

这点，我觉得可能是开发们吐槽产品们乱提需求的一个很大的原因。

产品会天天跟运营（内容、活动、社区、投放、用户）、广告和开发沟通，免不了这边来点需求，那边来点需求，但是这些需求一般有以下几种可能性：

1. 需求方不知道自己到底要干嘛的，死活要做某个需求的；
2. 需求方不知道自己到底要干嘛的，就尝试性的提一提需求；
3. 需求方知道自己最终要干什么的，但不知道过程怎么弄，就干脆不弄的；
4. 需求方知道自己最终要干什么的，尝试弄清楚过程，但没弄清楚的；
5. 需求方知道自己最重要干什么的，也给清楚的把需求整理了的。

以上列举的还没包括需求合理与不合理的可能性。

现实工作中，前面1、2两种不知道自己要干嘛，但是又要跟你提需要的人多了去了。

这个时候你不能顺着他，不然倒霉的就是你，还有在你后面的设计、运营以及开发们了。

这个时候你可以怎么办呢？

• “大杀器”：用“为什么要做这个，说不出原因就拒绝”的态度把这个需求给直接打回去；
• “小温柔”：通过多问一些问什么，把需求方逐渐转化成3、4、5、情况。当然，搞不清自己目的还要做需求的人，目测也不太可能变成e这种类型。

说完a、b两种情况后，我们再来说说该怎么解决3、4、5这些情况。

这些情况还算好，至少知道提这个需求的目的是什么，那就好办多了：

• 如果你不认可他的需求，并且觉得这个需求不合理、优先级低，那么可以通过沟通回绝；
• 如果你认可他的需求，也觉得这个需求合理、优先级可以比较高，那么就该帮助他一起正确的达到目的。

举个运营需求的例子：

运营部门要做个目的明确的活动 ，同时他们也做了一个活动流程出来。你看过之后，觉得可以做，但是现有的流程比较乱，导致用户会懵逼同时开发资源也可能会被不必要占用。

这种情况下该怎么办呢？

应该运用自己的逻辑，帮助他们一起梳理这个流程，提出可能性的解决办法，大家一起沟通商量，把东西做好，最终让后面的设计和开发们都不会做白用功。

再举个产品需求这边的例子：

因为公司政策问题，导致乃们要做某个需求，这个需求涉及的大部分功能，其实其他小组已经做好了。也就是说只需要自己开发小小的量，同时接入对方小组的东西就可以了。

那么，问题就来了，产品汪们在分析完自己要开发的部分之后，就完成这个需求了吗？

显然不是，是否考虑过以下问题？

• 功能的整套流程是否有走顺？
• 怎么对接比较好，逻辑比较干净？
• 对接需要提前注意到哪些问题？
• 对方开发的页面是否和你的页面UI、交互一致？

以上都是在进入到设计和开发前，“产品汪们”就要实现做掉的工作，而不是到设计到开发后，才开始的工作。

一个需求，并不是写完需求分析就完事了，而是要把围绕着这个需求的所有相关事情都要先搞清楚，继而整理清楚，再进入下一步，这样才省时省力，合作起来才不会这么累。

锅要背起来，不要怕被骂，我们是大家的人肉防弹衣

这点，其实很明确，不管是这个版本bug率过高了、还是用户流失严重了，亦或是新出来的功能被用户骂了等等，都有产品汪们的责任，不要想躲。

举个例子：

假设某一次版本上线后，bug率蹭蹭蹭往上涨，用户流失的比较严重，各项指标都在刷刷往下掉。这个锅该谁背？我觉得产品汪一定逃不掉。为什么？

• bug率过高，那说明测试大人们没有好好测试（测试的锅）或者没有时间好好测试；
• 测试没好好测试，但汪们居然验收通过了，那汪就该背锅；
• 测试没有时间好好测试，那是不是说明上线时间安排的有问题？是不是进一步说明项目时间没安排好？那是不是又进一步说明需求没安排好？汪又要背锅了；

不管如何，“产品汪”们是上线前的最后一道线，一旦线上，说明你认可了上线这个行为。不管有什么结果，都得担着。

这个不是鼓励大家把什么错都揽上身，而是千万不要觉得，自己在一件事里一定没有责任。

好啦，以上就是保命四招：

• 会一招，可保性命无忧；
• 会两招，可保不受白眼；
• 会三招，可被人人喜欢；
• 会四招，可带团队玩耍。

我还在练习……大家互勉……

#专栏作家#

killifer，微信公众号：killifer，金融资讯&工具类产品经理。脑洞大、笑点低、间歇性“有毛病”的理工科实力逗比少女。

本文原创发布于人人都是产品经理，未经许可，不得转载。