哇咔咔~~~大连,青岛,秦皇岛,在5分钟之内决定了去青岛,Ann和猴子都去过,只有我一个人没去过,但她们的反对无效,最后还是要听我的~~

其实一直想去的,在上学的时候,哥的供应商在那边就嚷嚷的让我去包吃包住的,天天吃海参!后来随着哥远去USA,就一直到现在了,在加上猴子说我是个工作狂,去的希望比较渺茫了,但这次我是铁了心要去了,谁也拦不住了!

为什么去青岛,因为夏天了要去看大海~~~哇咔咔

上周的蜜瓷聚会没聚成,因为那个大暴雨,很想念yoyo,猫和小嫩嫩和好了,真是太好了,终于大家都幸福了~~

好期待青岛之行~~大海~~

特别谢谢此仁兄~~目前这位仁兄自称单身~单身的女生请注意~~

dsc_0072

1、Innovation, not instant perfection/创新不会马上就完美
Start rough, learn and iterate./开始粗糙,学习和迭代

2、Ideas come from everywhere/点子来自任何地方
Ideas can come from the engineers, managers, users even the financial team.Share everything you can/分享一切

3、Everything is put on the intranet, so employees know what is happening./任何事情都可以在内网分享
You’re brilliant, we’re hiring/你有才,我雇你

4、Founders Larry Page and Sergey Brin approve hires. They favor intelligence over experience. /Larry Page和Sergey Brin的雇人之道是,喜欢聪明人胜过有经验的人
A license to pursue dreams/允许追求梦想

5、Letting employees use 20% of their time on what ever they want./让员工用20%的时间做爱做的事
Data is apolitical/数据中没有政治

6、There is no “I like”, it is all about the basing decisions on data./不要说“我喜欢”,所有决定都靠数据立足
Creativity loves constraints / 创造力爱制约

7、Engineers thrive on constraints. /工程师靠限制发展
It’s users, not money / 是用户而不是钱

8、If you can successfully engage users, you can monetize them/如果你能成功吸引用户,你就能赚钱
Don’t kill projects, morph them/不要毙掉项目,改造它

9、Products that doesn’t seem to respond well in the market should be morphed into something the market needs, not cancelled /产品市场反响不好应该改造它以适应市场的需求,而不要轻易取消它

 需求不等于功能,或者说你最终设计出来的跟用户告诉你的他需要的“功能”一模一样的功能并不等于他真正想要的功能。
      用户告诉福特,他需要一匹更快的马,最终福特给用户的是汽车。
      用户告诉你,他需要一个公告板,他要用来展示自己的新产品、自己的新资质荣誉、自己的特价供应、…,你就给他一个公告板,允许展示图片、超链接、产品、视频的“公告板”?
      用户告诉你,他需要一个可以收藏自己喜欢的商品、可以合并在一起付款的功能,你是给他一个购物车还是给他一个收藏夹还是同时给2个?(
Via
    
       产品设计人员在产品规划的初期直奔功能和表象而去,把自己的思维限定在一个很狭小的范围之内,用户想要什么就给什么,最后只能被用户带到沟里。何 况,很多时候其实用户是不知道自己到底需要一个什么样的功能的。如果我们能试图去挖掘一下用户提出需要“XX功能”背后的需求来设计一下,把他提到的这个功 能进行延伸与扩展,给他一个全新的不一样的功能,反而会获得更好的效果。
       我们可以把得到的需求可以分为三个主要类别:
       1)最显而易见的是人们讲述的、他们想要的东西。这中间有一部分是非常清晰的好想法,会寻找各种途径进入最终产品。
       2)有时人们口中说出来的、所期望的功能并不是一个很好的主意,但是它们代表了一条通向下一个版本的路径:用户实际想要的东西。用户的需求有时是行不通的或者治标不治本的,通过与用户探讨这些建议,有时可以得出真正解决问题的、完全不同的需求。
       3)人们不知道他们是否需要的特性。

       因为用户群体之间存在着很大的差异性,所以确认用户需求是复杂的。我们可以把大量的用户需求划分成几个可以管理的部分,这样通过用户细分来完成。把用户分成更小的群组,每一群用户都由具有某些共同关键性特征的用户所组成,可以通过人口统计学的标准来划分,也可以通过心理方面的数据来描述。
      细分用户不仅仅因为不同的用户群有不同的需求,还是因为有时这些需求也是相互矛盾的。对新手用户而言他可能需要把一个系统分成若干简单的步骤,而相对于专家级用户而言这样的分解可能会妨碍他的快速操作。很明显的是,我们无法提供一种方案来同时满足这两种需求,此时,我们需要要么选择针对单一用户群设计,要么为执行相同任务的不同用户群提供不同的方案。

       撰写需求的几个原则:
       1)乐观。描述这个系统将要做什么事情去“防止”不好的情况发生,而不是“不应该”做什么不好的事情。比如,“这个系统不允许用户购买没有风筝线的风筝”替换成“如果用户想买一个没有线的风筝的话,系统应该引导用户到风筝线页面”效果会更好。
       2)具体。尽可能详细第解释清楚情况,这是决定一个需求是否被实现的最佳途径。
       3)避免主观语气。需求必须可验证,就是说,它必须要能证明这个需求可以被满足。比如,“这个网站的风格应该是时尚、闪耀的”这样的需求是无法被验证的,我对于史上的定义也许并不符合你的,而Boss对时尚可能有完全不同的看法。
      4)用量化的术语来定义需求。比如,“具备高级别的执行能力”可以用“要求这个系统的设计至少要支持1000个用户同时使用”来代替。
 
       搞清楚了“用户具体需要的是什么”、“企业需要得到什么”这样2个问题之后,我们才能配合着网站的运营开始把用户需求和网站目标转变成网站应该提供给用户什么样的内容与功能,进入到具体的功能设计层面。作者:kent.zhu 

