产品经理们,遇到Bug请别十万火急

互联网 2008年08月05日 14:43 查看5020次 作者: Jeff Lash  【
文章分类:项目管理
如果你希望成为一个失败的产品经理,在遇到bug时,请立即动手修复它。如果bug可以立即被修复,为何要一拖再拖?PM应该是一位“执行者”,而非总是纸上谈兵的“思考者”。当问题出现后,必须在第一时间搞定它。当然,这样做可能浪费大量的时间,也可能分散精力,不过这是一位PM的最佳时间分配方式,不是吗?


如果你希望成为一个成功的产品经理,在遇到bug时,请不要总是立即着急的修复它。不可否认,我们在遇到问题时,总是迫不及待的想改正。然而事实上,其实根本不用那么的十万火急,理由如下:

如果迅速解决了问题,你可能会忽略问题的根本原因。在大多数时候,每个问题都有其根本诱因。在问题刚暴露的时候,诱因一般深藏不露,有很多的可能性。笔者认为,根本诱因最可能来自于需求确认阶段。

同样,在产品管理的其他阶段,这个理论也适用。有些问题可以很容易就找到根本诱因,但产品开发的真正挑战来自各种不稳定的因素。例如,有时候一款漏洞百出的产品在上线之初,只暴露了冰山一角:一个很小的Bug,似乎十分容易解决。另一个例子,开发过程中,团队成员对各项功能的优先级有争议时,靠“民主投票”来做决策,而忘了引发争议的源头:对产品远景、战略及计划缺乏共识。


医生治疗的是疾病,而不是治疗症状(译注:治疗感冒或支气管炎,而非咳嗽)。医生的任务不是治标,而是治本。对于PM而言,道理一模一样。


让问题暴露一段时间,或许是让大家认识到其严重性的唯一方法。很多父母都会说,他们的小孩吃一堑才长一智——例如,不去摸滚烫的炭炉——若小孩自己被炭炉烫伤一次后,他们自然会明白那东西是摸不得的。在产品开发过程中,存在着同样的道理。当你试图请同事修改或改进某功能时,你需要解释这是为了什么。如果大家不明白改进的意义,自然会无动于衷。


举个例子,假设你发现团队使用的需求管理软件存在着很大的问题,假如你希望马上修改它,或许得花大量精力去告诉大家修改的意义,还得制作demo 进行 说明。但如果让这个需求管理软件继续运转一段时间,让它自己暴露出弱点,可能是一种更好的办法。因为需求管理软件的问题,在新产品上线前,你会发现有些最初制定的需求并没有实现。此时,你可以告知大家这些遗漏的需求,但是不需要为之耽误了上线时间。如果你是正确的,要不了多久,大家就会意识到,因为使用了那个糟糕的需求管理软件,才导致产品出现一些无法挽救的Bug。

提醒,本方法需十分小心的使用。作为PM,就算你本意是为了让同事们更透彻的看清问题,也不能忘了你是该产品最终成败的负责人。所以多数情况下,使用本方法时,最好选择小项目来作为案例。

问题可能没有你想象中那么严重。每次问题出现的时候——产品暴露了Bug,用户发出抱怨,会议上的争论——看上去总是迫切得非解决不可。于是,PM不得不暂时暂停正在进行的真正关键工作——战略、计划、用户调研——而把精力用在四处“灭火”上。

然而,必须立即解决的Bug其实很少。同时,与PM应该着重思考的产品方向等问题比起来,这些Bug的重要性实在很低。每个Bug都有看上去万分关键的时刻,但过段时间后,它们似乎都变得无关紧要了。事实上,真正严重的Bug会迅速暴露出来。牢记这一点,会让PM把时间用在刀刃上,而不是每天都在处理危机。

花更多的时间可以找到更完美的解决方案。若在全面了解Bug之前,就急着去为Bug寻找答案,我们通常会选择脑海中冒出来的第一个解决方案。这可能也算是一个过得去的方案,不过若我们花更多时间来分析此Bug,找到其根本诱因,甚至来一场头脑风暴,或许我们能发现更完美的解决方案。当然了,花更多时间也不一定就找得到更棒的方案,但至少,花了时间之后,得到的不会是更少的备选方案或更差的解决方案。

下一次遭遇Bug时,请别十万火急。PM需要有战略眼光(不是战术),请先分析Bug,找到根本诱因,并衡量全局重要性,再对Bug进行解决。若不是每一次都着急解决每一个Bug,PM可以花更少的时间四处“灭火”,从而拥有更多的时间去思考产品战略——如何给用户带去更多的价值。

本文译自,作者是Jeff Lash。

责任编辑:抽烟的蚊子

给文章打分...

平均分:0.9(50 次)

-5 -4 -3 -2 -1 0 1 2 3 4 5
7

顶一下

发表我的见解...

  • 您的大名: 留空为匿名
  • 您的主页:
  • 您的邮箱: