配图
其实我不喜欢「撕逼」这个词，之所以起这样的标题只是想吸引你点击进来。
有段时间自己非常喜欢跟别人「撕逼」，还把它当做一种乐趣，因为撕的过程就是一个观点互相碰撞的过程，这简直就是精神上的一种愉悦。但是站在现在的角度再回头看当时的自己，觉得这是件很不恰当的事情。有时候只是单纯为了撕而撕，到最后也没有一个结果，还浪费了互相的时间，更有可能，不管选A方案还是B方案，没有太大区别。
「撕逼」这个词给人的感觉好像是大家都撑眉努眼然后坐下来开辩论赛的感觉，别这样，我们不妨优雅一点，把它称作「讨论」。
既然是讨论问题，很有可能是想法发生了分歧，为了对自己做的功能负责，产品经理就需要消除这个分歧，把大家的想法都拉到同一频率上。
一、与产品经理讨论
产品经理与产品经理讨论问题的情况是非常频繁的，大家会出现就某个功能或交互有不同的看法，然后会出现互相争论的情况。这里有几种情况是要尽量杜绝的。
一是不要为了说服别人支持自己的观点就拿着竞品或者某个很优秀的产品的对应功能对着其他产品经理说，「你看，这个产品也是这么做的」，那么这个产品的其他的功能点我们为什么不也去模仿呢。往往很多情况，为了说服别人支持这个观点就找相仿的一个应用来说事，下次为了说明另外一个观点发现之前那个应用做的跟自己的不一样就赶紧再找个跟自己做的功能相仿的应用来说事。
二是不要「我觉得」，虽然有很多文章和书籍都说了，做产品不要为自己设计，要让自己一秒变成小白用户，可是很多人都是很难做到的，很容易就把自己的经历代入场景。这样出现的问题是一个产品经理说「我觉得我会A，我就是这样的」，另外一个产品经理说「我觉得我会B，我就是这样的」，如果是这样讨论问题，没得聊了。最好的方法是拿数据说话，拿用户反馈说话（这也需要批判性去看待）。
三是不要拿极端情况试图推翻别人的方案。这其实是逻辑学上的一个非逻辑思维，要不得。你几乎在每个方案中都能找到问题，但这不代表别人的方案不好，为了说明别人的方案不好最好的方法是自己也拿出个方案来，不要瞎争论。其实个人觉得最好的方法是拿场景说话，看一个方案能否尽可能覆盖目标用户的场景。
二、与交互设计师讨论
这个时候产品经理内部功能需求评审已经通过了，进入了交互设计阶段。这里也有几种情况。
一是交互没有深刻理解为什么做这个功能，当交互不了解时就会出现交互稿的偏差，这需要产品经理多沟通，不然产品以为交互都知道了，结果在讨论交互时都不在一个点上，会出现很多无意义的争论。
产品经理会对交互稿提出很多不一样的想法，认为交互应该是这样的。我觉得如果产品经理不太懂交互设计，尽量让交互设计师自己决定，专业的人做专业的事。如果想跟交互讨论细节，最好自己也很懂交互设计（不然是在浪费别人时间），而且我认为交互设计也是产品经理的一项基本功。
三、与工程师讨论
其实与工程师发生对某个功能的争论的情况是很少的，产品经理要做的事情就是告诉开发目前这个功能出现了什么问题，改善方案是什么样的，解决之后对产品有什么好处，优先级有多高，让开发有动力去做，就OK了。
四、与运营人员讨论
运营人员会从他们的角度提出一些产品需求，当他们把大致的方案想好后就会来找产品经理讨论细节。这其中需要产品经理认真分析需求，不要来个需求就接，要了解清楚事情的前后经过，然后再评估。
比如运营拿个方案过来说要做这个东西，产品经理就得判断做这件事情是为了解决什么问题，目标是什么，大概会需要多久的开发时间。还比如，运营要求自己负责的某个功能的入口能大一点，这要考虑整个页面的布局情况和判断它的重要性。最后，把这些思考的过程和结论告诉运营，达成一致的想法，相信合作起来也会顺畅很多。
以上就是自己的一些总结，希望对大家有一点帮助。
网友评论