好不容易和密闺们吃个饭饭,好不容易找了个人帮我锁门,好不容易不用加班,结果我还把手给掩了,那个帮我锁门的人还没有带钥匙,我又打车送了一趟,我的亲爱们的我是不是有点背!

yoyo已经开始筹备婚礼了,听猫说的老男人还真是对猫很好,很好奇想见见!

我们的生活呀,痛苦的,幸福的,美好的,期待的……三个女人一台戏!哇咔咔

最近很嫌弃自己的年龄,不知道为什么一下子就变老了,看着小朋友们忙着出国,忙着换工作,忙着不靠谱的理想!真羡慕!

石同学说让我也出国看看外国的大农村,我说我舍不得我热爱的故土,舍不得到处都是充满京骂的话语,虽然我很向往外国社会的open程度,但是我还是老老实实的和妞们在一起吧 !对了还有我最喜欢的中餐,我绝对不能离开!要不我非天天哭八回

pm很忙~

In: work-产品

19 May 2009

pm一直很忙,最近boss大人让大家写工作流程和遇到的问题,pm的下属们提了很多问题,全部强调明确功能和项目需求。pm知道这些不是针对自己,但是还是觉得心里很不舒服,因为boss总是把责任推到接点pm这里。而下属推卸责任的目标也是pm。

美工在推卸自己为什么没有设计好这个功能,技术在强调需求讨论和评估为什么不详细,pm觉得很无辜,因为每次产品的会议都是一起参与讨论的,每个实现的功能和逻辑都是经过推敲的,pm总是会写文档,总是会画框架图,总是会把所有的字段都列举上,总是在满足boss的需求,也是在现有的程序逻辑上进行规划,可是每每boss不满意的时候,要承担责任的时候,pm总是会站出来,接受所有人的指责。

pm真的一直都很努力,每期功能单上的需求总是会越来越多,pm总是想一个一个把他们都解决掉,可是没有优先级,boss总是提的就是最重要的,要马上就执行,不管上个项目和功能做到什么程度,不得不停下来去做新的需求。pm总是幻想能不能在招聘个pm,因为pm觉得自己不是神仙,但很多东西是自己真的不知道怎么做!

pm是产品经理,pm不是万能的产品经理,pm不了解网络安全,pm只知道seo的皮毛,pm更不是美工对色彩设计达到很高的水平,pm也不是客服经常要解决商户的问题。pm做出的产品一定不是十分完美的要经过一些扩展和修正。pm也不是技术要帮忙设计数据库的搭建和去找适合的脚本。

