八 22, 2013 - 产品相关, 敏捷实践    No Comments

当我们在产品PK时,我们在PK什么?

互联网产品研发团队经常都会有各种产品讨论,大到产品方向、小到界面上几个像素,各种PK不断进行中。我个人是很支持产品PK,也常常喜欢和别人切磋一下。在一个开放的、相互信任的团队里,PK会带来各种想法的碰撞,大家会快速达成共识并把产品做的更好。

PK并非总是那么美好,在产品讨论的时候,也常常会出现对一个讨论点你觉得要这样,我觉得要那样,各自坚持导致僵持不下,争论半天没有结论。这样的PK多了不仅打击了参与者之间的默 契和热情、也会阻碍工作的进展。

如果你经历过让人痛苦的产品PK,不知道你有没有想过一个有趣的问题:
当我们在产品PK时,我们在PK什么?

表面上看起来我们都在阐述自己对产品设计的看法并努力说服其他人,实际上我们不愿意承认的是:

1. John说这个UI交互应该这样做,这样做确实有一定的好处,但他提的这种方案我没有考虑过,实际上是我做的功课不够,如果我做了足够的功课,我会事先考虑对比这种方案,明确的知道 它的优缺点,另外我所积累的设计方案也还不够多,但是我不愿意承认这一点,这会让我觉得丢脸,而且我提出的方案本身有一定的合理性,所以我要坚持捍卫我的方案。

2. John喜欢这种配色,鲜艳有活力,Mary不喜欢,觉得太招摇不大气,他们都在表达个人的喜好和感觉,并且都觉得自己的品味很不错。实际上这些感觉没有客观的分析支持,它们很模糊, 并且容易受影响而改变。

3. John用过大名鼎鼎A产品是这样设计的,而Mary用过也很出名B产品时那样设计的,这些产品都这么成功,我们直接copy就好了。实际上有些东西是无法复制的,当我们看A和B时,我们看到 的是一个结果(它是静态的),我们无法看到整个过程:A和B是如何设计成,为什么是这样而不是那样。当我们没有自己的思考时,因为A这样做可以,加上A,B那样设计,加上B。我们最后 得到只是一个四不像。

4. John是个Leader,他的工作经验比较长,因此他的位置+他的经验在无形中会产生权威感,当他的方案被否定时他的权威感会下意识的让他为自己的观点辩护。如果他的方案最终被采纳那么反过来又会加重他的权威感,这个与方案本身是否更好并没有决定性的直接关系。

5. John和两个用户聊过,用户给了他很强烈的反馈和修改要求,因此他觉得按照用户说的来做是应该。你看我这里有非常明确的用户反馈和方案,你为什么不做?我的需求你不做你就是不尊重我。实际上如果深入的去分析会发现导致用户吐槽的是更深层次的问题,用户提出的修改要求不仅不能彻底解决问题,而且会导致系统更加的复杂。

6. John和其他部门准备搞起一次运营活动,为了让这个活动好玩而且有趣,对方提出了全新的活动方案,平台功能需要有很多地方的改动来支持这个活动。这个活动很重要就修改平台支持一下嘛!你这也不支持、那也不支持,我怎么运营?!产品就是运营出来的,你应该听我运营的!实际上:运营活动完全可以利用平台已有的功能来策划并且不会影响到用户玩法,针对特性活 动的特殊开发不仅耗时耗利、而且是用过即弃。这本身违背了运营的根本目标。

当你们在产品PK时,你们在PK什么呢?

 

Got anything to say? Go ahead and leave a comment!