pm有时候在处理自己的问题地时候,别的员工会跑过来问你,“我的防火墙怎么到期了,我怎么办”“某某的首页图片能不能链接到自己的网站上”尽管这个问题pm已经都回复很多次了,还有“广告图片能帮忙帮我上一下吗”“我的网站怎么打不开了,他们怎么就能打开”。

pm很想向别的pm一样,做一些用户需求,做一些数据统计,收集相关的反馈来提升产品,pm想一门心思的做细致产品,但觉得好难,因为pm太忙了,喘不过气的忙

上个星期的闹心的事情就不说了,下个星期的闹心事太多了,工作从来不让人安逸,

大白-我们家Wii,小白-我们家psp,买了小黑-我们家本本,下面努力向着我们家大黑奔了,

 dsc01123

47_100052_13640b5d4d42286

很久没有得瑟了,在平静中度过了众人关注的生日,我远去的青春呀~~

突然觉得离开了QH后,我迷失了自己,我找了很多个理由当借口,找了很多的想法来说服我自己,其实我tmd就是想要安逸,不想改变,boss说无欲无求是很可怕的,因为做人没有动力,而我是理想离我遥遥之不可及,有些心灰意冷!

很想得瑟一下,~~其实没有那么多借口,如果心态良好可以面对一些,只要自己高兴就得了!

生日没有蛋糕,没有蜡烛,我也没有许愿,但是我觉得放下自己的坏心情,我好好的得瑟一下~~

谢谢朋友们的祝福~~

2006年,傅盛从雅虎出来,重新加入了老东家周鸿祎的奇虎公司。此时的奇虎公司创立时间还不长,却已经有了一张未来的蓝图。在当时3721担任了三年产品经理的傅盛,带着三个人开始了360安全卫士的产品之路。现在,360安全卫士已经成为了家喻户晓、耳熟能详的安全软件了,而傅盛却改变了自己的人生轨迹,加盟经纬中国成为了一名投资人。

 

       今天的傅盛已经是一名投资人了,所做的工作虽然有很大变化,但他仍然非常关注产品,以及产品团队。在他看来,一个值得投资的项目,一定有一个值得投资的产品经理。而被投资的产品,必须有自己独特的亮点和明确的思路。这是运营一个软件产品所必须具备的原则。 

产品经理要把自己看成总经理 

       许多公司都面临着同样的一个问题,为什么产品经理这么难招?傅盛说:“产品经理既要有能够把握产品和市场方向的能力,又能够静下心来做很多耐心细致的工作,甚至于包括设计产品的细节。这种要求对于一般的技术人员来说确实是太高了。”这也是为什么在很多公司里,总经理就是产品经理。 
       但是,在很多的公司,产品经理其实是一个定义很模糊的角色:作为一个产品的负责人,这个角色通常承担着大量压力和责任,却几乎没有权力可言。由于产品经理本身并不是一个管理职位,这就对产品经理提出了非常高的要求:能够想方设法协调各种公司部门的资源,为之己用;如果产品在市场上出了问题,必须能自己肩负责任,承担风险;所有工作中最琐碎的部分,基本上都是产品经理一手完成,事无巨细。用傅盛的话说,这是一个生存环境很艰苦的职业。 
       如果用电影导演这样的角色来做对比的话,就可以发现与产品经理的工作很类似。在面对灯光、摄像、场景、剧务、场记、后勤、演员、音乐、后期等一大堆细琐的工作面前,导演必须坚定不移的努力完成自己的作品。因为电影拍砸了,人们只会认为导演无能,没有人会去责怪其他任何一个角色。由于权力并非绝对存在,即使是大导演,在面临那些不能开罪的人面前(比如制片人、投资人以及大牌演员等),也只有耐着性子慢慢打磨。 

产品经理关键词:积极心态,关注细节,善于沟通 

       最开始的傅盛也和今天很多产品经理一样,一心只想做大事,对于很多细节的工作显得三心二意。加上他以前曾经开发过不少MIS系统,其中还有些是直接给国家各大部委开发的项目,面对一个产品页面上的小按钮,傅盛怎么也提不起兴趣来耐心揣摩。尤其是在最开始担任3721产品经理的时候,“上网助手”产品的界面几乎简单到了没什么事情可做的程度。 

       在初任产品经理的那段日子,什么事情几乎都得自己做。团队里一共没有几条枪,产品设计出来,连测试都觉得很难看,索性干脆罢工了。这种时候,积极主动的心态在做产品的过程中起了非常重要的作用。按照通常的情况,多半产品经理都会认为测试不给自己面子,但傅盛觉得,这是作为产品经理不必可少的思维方式。 
       从心态上来说,傅盛认为有两种人绝对不适合做产品经理。第一类是那些自以为是,刚愎自用的人。这类人通常独断独行,很难与人沟通。要么完全听不进任何意见和建议,要么阳奉阴违。另外一类则是那些耳根子太软的人,在面对关键问题上优柔寡断,甚至在某些争执发生的时候采用骑墙策略,无法对产品本身有实质性地推进。有意识地培养心态,是产品经理的入门课程。在遇到批评和意见的时候,第一要诀就是放弃反驳,即使别人说得不对,也应该至少静下心来听听,放下面子,才能真正做好产品经理。 

       关注细节是一个产品经理必备的能力。现在回想起来,当初觉得3721上网助手界面无事可作其实也是自己对细节不够关注的一个表现,傅盛回忆道。现在再看看浏览器的地址栏,里面有太多的产品设计可作,Firefox 3也正是在这里找到了突破点,一鸣惊人的。现在,面对产品界面、网站、宣传稿等,傅盛一眼就能看出里面非常细微的差别和不足,下属常常惊叹他的“眼尖”,也很头疼和他一起设计产品的界面或是琢磨如何宣传给用户,因为总会被他尖锐的指出诸多不足。

       “其实我生活上是一个很马虎的人,平时都不怎么修边幅,以前也从来没觉得自己能在细节上这么关注。之所以现在能够到达这个程度,没别的秘诀,就是熟能生巧”傅盛介绍到,为了能让自己对产品界面等细节有更好的感觉,他不断的使用各类互联网产品,尤其是客户端产品。每个产品发布新版的时候,自己也是第一时间下载、试用。日积月累,细节能力就出来了。有句话叫“读书破万卷,下笔如有神”“熟读唐诗三百首,不会做诗也会吟”,讲的就是这个道理。 
       由于产品经理的沟通工作横跨开发、测试、运营、市场等多个环节,因此有效沟通是产品经理的核心能力。“产品设计工作中,80%的问题都是沟通问题”,傅盛这么定义。很多时候,产品从最初的设想到最后的发布,差别巨大,很重要的原因就是没有沟通清楚,一点一点的差异的累计,导致了最后的巨大变形。“我们看很多大片,最后被观众骂的一塌糊涂,我就总在想,难道这些导演们不知道自己拍的片子烂吗?很明显,他们自己也知道。但可以肯定的是,最初,在他们脑海里的片子一定是一部美轮美奂的样子。但是,就是由于和各方面资源的协调、沟通的误差,导致最后快成型的时候,完全不是自己想象的样子了”一直喜欢用电影做类比的傅盛得出这样的结论。为了能够沟通清楚,傅盛逐渐养成了“逼问”的习惯:即在表达完一个观点之后,要对方再表述一遍,还要把观点拆散从其它角度追问对方的理解程度,才算把一个事情沟通完毕。 

具备猎狗一样的嗅觉,准确找到用户的甜点 

       当然,要具备产品观并不是一件容易事。“每一个产品都应该有一个明确的突破点,今天看,几乎没有任何产品,一上线就开始搭建平台而取得成功的。尤其是面向互联网的客户端应用产品,如果做成大杂烩,几乎不可能成功。这方面我们曾经见过中搜出品的网络猪,把浏览器、搜索、下载、聊天、邮件等所有的功能都集成在一起,摆在用户面前的必然是一个毫无特色的产品。”傅盛提道。 
       把握用户的需求来规划产品,尽管是一个目标,但绝不是被用户牵着鼻子走。更何况,踊跃提出“宝贵意见”的用户,往往都是一个小众,而产品规划的核心要点,是需要通过机制将大多数用户放在最重要的位置上。这一点几乎是很多互联网上曾经流行一时的小产品的通病,这些产品往往在进行产品功能规划上遇到了瓶颈,正是因为他们自以为是地认为把握了用户的心态,却忽略了产品本身的内涵。 
       尤其是那些小有口碑的产品,其产品团队很难自我否定,最终满足于单纯的产品功能,忽略了产品背后提供服务的那部分真正价值。甚至有些团队醉心于自身的技术,一味扩大产品线,无法在一个产品上做透,做扎实。“技术永远不是最重要的,只有和商业有效结合,才能把技术用好。”傅盛如是说。“比如iPhone,从技术本身而言,没有一个技术是独创的,但是,把很多实用技术捏和好,找到一个突破点、奇迹便会发生。” 
      做了投资人后,傅盛对此有更深刻的感受。“如果你把一个很领先的技术放在风险投资人面前,他们的眼里不会像我们一样闪烁着兴奋的光芒,反而,他会非常冷静甚至挑剔的追问,这个技术怎么应用给大众,能够找到怎样的商业模式,还有,这个技术的领头人是不是有足够的商业头脑,有没有足够的团队管理能力,有没有百折不挠的心态。所有这些,才是风险投资人们考虑的重点”。 

产品经理的成就感
       当然,产品经理是一项很有成就感的事业。产品经理是公司的“无冕之王”。行业内真正成功的产品经理,能成就一个企业。百度的俞军,从一个普通产品经理做起,创造了百度贴吧这个产品,最终成为了百度公司的副总裁。而傅盛,也从一个普通的产品经理,通过拼搏打造了一个全国闻名的360安全卫士,最终变为该业务的总经理,现在又转为知名风险投资公司的副总裁。提道这些,傅盛总是露出自豪的微笑:“有一段时间,我为了弄清楚网络游戏的机制,玩起了魔兽,我的老板当时怕我沉迷于此经常提醒我。我对他说,你放心吧,网游给我带来的成就感,哪有做产品得到的成就感大啊。魔兽在封闭的世界里最多升级到70级,我的产品呢,在开放的世界中边界无限,改变千万人的生活,我因此倍感幸福。”

好姐妹

In: 蜜闺

16 Apr 2009

47_100052_232c448605236c8

每天忙呀忙 对未来多向往
我们在不同地方 努力要活出自己的光芒
有时会失望 有时为爱迷惘
当现实让人受伤 可是我们学会要更坚强
一起梦 一起飞 我们是好姐妹
为幸福感动掉泪 你最了解我想要的安慰
一起笑 一起醉 我们是好姐妹
要为这友情干杯 这一路上有你多么可贵
我们是好姐妹 这感情多可贵
看 这世界会下雨 受了伤会哭泣
生命 有高有低 可是我从没想过要放弃
因为身边有你 在给我鼓励 Woo—-oh—
你是我最好的姐妹

如果你希望成为一个失败的产品经理,在遇到bug时,请立即动手修复它。如果bug可以立即被修复,为何要一拖再拖?PM应该是一位“执行者”,而非总是纸上谈兵的“思考者”。当问题出现后,必须在第一时间搞定它。当然,这样做可能浪费大量的时间,也可能分散精力,不过这是一位PM的最佳时间分配方式,不是吗?

If you want to be a bad product manager, solve a problem as soon as it becomes apparent. Why let something linger when you can take care of it? A product manager needs to be seen as someone who will “do” things, not just “think” about them. When a problem comes along, you must fix it as soon as possible. Sure, you may spend a lot of your time in this way, and it may distract you from other things, though this is really the best use of your time, isn’t it?

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

If you want to be a good product manager, do not immediately solve every problem which presents itself. It is often tempting to fix an issue as soon as it appears, though there are many good reasons to not rush to address problems:

1.如果迅速解决了问题,你可能会忽略问题的根本原因。在大多数时候,每个问题都有其根本诱因。在问题刚暴露的时候,诱因一般深藏不露,有很多的可能性。笔者认为,根本诱因最可能来自于需求确认阶段。多篇文章都探讨了这方面的问题,比如: Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems.

If you fix the problem right away, you may not be addressing the underlying issue that caused the problem in the first place. In fact, in most cases, there is a root cause which is likely not visible on first glance. This applies to many areas in product management, most notably in addressing requests from customers. This has been discussed here in several different posts, including Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems.

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

However, this concept applies to other areas of product management as well. There are many times when “points of pain” which are readily apparent can be traced back to root causes. Challenges within the product development process may be attributable to several factors. For example, releasing a product with many defects may initially appear to be a problem easily solved by adding additional Quality Assurance resources, though the real problem may be lack of appropriate details in product specifications. As another example, disagreements about prioritization for development work may cause many to push for a voting system, though the disagreements may be caused by an inconsistent view of the vision, strategy, and roadmap.

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

In medicine, there is a saying that doctors should seek to treat the disease, not the symptoms, and product managers would be well served to follow this advice as well.

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

Letting the problem subsist for a period of time may be the only way to get others to realize its severity. Parents often tell tales of how their children learned what not to do — not to touch a stove, for example — by letting the children try it once and learn for themselves that it is a bad idea. A similar approach can be taken in product development. Whenever you try to convince people to change or implement new ideas, you need to show them why the changes you are proposing are needed. Without understanding the need for change, people will cling to the status quo.

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

For example, you may want to implement a requirements management tool because of the problems you see with how requirements are managed. Rather than spending all of your energy telling people why it is needed and doing demos of the various products, you may be better off letting the current requirements process show its weaknesses. Perhaps you have a new version of your product which is close to release, yet you know that there are requirements which were likely lost along the way. Instead of insisting that the release be held up, you can foreshadow the issues before the launch and let the product be released. If you are correct, it will soon be apparent to all that requirements were mistakenly never implemented because of the faulty requirements management system.

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

This tactic needs to be used carefully. As product manager, you are still responsible for the product in the end, even if you are trying to teach your team a lesson or tell them “I told you so.” However, in many cases, it is possible to use smaller projects or specific aspects of the product as examples which can prove your point and make the case for change.

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

Problems may not be as severe as you originally thought. Often, when an issue presents itself — defect in the product, complaint from a customer, argument in a meeting — there is a rush to resolve it immediately. A product manager will often break focus from the really important things — strategy, roadmap, getting out of the office to talk with customers — and instead spend energy on “fire fighting.”

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

However, issues are rarely so important that they must be resolved immediately, and seldom are they more important than the larger strategic activities on which a product manager should be spending his or her energy. In the heat of the moment, every problem appears to be major, though with time, the importance of most usually diminish. The truly severe problems will become apparent quickly, and this will allow you to focus more attention on the major issues rather than the crisis of the day.

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

More time gives you more opportunity to find the right solution. In a rush to find answers before we even understand the full extent of the problem, we often choose the first idea which comes to mind. While this may be an acceptable solution, with more time to understand the issue, look for underlying problems, and brainstorm solutions, it is likely that a better solution can be determined. While more time does not guarantee more or better solutions, it is at least certain that you will not have fewer ideas or worse solutions if you provide more time to consider your options.

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

The next time a problem comes along, resist the urge to take immediate action. Take a strategic — not tactical — approach to problem-solving by evaluating the issue and considering possible underlying causes along with the overall severity. By not responding immediately to every issue, you will spend less time putting out fires and more time on the true value-adding strategic aspects of product management.

本文译自,作者是Jeff Lash。

About this blog

半是蜜糖半是伤 也不是真的不要关心 也不是真的不曾介意 可偏我也不是真的拒绝这一切 只留下自己 也不是全都不理不听 也不是真的无从继续 可每一次我的试着坚强 都成了不得已的哭泣.

Photostream

    IMG_0209IMG_0203IMG_0419IMG_0210IMG_0208IMG_0355

 

July 2009
T W T F S S M
« Jun    
 123456
78910111213
14151617181920
21222324252627
28293031  

What I'm Doing...

Posting tweet...

Powered by Twitter Tools.

IMG_0209IMG_0203IMG_0419IMG_0210IMG_0208IMG_0355